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

Reliability Requirements

With regard to reliability requirements, mobile devices paradoxically resemble servers more than they do desktops. The reasons for this are as follows:

Much like servers, mobile devices and their applications are often left running 24 hours a day, 7 days a week.
Cell phones and PDAs are often left running all the time or have standby modes that ensure that when they start up they come up in a state that closely resembles the one they were last used in. Although desktop computers are also increasingly left on all the time, users still reboot them, log on and off occasionally, and start and shut down applications fairly frequently; this causes improperly held system resources to periodically get flushed. In contrast, because the applications on mobile devices are meant to be "instant access," the applications are often left running in a background state so that they do not need to incur startup delays and users can pick up where they left off with the applications. For these reasons, devices resemble servers in that they need to sit ready to provide instant services for their clients.

Much like servers, mobile device applications have to deal effectively with unexpected failures.
Mobile devices operate in a demanding environment. Communications failures occur often and midstream. Users think nothing of popping the battery out of the back of a mobile phone midstream if they are running low on power or think the device is behaving in an awkward way. The operating system itself may shut down a background mobile application if it is running low on resources. Worse still, devices get lost, are stolen, are dropped into puddles, and suffer all means of cruel and unusual punishment at the hands of their users. Even with this, users are devastated when their mobile phone disappears or stops working and they realize that they had important and hard-to-replace information on it. For all these reasons, mobile applications, like mission-critical servers, need to make sure that the important data and state they are managing is held in longer-term storage that can survive the application unexpectedly vanishing or failing. Mobile application developers need to think like mission-critical server application developers and ensure that data important to users is stored safely and in a form that can be recovered if data corruption occurs due to sudden failure. Developers should also consider enabling appropriate backup measures to allow automatic off-device archives that enable users to recover from catastrophic loss of important information; users rarely back up their own important data even though the need to do so should be obvious.

Much like servers, mobile device operating systems and applications often do not use memory paging files.
Your desktop computer probably has a large paging file set up by default that enables it to swap out memory not being used to a file on disk. This file is called a memory paging file or a swap file. If new memory is requested by an application because it is starting up or because it has additional memory needs and the system is running low on physical memory, the operating system will swap out pages of memory that have not recently been used to a file on disk. If the paged-out memory is later accessed, it is swapped back into memory and other pages are swapped out as needed. In this way your desktop computer can function as if it has a much larger amount of RAM than it actually does. This is intended to enable users to run many applications simultaneously while keeping the one in the foreground as responsive as possible. It also allows leaked memory to be relatively harmlessly swapped out to disk on the grounds that the application that is leaking memory will probably be shut down before its leak becomes so large that it consumes all of the page file memory. Servers tend not to use this strategy because they are designed for maximum throughput. A server wants to keep everything in physical memory where it can be accessed quickly. Devices tend not to use page files because they do not have huge disk drives onto which they can quickly swap in and out pages of memory. Having this capacity on a device would be prohibitive from expense, size, speed, and power-consumption perspectives. You may object that "in theory memory could be swapped to some kind of flash memory on a device"; however, this is not practical because writing to flash is not quick and is not intended to be done over and over again in rapid succession.

Many mobile devices serve other critical purposes while running foreground applications.
If a mobile phone ceases to work as a mobile phone because your application crashes, drastically slows down in responsiveness, blocks the user interface, or otherwise misbehaves, the end user will not be very happy. Most mobile operating systems have levels of protection to guard the critical functions, but your application is certainly capable of making the device less useful for its other functions if it misbehaves. In server terms, this would be known as a "denial-of-service" problem. Like servers, many devices need to manage a series of critical services that must be available for users at all times.

For these reasons, it is important that your mobile device application be able to run reliably and efficiently over long periods of time.