When designing an application for mobile, the developer must consider the constraints the device imposes and decide what type of application framework is best for a given project.
Understanding Mobile Device Limitations
Applications are expected to be fast, responsive, and stable, but developers must work with limited resources. You must keep in mind the memory and processing power constraints of all target devices when designing and developing mobile applications.
Exploring Common Mobile Application Architectures
Mobile applications have traditionally come in two basic models: stand-alone applications and network-driven applications.
Stand-alone applications are packaged with everything they require and rely on the device to do all the heavy lifting. All processing is done locally, in memory, and is subject to the limitations of the device. Stand-alone applications might use network functions, but they do not rely on them for core application functionality. An example of a reasonable stand-alone application is a basic Solitaire game. A user can play the game when the device is in Airplane Mode without issue.
Network-driven applications provide a lightweight client on the device but rely on the network (or “the cloud”) to provide a good portion of its content and functionality. Network-driven applications are often used to offload intensive processing to a server. Network-driven applications also benefit from the ability to deliver additional content or functionality on-the-fly long after the application has been installed. Developers also like network-driven applications because this architecture enables them to build one smart application server or cloud service with device clients for many different operating systems to support a larger audience of users. Good examples of network-driven applications include
- Applications that leverage cloud-based services, application servers, or web services
- Customizable content such as ringtone and wallpaper applications
- Applications with noncritical process and memory-intensive operations that can be offloaded to a powerful server and the results delivered back to the client
- Any application that provides additional features at a later date without a full update to the binary
How much you rely on the network to assist in your application’s functionality is up to you. You can use the network to provide only content updates (popular new ringtones), or you can use it to dictate how your application looks and behaves (for instance, adding new menu options or features on-the-fly).
Designing for Extensibility and Maintenance
Applications can be written with a fixed user interface and a fixed feature set, but they need not be. Network-driven applications can be more complex to design but offer flexibility for the long term—here’s an example: Let’s say you want to write a wallpaper application. Your application can be a stand-alone version, partially network-driven or completely network-driven. Regardless, your application has two required functions:
- Display a set of images and allow the user to choose one
- Take the chosen image and set it as the wallpaper on the device
A super simple stand-alone wallpaper application might come with a fixed set of wallpapers. If they’re a generic size for all target devices, you might need to reformat them for the specific device. You could write this application, but it would waste space and processing. You can’t update the wallpapers available, and it is generally just a bad design.
The partially network-driven wallpaper application might enable the user to browse a fixed menu of wallpaper categories, which show images from a generic image server. The application downloads a specific graphic and then formats the image for the device. As the developer, you can add new wallpaper images to the server anytime, but you need to build a new application every time you want to add a new device configuration or screen size. If you want to change the menu to add live wallpapers at a later date, you need to write a new version of your application. This application design is feasible, but it isn’t using its resources wisely either and isn’t particularly extensible. However, you could use the single application server and write applications for Android, iPhone, BREW, J2ME, and Blackberry clients, so we are still in a better position than we were with the stand-alone wallpaper application.
The fully network-driven version of the wallpaper application does the bare minimum it needs to on the device. The client enables the server to dictate what the client user interface looks like, what menus to display, and where to display them. The user browses the images from the application server just like the partially network-driven version does, but when the user chooses a wallpaper, the mobile application just sends a request to the server:“I want this wallpaper and I am this kind of device, with such and such screen resolution.” The server formats and resizes the image (any process-intensive operations) and sends the perfectly tailored wallpaper down to the application, which the application then sets as the wallpaper. Adding support for more devices is straightforward—simply deploy the lightweight client with any necessary changes and add support for that device configuration to the server. Adding a new menu item is just a server change, resulting in all devices (or whichever devices the server dictates) getting that new category. You only need to update the client when a new function requires the client to change, such as to add support for live wallpapers. The response time of this application depends upon network performance, but the application is the most extensible and dynamic. However, this application is basically useless when the device is in Airplane Mode.
Stand-alone applications are straightforward and great for one-shot applications and those that are meant to be network-independent. Network-driven applications require a bit more forethought and are sometimes more complicated to develop but might save a lot of time and provide users with fresh content and features for the long run.
Designing for Application Interoperability
Mobile application designers should consider how they will interface with other applications on the device, including other applications written by the same developer. Some issues to address are
- Will your application rely on other content providers?
- Are these content providers guaranteed to be installed on the device?
- Will your application act as a content provider? What data will it provide?
- Will your application have background features? Act as a service?
- Will your application rely on third-party services or optional components?
- Will your application expose its functionality through a remote interface (AIDL)?