Mobility
Home » Mobility » Mobile Innovations

Interrupt handling (m-cube: Level 1)

Posted by Amitabh Srivastava | Nov 25, 2010 | (0) | Add a Comment  |   Bookmark and Share
I think interrupt handling is one of the crucial parts of any mobile solution.
So many times it happens that while running a mobile app, there are interruptions such as an Incoming Calls, Text Messages, low memory or a low battery notification. A good mobile solution must be able to handle these notifications gracefully… and without any disruption. Few of the important aspects to be considered here are
 • Application suspend and resume should be handled properly especially for incoming calls and
   Text Messages.
 • The UI and media, such as images, sounds, context pointers should be released on SUSPEND
    event.
 • Low memory notification should be given highest priority and unused memory should be release
    immediately.
 • Suspend routine should be small and must not consume time.
 • Object Serialization/De-serialization and state management should be considered.
 • Context sensitive handlers should execute data processing in case of interrupt handling.
 • Thread safe the execution of processes, so that the UI threads will be in a sleep state until
   interrupt is executed.
Every mobile platform has its own recommendation for interrupt handling. For example, in the iPhone Applications, the low memory notifications must be appropriately handled and necessary steps should be taken like cleaning up the stale resources.
However, if the iphone application is data centric, the “Application state management” should be present. This will be required to handle the premature exit of the application; for example, if the last session of application is closed abruptly, the application should be able to serialize its state before exit, and when the same application is accessed, it should initiate from the same point.
Similarly in BREW applications, “Suspend and resume behavior” is one of the very important recommendation of NSTL TBT certification. As per the NSTL guidelines, BREW application must suspend itself on notification of incoming call and must resume from same point after the call is finished.
In the case of a client-server based mobile application, the app must have ability to check network connectivity (GPRS or WI-FI). If the connectivity is not available, then the application should keep information (to be synced with server) in some local storage and sync it with the server when the network is available next time.
 
For mobile devices like iPhone, iPad, Windows mobile phones, that supports bolth..landscape and portrait modes, the application should be able to provide the required support with the help of appropriate delegates/ events.

0 Comment for this post

Post a Comment

Required Information *
Name* Email*
Comments*  

*

In accordance with our comment policy, we encourage comments that are on topic, relevant and to-the-point. Once submitted, your comments will be published by the Impetus blog moderator. We will remove comments that include profanity, personal attacks, racial slurs, or threats of violence, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.
Cloud and SAAS model for ISVs Big Data : Open Source Revolution Mature Big Data Open Source products adding excitement
Cloud and SAAS model for ISVs Cloud and SAAS model for ISVs Pankaj Mittal,
CTO & Sr.VP, Impetus
More More More Videos