Mobile Devices Application Architecture

Mobile Platforms are increasing finding there right places in the enterprises. The Mobile Platform vary from an insignificant non UI based devices to a full-fledged tablets and SMART TV. The compute and storage are a fast moving segment for mobile device capabilities, building applications for these platforms can be a daunting task for developers. Most mobile devices have connectivity in some form or the other and the applications build for devices connect with services which are hosted on premise OR cloud. Concentrating on the mobile device Architecture it would be good to have some guidance for developers what constitute a typical mobile architecture.

High Level Device Architecture

Since most mobile devices as of current are UI intensive the starting point is more around the UI architecture.

The High Level Mobile /Device Application Architecture includes the following components. It’s typically a layered architecture.

Presentation Layer

The UI architecture is heavily driven but certain patterns

• MVC – The Model View Controller is an architectural pattern that divides an interactive applications into 3 components. The model contains the core functionality and data. View displays information to the user. Controller handles the user input. View and controller together comprise the user interface. A change propagation mechanism ensures consistency between the user interface and model. This architectural pattern came up first with Smalltalk 80 and post that a large number of UI frameworks have been built around MVC and now become a defacto standard for UI development. For more on MVC refer here.
• Delegation- Most User Interface in mobile devices are rich from a functionality standpoint view and have delegate i.e. transfer information, data and processing to another object typically referred to as a background object. Delegation is a design pattern. For more on Delegation refer here. The delegation pattern is a design pattern in object-oriented programming where an object, instead of performing one of its stated tasks, delegates that task to an associated helper object. There is an Inversion of Responsibility in which a helper object, known as a delegate, is given the responsibility to execute a task for the delegator. The delegation pattern is one of the fundamental abstraction patterns that underlie other software patterns such as composition (also referred to as aggregation), mixins and aspects.
• Target actions- The User Interface is divided up into View, Controller which dynamically establish relationships by telling each other which object they should target and what action or message to send to that target when an event occurs. This is especially useful when implementing graphical user interfaces, which are by nature event-driven. Most UI on devices are event driven based on the user input raise the desired event and the event handler associated with the same will executed by the event handler associated.
• Block objects – Most device based application interact with services or other applications for data services or more. The need of having asynchronous call backs will help saving compute. The services have to modelled differently for devices that’s a whole different topic will be covered in a separately.

Management Layer

The management is crucial piece in devices ranging from memory management, state management all the way to device management. Below are some of the key components.

Memory Management-

Device have less usable memory and storage in comparison to a desktop computer, all applications built need to be very aggressive on deleting unneeded objects and be lazy about creating objects.

Foreground and Background Application Management

Applications on device have to be managed differently when in foreground and background. The operating system limits what your application can do in the background in order to improve the battery life and the user experience with the foreground application. The OS notifies your application when it moves from background to foreground which requires special handling for data loading and UI refresh. So typically from transition between these states what does one really have to take care?

• Moving to Foreground: Respond appropriately to the state transitions that occur. Not handling these transitions properly can lead to data loss and a bad user experience.
• Moving to Background make sure your app adjusts its behaviour appropriately. Devices which support multitasking have this option in other cases application is terminated. The elementary steps in taking a snapshot image of the current User Interface, save user data and information and free up as much memory as possible. Background application continue to stay in the memory until a low memory situation occurs and OS decides to kill your application. Practically speaking, your app should remove strong references to objects as soon as they are no longer needed. Removing strong references gives the compiler the ability to release the objects right away so that the corresponding memory can be reclaimed. However, if you want to cache some objects to improve performance, you can wait until the app transitions to the background before removing references to them.

Examples of objects that you should remove strong references to as soon as possible include:

• Image objects
• Large media or data files that you can load again from disk
• Any other objects that your app does not need and can recreate easily later

• Handling Interrupts

The devices are more complicated than one can think classic scenario handling interrupts like an incoming phone call, when an alert-based interruption occurs, such as an incoming phone call, the app moves temporarily to the inactive state so that the system can prompt the user about how to proceed. The app remains in this state until the user dismiss the alert. At this point, the app either returns to the active state or moves to the background stat. In most devices in this state the application don’t receive notification and other types of events. There needs to be some nature of application state management.

State Management

Irrespective what state the application is in foreground, background or suspended, the application’s data has to stored and restored. Even if your app supports background execution, it cannot run forever. At some point, the system might need to terminate your app to free up memory for the current foreground app. However, the user should never have to care if an app is already running or was terminated. From the user’s perspective, quitting an app should just seem like a temporary interruption. When the user returns to an app, that app should always return the user to the last point of use, so that the user can continue with whatever task was in progress. Preserving and restoring the view controllers and view is something which has to be implemented application specific. State preservation needs to considered at the following scenarios

• Application delegate object, which manages the top level state
• View Controller object which manages the overall state of the app’s user interface.
• Custom View, custom data.

State preservation and restoration is an opt-in feature and requires help from your app to work. When thinking about state preservation and restoration, it helps to separate the two processes first. State preservation occurs when your app moves to the background. The restoration process uses the preserved data to reconstitute your interface. The creation of actual objects is handled by your state management.

Core Data Management

The Model in the MVC in the Presentation Layer holds references to business data which may be displayed in the views. The Models generally can end up holding a lot of data can become a major performance issue. The Models should ideally load data which is most relevant to the scenario with support for lazy loading. The responsibility of loading Core Business Data in the Business entities is handled by the Core Data Management. Core Data is generally a schema driven object graph management and persistent framework. Fundamentally, Core Data helps save the model objects, retrieve model objects from the business layer.

• Core Data provides an infrastructure for managing all the changes to your model objects. This gives you automatic support for undo and redo, and for maintaining reciprocal relationships between objects.
• It allows you to keep just a subset of your model objects in memory at any given time,
• It uses a schema to describe the model objects.
• It allows you to maintain disjoint sets of edits of your objects. This is useful if you want to, for example, allow the user to make edits in one view that may be discarded without affecting data displayed in another view.
• It has an infrastructure for data store versioning and migration. This lets you easily upgrade an old version of the user’s file to the current version.
• It interacts with Services or Business Level API to perform CRUD on the business entities.

Core Data Management is runs on a background thread(s).

Application Resource Management

Aside from images and media files, most devices have a lot more capability ranging from accelerometer, camera, Bluetooth, gps, gyroscope, location services, telemetry, magneto meter, microphone, telephony, Wi-Fi….. Most of these have platform based API to access the same. In certain cases there may be a requirement to manage this resources for example video telephony module. The nature of the API provided by platform provides direct access mechanism to access these resources.

Services Helper Layer

The Services Helper Layer on the device serve the purpose providing caching, api, logging or notification services. The Service Helper Layer function more as an assistance to the device hiding the complexity of the inner working thus simplifying the programming model for the developer and not having to worry about low level functions.

Caching Services

The application running on the devices does have limited memory and compute. Most UI elements, pages, data may require to be in memory while they may not be displayed. A efficient disk and memory based caching strategy needs to implemented for the application for better performance.

API Services

In the cloud world or on premise world the devices are likely to talk via services. These services are infact well defined API’s of the business. APIfying the services is a core concept on the cloud which will be covered later. A standard API is

The API Services will interact with the Services API and manage the lifecycle of the service call asynchronously. It will manage aspects such as format conversion, lazy loading and much more.

Logging Services

This is a generic services provides for application level and business level logging. The data collected will be sent back to the Services serves multi-purpose use.

Notification Services

This is asynchronous module which will manage application based notification and events from the services and other application