Over a million developers have joined DZone.

Intro to Major Android App Development Architectural Patterns in Brief

DZone 's Guide to

Intro to Major Android App Development Architectural Patterns in Brief

· Java Zone ·
Free Resource

In software niche, mobile application development is getting momentum and mobile OS is spreading its tentacles beyond the handheld devices such as wearable gadgets and auto-mechanical systems (cars, home appliances, machines, etc.). High acceptance of mobile web among the masses is blurring the differences between web and mobile with the evolution of responsive design.

There was a time when software developers were talking mostly about the software architectures, mainly in the sense of web related development. Fortunately, today web dependent architecture still exists there and needs lot of refinements in the sense of modern mobile contexts. In web development, we were banking on MVC (Model, View, and Controller) patterns greatly with a high degree of success. Therefore, it is only natural that we think of it first in mobile app development too.

Architectural Components of Mobile Development

It is worthwhile to think about the architectural components of mobile development before thinking of MVC or any other development architecture or framework. No doubt, there seems some differences across the mobile platforms like iOS, Android, Windows, etc. in their architectural components due to the native languages and their hardware supports. Therefore, in this post we will be restricted to Android app development only.

For the sake of simplicity and understanding, we can divide Android architectural components in the following ways:

·  Activities: This includes all user interfaces in a class form for an application where our users interacts with Android application. This mostly takes place at the front end

·  Services: This includes all background tasks/operations in the threads, at the backend of the application/device. Therefore, it is hidden and not affecting UIs apparently.

·  Content Provider:This include data storage mechanism within application in form of lightweight and efficient databases like SQLite on client devices or on the cloud.

·  Broadcast Receiver: This includes the responses from the hardware and OS such as kernel space or utility system or widget components, etc.

In MVC Paradigm

If we try to fit the above given architectural components in MVC paradigm, we can place Activities in the View part of MVC, as it forms the UIs of Android applications and updates them throughout the lifecycle of the Android application.

The Services and Content Provider or data are hidden components and monitoring the behavior of the application, they are best fitting in the definition of Model part of MVC.

Widget components at kernel are acting as Controller of MVC and interacts with Models and Views. Therefore, we can separate presentation (View) from the logic of application (Model). However, as broad concepts, these Android application architectural components are best fitting in many projects of Android application development. This way MVC eases the work of Android app developers at greater degree.

Unfortunately, frontend activities rely on the XML and Java files and their interactions in Android app programming. Java files/libraries are falling in Model part of MVC, whereas XML belongs to the View part. Thus, separation of logic from presentation is a nightmare in actual Android application development and we have to think of another architecture for the high level of Android programming.

Layer Abstraction Architecture

Now in MVC, we have seen that we can’t separate the architectural components in distinct ways in Android development, as we do in web development. Therefore, assuming a hierarchy of layers where at each layer, all of our components can work together in abstraction with the layer below and give functionality for the layer above. If we divide layers of abstraction in four logical parts of architectural components, our work becomes easy.

If we think of the first and top layer as application layer, it will consist of all frontend UIs and the core of the application. Below it, we can place application framework consisting of all our Android application architectural components (Activities, Services, Content Providers, and Widgets) along with other components. In technical terms, we can say this layer may consist of UIKit and Foundation framework, so we can say it's the Cocoa Touch layer for Android programming in particular.

Below it, libraries and Android the runtime layer may exist where you may find all media components such as Open GL ES, Quartz, Core graphics, etc. for graphics part and Open Al, Core Audio, etc. as Audio part of the medial layer.

Apart from these upper space/layers, we would have kernel space with drivers like system utilities and components of Linux kernel at the bottom level of the architecture of layer abstraction.

In short, layer abstraction architecture seems more practical and applicable in a broad sense for modern Android app development  processes.


Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}