Writing Mobile Code Essential Software Engineering for Building Mobile Applications [Electronic resources] نسخه متنی

Standalone or Part of a Larger System?

A basic question to be answered is how your mobile device application relates to other applications. A mobile application can be a standalone application, a part of a suite of focused on-device applications, or the portable part of a larger distributed system.

Standalone Applications

A simple game or calculation program may be a standalone application. Standalone applications interact with no other applications and only provide users with a fixed set of quickly accessible features. If this is the case, your application will be relatively simple to scope. Even in this case some refinement may be required. For example, a calculator that enables you to quickly add, subtract, divide, and multiply numbers will have a significantly different focus than an algebraic equation solver and graphing calculator. These applications are likely to have significantly different user interfaces and navigation models. Users will have different things they want to accomplish in 20 seconds with each application, and this requires a different design focus. Even in small standalone applications, proper scope is important.

Suites of Related Applications on a Device

Most interesting applications interact with other systems. In some cases, instead of having a single large multifaceted application you may want to have a set of applications on the same device that share data in an on-device database. Each application can have its own focus and concentrate on excelling at achieving its goals. In cases where a suite of applications is being constructed to work on shared data, it is important to outline exactly what each application does and does not do. A good example of this partitioning on the desktop is the relationship between the members of an office suite. An office suite typically contains software for word processing, software for calculating (spreadsheets), software for presentations, and software for communications. These interact in many ways and can share data and common components, but rarely is there confusion as to which software application should be used for any given task. Some people may think that the individual office applications themselves may be too complicated and lack focus, but imagine what would happen if they were all combined into one "super application." It would be a mess. Small and focused is beautiful.

If you have discrete tasks that need to be performed on a mobile device, it often makes sense to break these up into separate applications instead of building one giant kitchen sink, salad maker, and barbecue of an application. These compound-purpose applications are difficult to navigate and hard to maintain. It needs to be obvious to the end user what tool to use for any given task. In cases where there is confusion of purpose between applications in a suite, it is usually the product of incomplete or incremental design where a new set of needed capabilities are identified and addressed in an ad hoc way by modifying existing applications rather than thinking about the features systematically. If a new "killer scenario" emerges during your mobile application development, ask yourself whether this scenario should be grafted onto the existing application or realized cleanly in a separate application. It is easy to merge applications together but difficult to tease interwoven code apart. When in doubt, start it as a separate application and remember the 20-second rule: Users should be able to take the mobile device out of their pocket and easily navigate to their desired information in 20 seconds of unhurried device operation.

Device Applications That Interact with Desktop or Server Applications

Many device applications interact with off-device resources such as data present on a desktop computer, available on a corporate server, or exposed as an Internet service. There are two important things to keep in mind when defining the scope of mobile applications that are part of larger systems:

Identify the key set of on-device scenarios.
Usage scenarios for desktop and Web applications differ significantly from mobile device usage scenarios. For this reason, it rarely makes sense to take the set of features in a desktop or Web application and transfer them to mobile devices. It is important to ask these questions: What are the things that the users of this application will need to do quickly when mobile? What are the key things that users need to find or accomplish quickly that will compel them to take the device out of their pocket? The answer to these questions will define your mobile application's usage scenarios.

Identify whether the device will interact with desktop data or server data.
For large applications, often copies of data are scattered everywhere. Data may live on a number of servers, data may live on desktops, and data may live on devices. It is important to have a clear vision of what data your mobile application will interact with. When given the choice between interacting with data on a server and data on a desktop, the correct answer is almost always to interact with server-based data. There are two reasons for this: (1) The data on the desktop is usually a local cached copy of the server data and will be less current, and (2) although desktop computers may not always be accessible, servers are designed for accessibility. Usually when a decision is made to have a mobile device synchronize with desktop-based data rather than server data the decision is done for short-term tactical reasons rather than for well-considered strategic reasons. Typical of short-term rationalizations are statements such as "Because I can't get permission to access the server data from a device, I'll just build a model that synchronizes with a desktop copy of that data" or "The server data is too complex to deal with, but the data on the desktop is all stored in a simple format so I'll just synchronize with that data." These urges should be resisted. If the data truly does live on the server, you should synchronize with that data even if you need to build an intermediary server solution to support accessing the data. Having a clean architecture for interacting with other tiers of your application will pay rich dividends in reliability and development time. Short-term tactical solutions tend quickly to turn into long-term maintenance nightmares. Understanding the scope of your mobile application requires being able to draw a clear diagram that shows the interactions your mobile data has with off-device systems.