Mobile computing has grown hugely popular over the last several years. The growing capabilities of the mobile phones has meant that the phone has become an appealing and persuasive platform for application developers to build both consumer and enterprise applications. Today, developers have started building applications that are ubiquitous and multiscreen-capable. However, the trick is to build a mobile application that will work on phones having different software and hardware capabilities. How do you achieve this? While you have no control over the phone’s platform segmentation, you can build mobile applications following certain considerations, widely recognized as the ‘best practices’ for building mobile applications.
Here are some design considerations for building mobile applications:
- Decide on the application type. It is the high order bit! Do you want to build a native application or a Flash/AIR-based application? Whatever you decide, understand that it is very expensive to rollback this decision. Developing native application has its own benefits and shortcomings. For very trivial application, go native. For complex applications, go Flash.
- Don’t worry about the phone’s platform fragmentation. For any open system to proliferate, fragmentation is important. Do not worry if your application does not work well on some devices. Find out other ways to filter out your application from those devices.
- Storage. There is no such thing as a 1 TB SD card! Use the phone’s data memory judiciously.
- Connection and bandwidth. Understand that the users pay for every byte transmitted and received. Before you open up a data connection or before you start downloading that large piece of data from a service, warn the user.
- Tombstoning. Handle system interrupts effectively. When your application is pushed to the background, pause those game timers, disable those animations, and save the state of your application.
- Memory usage. Nothing much can go wrong here if you design your application well. Never get overwhelmed by the memory usage statistics reported by the phones. For AIR-based applications, the memory usage may also include the AIR Runtime footprint. Don’t panic if the memory usage for your AIR application is around 50 MB.
- Battery. Battery consumption is very important. If your application utilizes the hardware sensors, you may need to build an appropriate model to conserve the battery. For instance, if you are building a location-aware application, do not query the GPS sensor every few milliseconds. Also, implement Tombstoning to give those sensors a break!
- Graphics. With all those friendly IDEs and tools, anyone can build a mobile application. What differentiates your application from the ‘other’ applications is UI responsiveness and graphics. Spend more time in formulating the UI.
- Formats and Sync. If your mobile application connects to external services, understand the protocols and syncing methods. Will your application interact with a SOAP/REST-based service or an AMF endpoint? Also, understand the synchronous and asynchronous way of interacting with the remote services. How will you handle push messages? How will you sync the local data store with the remote store?
- Cloud. When you are building a mobile application that connects to the cloud, you need to understand the semantics of the cloud. The response returned from the cloud varies and it is your application’s responsibility to handle such disparities. For instance, in your application, if you are using UTF methods to read and write strings returned from a web service, your application may crash if the web service starts returning long strings. The cloud need not understand the semantics of the client but the client should understand the semantics of the cloud! Also, the cloud provides resilience, elasticity, and performance for your mobile applications. Always build applications that are controlled by the cloud.
- Finally, do not just build applications. Build solutions.