iOS extracts: Handling Terminations

extracts from 《Programming the iPhone User Experience》

Handling Terminations

Developers should be careful to spend as much time focusing on their exit processesas on their launch processes. The ideal cooperative model, when applied to an appli-cation, would result in a very symmetrical curve where launch and termination are shortand engagement is immediate.

The way in which you terminate your application will probably depend on the state ofthe application and its resources. Obvious goals such as committing all pending trans-actions and freeing used memory are important, but what about preparing for the nextlaunch? Should you cache the whole screen? If so, should you go beyond the clippedarea that is visually present in order to provide for a scrollable placeholder in the future?What will your users expect? Is the nature of your application such that state persistencematters? Will the criteria depend on the frequency between launches? What if the userwaits a month to relaunch your application? What if the wait is five seconds?

The overarching goal is to make opening and closing as painless as possible and tofollow good UX and anticipate the expectations of your users.

Here are some guidelines for streamlining terminations:

• Perform as few IO tasks as possible. Saving locally will be safer than saving over anetwork.

• If saving over a network, provide an internal timeout that invalidates your requestand closes the application.

• Don’t save all persistence tasks until the termination call. Perform database orfilesystem writes when they are relevant instead of caching for one big save. Thereis a balance to find here, but if you consider event-based writes in your design, youcan make informed decisions.

• Stop any non-critical, expensive operations instead of letting them finish. If yourmain event loop is blocked, your application cannot terminate smoothly.