1. 1. 22nd May 2015 Android Development Project CI360 Mobile Application Development Luke Willmer UNIVERSITY OF BRIGHTON JUST DINE APP
2. 2. pg. 1 Table of Contents List of Figures ....................................................................................................................................................................2 List of abbreviations..........................................................................................................................................................2 Introduction ......................................................................................................................................................................3 Rationale and Purpose..................................................................................................................................................3 Background Research and Implementation..................................................................................................................3 Optimisation .....................................................................................................................................................................4 Compatibility.....................................................................................................................................................................6 Gestures........................................................................................................................................................................6 Mobiles in Context............................................................................................................................................................7 Screen Captures................................................................................................................................................................8 Evaluative Summary........................................................................................................................................................12 Critical Evaluation .......................................................................................................................................................12 Methodology...............................................................................................................................................................12 What I Have Learned...................................................................................................................................................13 Problems Encountered ...............................................................................................................................................13 Future Extensions........................................................................................................................................................14 References ......................................................................................................................................................................15 Appendix .........................................................................................................................................................................16 Appendix A Original Time-Gantt Chart...................................................................................................................16
3. 3. pg. 2 List of Figures Figure 1: Android Version Distribution (Mick, 2015)........................................................................................................6 Figure 2: Gestures within Google Maps (Scilligence, 2015)..............................................................................................6 Figure 3: Just Dine Landing Page.......................................................................................................................................8 Figure 4: Nearby results for 'Chinese'...............................................................................................................................8 Figure 5: Extended radius and hybrid map type...............................................................................................................9 Figure 6: Settings Activity..................................................................................................................................................9 Figure 7: Advanced search result....................................................................................................................................10 Figure 8: Advanced search predictions...........................................................................................................................10 Figure 9: The About page for this app ............................................................................................................................11 Figure 10: Graphical Time-Gantt Chart...........................................................................................................................16 List of abbreviations ADT Android Developer Tools API Application Programming Interface APP Application CPU Central Processing Unit GPS Global Position System HTTP Hyper Text Transfer Protocol JIT Just In Time complier JSON JavaScript Object Notation JVM Java Virtual Machine MBR Master Boot Record RAM Random Access Memory SDK Software Development Kit SHA Secure Hash Algorithm XML Extensible Markup Language
4. 4. pg. 3 Introduction This project was undertaken to provide a user-friendly app that could direct its users to restaurants nearby, by using Google APIs and the users GPS location. This section will be used to identify the reasons for selecting this Android app idea, the apps use within a real-world environment, the background research required to complete this project and the decisions made throughout this apps development. Rationale and Purpose This app idea was chosen to satisfy the need for an effective restaurant location app, with a brief search on the Google Play Store only finding restaurant- styled games, and with a minimal number of apps actually providing these necessary locations. In addition, these restaurant-styled apps seem to be growing in popularity with apps such as BookATable, and voucher-styled apps including Groupon and VoucherCloud. This app was developed to provide a more user- friendly app to use than the main competition: Restaurant Finder, by identifying any issues with usability or functionality with the competition which could then be used as part of the development for my app. In addition, my rationale for developing this app idea was to enable me to gain valuable experience of using APIs, along with different layouts and structures within the Android development stage. Background Research and Implementation This segment covers all of the required research which allowed me to interact with the Google Maps and Places APIs, along with the Android developing environment. This will be discussed chronologically to help portray the steps taken from the initial app development stage through to its completion. The entirety of this section covers research that has been gathered since the project conceptual documentation. To begin, the functionality of spinners had to be researched, including how they are displayed, and how multiple entries can be added. During this research, it became evident that using spinners for changing options was more efficient and more effective for conserving space on an options screen. This is primarily because all of the available options are nested on top of each other, rather than being displayed sequentially. The implementation of a spinner was crucial for this app as it is used to identify which cuisine the user is looking for. This implementation led onto needing to investigate how a button can load a new activity along with a critical piece of information. The information needed to be sent to the new activity as the users chosen cuisine. This investigation would contribute to the rest of the apps development as there are multiple activities that need to be loaded within the app and have important information fed from one activity to another. This research also yielded crucial information on intents, which calls a new activity to be brought to the front, and putExtra which is used to send a piece of information by attaching a key to it. This key would then be used in the new activity to receive the original piece of information. The exploration into the Google Maps API enabled the new activity, which takes in the chosen cuisine type, to integrate a Map Fragment which the Google Maps API would interact with. Further research detailed that this would require updates to the Android Manifest, along with the activities layout XML file. During this exploration of the Google documentation, it unveiled valuable information on troubleshooting the Google Maps API if any unexpected errors should occur. In addition to this, it was revealed that personalised API keys were necessary to help Google identify which app was attempting to send requests, and receive information. These API keys were generated by combining the SHA-1 hash value, with the Android apps package name. The integration of Google Maps within the Map Fragment encourages research into creating identifiable markers which will be used cumulatively with the Google Places API. The desired result would therefore be to create a new
5. 5. pg. 4 icon, or change the colour of the default markers fashioned by Google. This directed research into BitmapDescriptorFactory which can be used to adjust the visuals of a Google Maps marker icon. However, this research was not deemed a high priority as it only enhances the aesthetics of the app, along with only been usable on one activity. In addition, this different marker was implemented to help the user identify themselves and their current location, to all of the result markers sent from the Google Places API. The following step was to analyse the Google Places API documentation to identify how this can be integrated to work in synergy with the Map Fragment, and the Google Maps API. This analysis covered how to implement the Google Places API code into the relevant class, how the HTTP request was constructed, and possible means of filtering the results that were received back from Google. The code used which executed the Google Places API call was copied across from an online tutorial which detailed each step necessary to complete this section of my app (Smith, 2013). The next investigation was to check how the AutoCompleteTextView could be implemented into the app, which would allow the users to search for a specific restaurant by name, rather than by proximity to the users location. This tool would be beneficial to a user as it allows them to show a friend a restaurant that they visited recently. This was achieved by using a GooglePlacesAutoCompleteAdapter which provides a list of predictions based on what the user has entered in to the text field. This research has identified that for this service to work, the user must have typed at least three characters before the predictions start populating results. This research also brought to light how these predictions can be filtered based on the type of results that the app is looking for. The types of filters that can be applied can be found on the Google Places API Types webpage (Google, 2011). Optimisation The Android Lint is a new tool introduced in ADT 16 which scans Android project sources for potential bugs. These potential bugs may include missing translations, performance problems, unused resources, inconsistent array sizes, and usability problems (Google - Android, 2012). This tool which is integrated into the Eclipse development environment was used within this project which identified multiple bugs such as missing translations, and inconsistencies with icons and images within the drawable files. Other attempts of optimisation have included using certain data structures over others, removing any unnecessary objects or instantiated variables that werent in use, using static and final parameters where available, attempting to avoid internal Getters/Setters, and using known libraries. The importance of using the correct data structures is that each instantiation may require unnecessary objects being created. An example of this would be between creating a Map object when compared to creating a SparseArray. The difference between these two objects is that the Map object creates an Integer value which may not even be used within an Android app. Map map = new HashMap(); SparseArray map = new SparseArray(); map.put(1, "Hello"); (Vogella, 2014)
6. 6. pg. 5 The use of removing any objects that are created is an obvious way which can be used to increase the performance of an Android app. This is because it prevents the need for an object to be created which saves memory from being unnecessarily allocated. Any variable or object that is instantiated will take up valuable memory space even if the object or variable has not been assigned a value yet. This can be identified by looking at the stack print out from the JVM or Android device (Kiparsky, 2014). The next optimisation to attempt is to use the static and final parameters on an objects creation. The use of static should be used when an object is not accessed from outside of this scope. This can be seen as increasing performance of an Android app up to 20% faster whilst also indicating from a methods signature that the method cannot be used to alter an objects state (Android, 2012). The use of the final parameter is to indicate that a variable is constant, meaning that the value of that variable or object is unchanging. This is because all constants are stored within a dex file1 which will save constant values directly instead of using a field lookup (Android, 2012). //before int a = 3141; //Value a can be changed //after static final int a = 3141; //Value a is constant and cannot be changed These constant variables are necessary to be regarded as static otherwise the Java compiler will allocate memory for a constant in every object of that class: if there are multiple instances of a variable or object, then it cant be constant. This can be followed by avoiding the use of Getters/Setters which can be a very expensive process within an Android device. This is because these are classed as virtual methods2 which are even more expensive then instance field lookups. As these are so expensive, it is much better to directly access the variable or object then attempting to access through virtual methods. The developers page on the Android website indicates that these calls could be up to seven times quicker accessing a value directly rather than through these virtual methods. The last potential optimisation is to favour the use of libraries since the JIT may not be able to produce as efficient code than a library call can. The examples of this provided to Android developers are the use of String.indexOf() with the related APIs which Dalvik replaces with inline intrinsic and the use of System.arraycopy() (Android, 2012). 1 A dex file is the compiled Android application code (Dalvik Executable). 2 A virtual method is when a Java application executes a method which is determined by the object type in runtime
7. 7. pg. 6 Compatibility This section highlights how aspects of this app has been designed for various devices, which may be running different versions of the Android operating system, and screen sizes. The most notable feature and implementation of this app, in terms of dealing with different screen sizes, are that any icons used within this app have been created within all of the drawable folders which are designed to contain these icons. The difference about each folder is that the images contained in each folder are scaled differently depending on the size and resolution of the Android device on which this app is being executed on. The chosen platform version for this app was Android 5.01, API 21, with the release name of Lollipop. This version was chosen because it is the second latest API version which will mean that it will contain the most up-to-date features, whilst being released long enough to have most of the bugs and issues with it to be patched already. Since the Android market has a varied audience with a recorded consensus of only 0.4% of Android users running Froyo and 7.4% running Gingerbread (as seen on the left), the opted minimum target SDK version was set to API 14, Android 4.0 Ice Cream Sandwich. API 14 was chosen since it will enable the vast majority of users to be compatible with this app, whilst not restricting the app in terms of usable code and style too much. Gestures This app does take advantage of the use of gestures within the GoogleMap activity which the vast majority of users will be familiar with, and be happy to use. These gestures include rotating the map, zooming in and out, and changing the pitch of the map (these can be seen below). These gestures are available from the Google Maps API which provide the same usability and function that someone would have when using Google Maps on a desktop or laptop machine, or via a browser. Figure 1: Android Version Distribution (Mick, 2015) Figure 2: Gestures within Google Maps (Scilligence, 2015)
8. 8. pg. 7 Mobiles in Context This section focuses on how this app was developed with the mobile constraints considered to ensure that the user would be able to use to app and use all of its functionality. These constraints include screen size, along with reachable areas, performance, and time and place. This section will also include how certain functionality is implemented and what requirements need to be met for them to work. The importance of screen sizes has already been identified within the Compatibility section of this report but this can be furthered to identify what constraints this will have on the app. Screen sizes can vary a lot for Android devices which makes the effective use of text to be crucial, the amount of text needs to be kept to a minimum otherwise the user will have to keep on scrolling, or for the text font size to be smaller. This would not be good in terms of accessibility for any user with any kind of visual impairment. In addition, the interfaces would have to be kept simple so the user can quickly identify how each activity works, and that these activities focus on a single function. The simplistic design required for an Android app is required so that it follows the Android Standards and Convention which will allow any user to be able to this app with minimal experience with it due to the interoperability of these standards. The amount of resources available for any given Android device can be regarded as limited when compared to the quantity of resources available on a desktop or laptop machine. The development of any Android will need to have this as a crucial consideration as this performance criteria can affect the overall use of the app. This will require the programmer to take into account the amount of memory allocation that their app will require, overall performance3 , layout performance, battery life, use of multiple threads and app responsiveness. Memory allocation works differently within the Android operating system than that of a Windows operating system. This is because within Android, any memory you modifywhether by allocating new objects or touching mmapped4 pagesremains resident in RAM and cannot be paged out. So the only way to completely release memory from your app is to release object references you may be holding, making the memory available to the garbage collector (Android, 2012). In terms of battery life, the app needs to be able to run multiple times for short activities, or a long-time for a single activity without having any major input on the deprecation of the Android devices battery life. In terms of Just Dine, the app will be ran multiple times in short bursts, as its main function is to identify what restaurants are nearby which wont take a lot of time to achieve, unlike a gaming-styled app used to waste a bit of time. The benefit of multi-threading an Android app is that the CPU provided on Android devices have a slower clock frequency than that of desktop and laptop machines, but still contain multiple cores. For an app to achieve its performance potential it is imperative to take advantage of multi- threading which will increase the performance and responsiveness by allocating processes onto multiple cores. 3 This has been covered within the Optimisation 4 Abbreviation meaning memory-mapping
9. 9. pg. 8 Screen Captures Figure 3: Just Dine Landing Page Figure 4: Nearby results for 'Chinese'
10. 10. pg. 9 Figure 6: Settings Activity Figure 5: Extended radius and hybrid map type
11. 11. pg. 10 Figure 8: Advanced search predictions Figure 7: Advanced search result
12. 12. pg. 11 Figure 9: The About page for this app
13. 13. pg. 12 Evaluative Summary This section covers my personal reflection on the progress and overall outcome of this project, along with any improvements or changes that I would make if this project had to be repeated. This evaluative summary will begin with critically analysing the main aspects of this project, which is followed by the Methodology of the project. This will progress into what has been learned throughout the duration of this project, and any issues that have been encountered and how they have been overcome. Critical Evaluation This section will cover the critique of all the significant portions of my project, including the reason for choosing this project over other ideas. This idea was chosen as it involved implementing multiple APIs into this project which is incredibly beneficial for learning how different APIs work and function. The first main important fragment undertaken was the necessary research required to get the basis of this project functioning. The necessary research required researching the basics of using Google APIs and integrating this functionality into this app. The next critical section involves the implementation of the Google Maps API into this project along with the Map Fragment: this will be followed by the evaluation of the Google Places API implementation. The last critique will be made of the GPS tracking service used within this project. The next main important undertaking was to research the implementation of the Google Maps API. This included reading through the Google Maps documentation and following a video tutorial which provided a step-by-step guide for adding Map Fragments and linking it to the Maps API. The video tutorial that was used was uploaded by a user named DrBFraser and can be found at this link: https://www.youtube.com/watch?v=awX5T-EwLPc. The next two aspects of this critical evaluation involves the Google Maps and Places API. These APIs were the first choice as they have greater supporting documentation, plus a larger community base. The other possibility was to use the OpenStreetMap API which is a free geographic data service similar to the Google Maps API. The decision to choose the Google API over OpenStreetMap was based on multiple factors including the prominence of Google over OpenStreetMap, and the similarity of the Google Maps API and the Google Maps service online which will increase usability. In addition, the Google Maps API allows integration into the Maps application on any Android device which will plot out the necessary route from the users location to the restaurants location. The GPS tracking service used in this project was implemented from a tutorial which will be placed within the references section. This tutorial was selected as it provided step-by-step instructions for fully implementing this class into your current project. The lint process identified that this activity was incorrectly marked as this class is deemed a service rather than an activity. This would have been better if the implementation of GPS tracking was not sourced by someone else, but it is common for code to be re-used, if proper reference and accreditation goes to the right people. Methodology The methodology used within this project has produced a working app that successfully shows the users position along with the responses from the Google Places API service. As well as this, the user can successfully search for results by a restaurants name instead of performing a standard nearby search. The main downfall of this project is that a route could not be generated on the Map Fragment since this service is not provided by the Google Maps nor Google Places API. On the other hand, the Map Fragment has an integrated function to feed the coordinates of both the user and the chosen destination into the Google Maps app installed on an Android phone which successfully plots out the route on to the Map Fragment. In addition, this functionality allows the users position to be updated which will also update the route required to reach their destination. This functionality has been implemented using the
14. 14. pg. 13 LocationManager which will attempt to update the users position based on two different factors, these being distance or time. This means that the users position would be updated if they travelled enough distance or enough time has passed since the last previous update. The planning stage for this project produced a Time-Gantt chart which was primarily created for tracking the progress of this project, to determine if the project is running on-time, ahead, or behind schedule. As expected for the initial plan, the schedule was not kept to, and changes were necessary to produce a more realistic time frame that could be kept to. The main issue with the initial Time-Gantt chart is that the main development along with the sections for implementing improvements were too short which did not provide enough time for these stages of the project to completed successfully. Furthermore, the initial plan had many detailed steps but the actual schedule was much less detailed. This simply resulted from the development schedule taking up the vast majority of this projects duration. What I Have Learned This section covers the main learning aspects of this project, including the implementation of code but also information that have been gathered through research, but not necessarily added into this project. Below is a list of all of the main learning points that have been identified during this project: How to create multiple intents and feed through information by using putExtras How to implement a Map Fragment that interacts with the Google Maps API How markers can be placed onto the Map Fragment, both dynamically and statically How Google Places can be used to provide a nearby or detailed search The benefits of using SharedPreferences over variables Problems Encountered There were a number of challenges that were necessary to overcome, both in terms of the research required and the limitations based on the Google APIs, and unforeseeable events such as system crashes and corruption. The first challenge that was necessary to overcome was to enable any Android device to connect to the Eclipse IDE. This issue was caused by every Android device having a different device driver, and identifying the correct driver which is compatible with the Google USB driver downloaded from the Android SDK. This resulted in all testing being performed on an LG Nexus Android device as this devices drivers were compatible with this Eclipse environment and more reliable than any other devices. The next problem faced was establishing how the Google Places API integrated into the development of the app. This was an issue because the two API services Maps and Places require different types of API key for the Map Fragment and the Places integration; the Maps API requires an Android specific key whereas the Places API requires a browser specific key. These different keys also require a different form of implementation, as the Maps API key must be implemented within the Android Manifest, whilst the Places API key needs to be implemented within the java code. The next issue was very fatal which was caused by corruption of the MBR which required a format, and fresh install of the Windows Operating System. This setback caused delays within the development of the app along with the research required to succeed in each part of this project. This issue caused the same driver compatibility issue to be faced, and the attempt to recover any lost information. The Eclipse workspace was being automatically uploaded onto cloud storage to mitigate any loss of information caused by hard drive failure, or corruption. Another complication that had to be dealt with was caused by issues with the Google APIs connected with the Google Mail account linked up with this project. The reason for this is still unknown as the valid API key was working initially
15. 15. pg. 14 but its status changed from Active to Activation end-date which seemed to occur unprovoked. This was corrected by removing all of the API keys that were linked to this project, and re-instantiating a new key for Android devices and Browser access, which created new generated keys. Future Extensions This section covers any future extensions that would be beneficial to the users of this app including improved accessibility for visually impaired users, detailing more information on the places search, and to increase the responsive feedback to the user. The need for more accessibility options are necessary to ensure that everyone can use this app comfortably and without any strain on their eyes. The potential improvements that will be focused upon are allow the user to increase and decrease the size of all fonts within this app, add in a colour-blind option that will attempt to provide an easier to view colour scheme. These extra options could be added into the settings activity, or could be separated into its own accessibility tab to help the users identify that this app takes accessibility as a consideration. This can be regarded as a high priority extension as it will allow a larger audience to use this app, along with being seen as considerate within the mobile app development community. The next extension that is being considered is to provide more details for each place marked out on the GoogleMap activity. This extra information would include a rating, photos as well as Googles summary of the restaurant which will be obtained via the Google Places JSON response. The rating will be useful for users of JustDine as it will detail what other customers have said or felt that restaurant which may affect the users decision of going to that selected restaurant. The use of the photos will help allow the user to identify the restaurant that theyve selected, whilst the Google description can give a brief overview of what the restaurant is actually like. This extra information could be provided to the user through the use of OnInfoWindowClickListener which is a listener provided by the Google Maps API. This can be used by calling a new activity which will be used to dynamically change its text, rating and images depending on the location that the user has selected. When the user first selects a restaurant marker, a little information window is shown detailing its name and address. The user can then press it again which will call the OnInfoWindowClickListener which can either pass all of the information as a putExtra or by recalling the Places API response for the individual location based on its id. This should be manageable as the AdvancedSearch activity performs a search on ids to locate the specific restaurant being searched for. This extension would be given a medium priority as the implementation of this would provide more useful information to the user, but the extensions that increase usability should be prioritised higher than other extensions. In addition to this, the app works perfectly without this extension, as all of the necessary information for a user to find this restaurant is provided, and the user can feed the restaurants location into the Maps app provided on every Android device to plan out the quickest route to the restaurant. The JustDine app does provide feedback to a number of issues that may occur during the use of this app such as having no internet connectivity or the Android device needs to update its Google Play Store. However, this app doesnt provide any responsive feedback to the user when its processing the Google Places API response, meaning that on a slow Wi-Fi connection or having a poor mobile data signal, the app may appear to be unresponsive. This issue has been provided a low priority as, in the vast majority of cases, the location markers have been placed instantly or within a negligible amount of time. A feedback mechanism could be put in place, such as a spinner or a loading bar, which will aid the app in portraying that its processing information, whilst indicating that the app isnt unresponsive. The way that this could be achieved is by placing an overlay on the GoogleMap activity which will cause this loading spinner or bar to be shown until the activity is ready for both nearby searches or an advanced search.
16. 16. pg. 15 References Android, 2012. Managing Your App's Memory | Android Developers. [Online] Available at: http://developer.android.com/training/articles/memory.html [Accessed Friday, 22nd May 2015]. Android, 2012. Performance Tips | Android Developers. [Online] Available at: http://developer.android.com/training/articles/perf-tips.html [Accessed Wedensday, 20th May 2015]. Google - Android, 2012. Android Lint. [Online] Available at: http://tools.android.com/tips/lint [Accessed Monday, 11th May 2015]. Google, 2011. Places Types - Google Places API. [Online] Available at: https://developers.google.com/places/supported_types#table3 [Accessed Monday, 30th March 2015]. IQ Agency, 2012. Mobile Web vs. Native Apps. [Online] Available at: http://www.slideshare.net/IQ_Agency/mobile-web-vs-native-apps [Accessed Thursday, 21st May 2015]. Janssen, C., 2011. What is the Mobile Web? - Definition from Techopedia. [Online] Available at: http://www.techopedia.com/definition/23588/mobile-web [Accessed Thursday, 21st May 2015]. Kiparsky, J., 2014. Do unused local variables in a method acquire memory in JVM?. [Online] Available at: http://stackoverflow.com/questions/26632799/do-unused-local-variables-in-a-method-acquire- memory-in-jvm [Accessed Wednesday, 20th May 2015]. Mick, J., 2015. DailyTech - Android Lollipop Has Less App Creashes Than iOS8, Says Study. [Online] Available at: http://www.dailytech.com/Android+Lollipop+Has+Less+App+Crashes+Than+iOS+8+Says+Study/article37158.htm [Accessed Wednesday, 20th May 2015]. Smith, S., 2013. Android SDK: Working with Google Maps - Displaying Places of Interest - Tuts+ Code Tutorial. [Online] Available at: http://code.tutsplus.com/tutorials/android-sdk-working-with-google-maps-displaying-places-of- interest--mobile-16145 [Accessed Monday, 23rd March 2015]. Vogella, 2014. Android memory and performance optimization. [Online] Available at: http://www.vogella.com/tutorials/AndroidApplicationOptimization/article.html#androidperformanceandmemoryop timization3 [Accessed Wednesday, 20th May 2015].
17. 17. pg. 16 Appendix Appendix A Original Time-Gantt Chart Task Name Duration Start Finish Predecessors Milestone Phase One 0 days Mon 01/12/14 Mon 01/12/14 Yes Feasibility Check 3 days Mon 01/12/14 Wed 03/12/14 1 No Identify Requirements 5 days Thu 04/12/14 Wed 10/12/14 2 No Phase Two 0 days Thu 11/12/14 Thu 11/12/14 1,3 Yes Create Wireframes 5 days Thu 11/12/14 Wed 17/12/14 4 No Research Implementation Techniques 10 days Thu 18/12/14 Wed 31/12/14 5 No Identify APIs required 5 days Thu 18/12/14 Wed 24/12/14 5 No Submit Conceptual Report 17 days Thu 01/01/15 Fri 23/01/15 6,7 No Implement First Draft Design 30 days Mon 26/01/15 Fri 06/03/15 8 No Testing functionality and usability 3 days Mon 09/03/15 Wed 11/03/15 9 No Add Improvements 10 days Thu 12/03/15 Wed 25/03/15 10 No Phase Three 0 days Thu 26/03/15 Thu 26/03/15 11 Yes Ensure working functionality 3 days Thu 26/03/15 Mon 30/03/15 12 No Phase Four 0 days Tue 31/03/15 Tue 31/03/15 12,13 Yes Create First Draft Report 10 days Tue 31/03/15 Mon 13/04/15 14 No Create Second Draft Report 10 days Tue 14/04/15 Mon 27/04/15 15 No Submit Finalised Version 20 days Tue 28/04/15 Mon 25/05/15 16 No Figure 10: Graphical Time-Gantt Chart