In this topic
Mobile mapping application issues
This topic describes the issues encountered by mobile mapping applications written with the ArcGIS Runtime SDK for Android and what to consider when designing map layer types to use in your application. The Layer types topic contains more detailed information on the available map layer types.
On mobile devices where you have limited resources and variable network speed (see below) it is advisable to perform long running tasks on a background thread. The Android system guards against unresponsive apps by showing "Application Not Responding" or ANR dialogs, these should be avoided at all costs, more information can be found in the Android guide here. The design of the ArcGIS Runtime SDK for Android has taken this into account and implemented a number of asynchronous methods which put tasks on a background thread for you (noticeable as they commonly return a java Future and take a Callback as a parameter e.g Locator.find() ) but a lot of other methods provide only synchronous calls that you will need to handle yourself. However, since threads consume device resources, you still do need to pay particular attention to minimizing the amount of threads that are created.
Android mobile devices often use 3G or sometimes lower speed radio communication networks to obtain and transfer data. The speed of these networks vary but are much slower (in terms of data per second) than wired or wireless networks. Due to this network latency, small requests can take time to return, which makes your application seem sluggish. Therefore, you need to carefully manage the total amount of data and the number of network requests submitted by your Android application. As an example, it may be more efficient to send a single large request for data rather than multiple small requests. Changing the layer types, application functions, or the flow of your application can also affect network speed.
If your mobile application users are always in the range of a wireless network, your application can retrieve and submit larger amounts of data. However, even in this scenario, it's always good practice to remember the amount of data and number of requests your application uses, whatever the bandwidth.
By understanding the characteristics of the different types of map layers in the API, you can determine the best layers for your needs and ensure that your application performs for your users.
Some application users may only have intermittent network access, such as intermittent 3G access due to working in remote areas or daily access to a wireless network for synchronizing data. If this is the case, local storage usage is important. The application can be designed to connect to the server to retrieve data the user needs, then store this data on disk or in a local SQLite database. Applications need to be developed robustly with this in mind, because the network connection can be dropped anytime. Functions need to fail gracefully, and any long running application transactions may need to be rolled back.
Analyzing these issues in Android
There are various debug tools provided by the Android software development kit (SDK) that can help analyze these issues in more detail. SDK tools exist for profiling memory, and viewing thread and network activity. For more information, see the Debugging section in the Android Developer Guide.
What do you want from your data?
There are two things to consider when designing the data layers for your application. First, what functionality do you need to provide to your users? The different layer types have different functional characteristics, which are explained in more detail in the Layer types topic. Second, what are the performance characteristics of the data layers? This is also described in the Map layer types topic. You may need to prioritize one of these issues and compromise the other, because often the layer's characteristics conflict with performance. For example, the layer that gives you the best functionality may be the slowest to perform in your scenario.