Performance Factors
To supplement the general enterprise GIS performance factors listed under Application Performance Considerations, this section summarizes typical performance factors impacting Mobile Applications.
Utilizing mobile devices requires that you consider limited CPU speed, reduced memory and storage, narrow bandwidth and high latency connections, and limited battery life.
Consider the following guidelines:
- Design configurable options to allow the maximum use of device capabilities. Allow users to turn off features they do not require in order to save power.
- To optimize for mobile device resource constraints, consider using lazy initialization.
- Consider limited memory resources and optimize your application to use the minimum amount of memory.
- Consider power consumption when using the device CPU, wireless communication, screen, or other power-consuming resources while on battery power. Balance performance with power consumption.
Tuning and Optimization
It is extremely important that you carefully consider what is and what is not supported within the geodatabase information and transactional models when determining how best to support field editing applications with ArcGIS Mobile.
When deploying mobile solutions for the enterprise you need to aware of:
- Information workflows
- Technology platforms and protocols
- Expected user loads and demands
- Best practices and patterns including real time requirements and data update posting requirements,
Information Workflows
Access maps on-demand using location
- Ideal for thumbnail datasets
- Optimized map layers streamed over wireless
Devices are pre-loaded with maps
- Ideal for large deployments over large geographies
- Put in place 3rd party software to manage workflow
Data Update and Posting
The updates that you perform in the field are stored locally in the mobile service cache on the mobile device. This is important because your field-workers may not be connected in the field at all or they may need to shut down and charge their devices, and it is important that updates are not lost. When connectivity with the server is established, you can then synchronize updates stored in the cache with the server.
When posting changes from the mobile device, only deltas are sent to the server. For example, if you change an attribute on a feature, only the change to that specific field is recorded rather than marking the entire row as edited. This is done so that when synchronizing changes, only the information that has actually changed is sent back to the server. When synchronizing updates in the field, bandwidth and storage must be conserved whenever possible.
Depending upon the amount of edits you expect and the type of server connection you have (GPRS, for example), you may want to only enable posting features when the application and device are back in the office to ensure a stable high speed connection.
Scalability Strategy
Scalability of mobile solutions is primarily dictated by the synchronization methods used by the mobile clients to a server infrastructure. Consider whether you want to support over-the-air synchronization, cradled synchronization, or both. Even though connection interruptions may occur gracefully, either by canceling the operation or by allowing it to resume when a connection becomes available, they cause additional overhead. Standard web application server scaling guidelines may be utilized to support your mobile synchronization needs. One key option to remember with mobile solutions is the ability to stagger times of when devices are synchronized.
Related Links