Architectural patterns for Mobile Application Development

1. Introduction

Mobile application development share common software design principles as desktop application development. However, typical mobile applications follow the mobile application lifecycle management process [1], [2] that differs from desktop applications.

Mobile applications often require more user interaction compared to its desktop counterpart, usually waiting for an action from the user (such as a button click) before responding to the user with an updated UI showing the requested information. We will discuss a software pattern that focusses on the interactive aspects of mobile applications as well as a more general high-level decomposition pattern and discuss their uses in mobile application development.

2. Model View Controller (MVC)

The Model View Controller (MVC) pattern [3], [4] is a very popular approach for the development of a mobile application. We observe that most mobile applications’ core operation is to retrieve data from a data store and update the user interface with the newly requested information based on the user’s inputs. The logical sense is to tie the user interface components with the data store components. However, since the user interface components are updated regularly to accommodate the changing user requirements and new technologies – more so than the data store components, we introduce extra coupling in our system. The aim of this pattern is to separate the components of user interface (View); core functionality and data (Model) and the response to user inputs (Controller).

2.1 MVC in the context of Android applications

I will first provide a brief overview of the components of the Android system. The main components [5] are:

  • Activity – represents a single user interface class. Activities are usually packaged together to form the UI components of the application.

  • Service – allow tasks to be executed in background threads (such as networking operations) without affecting UI components.

  • Content Provider – enable data to be stored within the application with the use of SQLite database or SharedPreferences (data stored in an XML file on the device).

  • Broadcast Receiver – responds to announcements from the system (such as low battery warning) and provides notifications to the user.


In my experience of developing Android applications in the SELP third year project and my final year project, my opinion is that the suitability of the MVC pattern depends on the context of the application in question.

My project is based on a tourism application consisting of: UI components (update a list of nearby points of interest and displaying these to the user); service components (location listener for tracking user location using GPS and detect changes, background running tasks to fetch data from other services); data components (for storing and retrieving user preferences); widget components (buttons, edit text, text views for handling user clicks and inputs).

The UI components is made up of a package of Activities that resemble the View component of the pattern where each Activity updates and modifies the UI throughout its lifecycle. The service and data components represent the Model component of the pattern in that it monitors the behaviour of the data and core application domain. It also handles requests from the View and Controller for information about its state and instructions for changing its state respectively. The widget components are similar to the Controller in that it waits for user inputs (such as a button click) then interprets those inputs and notifies the Model or View of the change.

In the high-level overview of my application, it seems that MVC patterns fits well with the Android ecosystem with each application component more or less mapping to the Model, View and Controller. However with closer inspection of the details, things are not so straightforward. An example is the Activity component that forms part of the application. Each Activity consists of a Java file and a corresponding XML layout file. We define the UI layout of the Activity in the XML file and implement the functionality and behaviour in the Java file (separation of user interface with application logic). When we use widget components in our Activity, we first have to define the widgets as XML elements in the layout file to instantiate the widget and its attributes. The handling of the behaviour of the widget in response to user actions is then implemented in the Java file. However, we often have to access the widget’s attributes from the XML layout while implementing its functionality and this violates the concept of separating the View from the Model/Controller in the MVC pattern.

A possible solution to this is to use an Observer pattern within MVC. We could make the Activity components (View) implement an Observer interface to receive updates and notifications of changes to the application logic (Model’s state). When a change occurs, the application logic notifies all its Activities (observers) of the state change. This eliminates the coupling between the Model and View.

Figure 2. Using Observer within MVC [4]

3. Layered Abstraction

The Layered Abstraction pattern [6] consists of a hierarchy of layers. At each layer, we have components that work together within the same level of abstraction, with the layer below providing functionality for the layer above.

The Android architecture [7] follows this Layered Abstraction pattern. It consists of four layers of abstraction with direct communication only between a layer and the layer directly above or below it:

  • Applications – this layer consists of a set of core applications as well as developed applications.

  • Application Framework – layer which contains the main components of the Android system (Activity, Service, Content Provider, Broadcast Receiver) as well as other system components.

  • Libraries – consists of core Android system libraries as well as a lightweight relational database management system – SQLite.

  • Linux Kernel – contains device drivers which provides communication with the device’s hardware.

Figure 3. Android system architecture [8]

I will now provide an example scenario from my tourism application that follows this software pattern. When a user uses the application to determine their current location, a background running task is executed from the Service component which sends a location request from Applications to the Application Framework layer. The location manager sees the request and provides periodic updates of the device’s geographical location (latitude, longitude coordinates) with the help of the core system libraries in the Libraries layer. The system libraries communicate with the WiFi and GPS device drivers in the Linux Kernel which interact with the device’s hardware to receive GPS signals. Once the signals are received the notifications are propagated back up the layers to the Application layer which updates the user with their location information.

4. Conclusion

In this blog post, I discussed the interactive MVC pattern and the high-level decomposition Layered Abstraction pattern and their relation with mobile application development.

In terms of the MVC pattern, I think for applications with large UI components it might be worthwhile following this pattern of design as the constant update and modifications of the user interface due to the rapidly changing nature of user requirements will result in less work maintaining the core business logic of the application.

With the Layered Abstraction pattern, since the Android system follows the abstraction layer architecture as discussed above, we can say that this pattern forms the foundation for all Android applications that makes request to services and receives notifications from them.