Tutorial- Why and How to implement Android App Architecture to Streamline the Overall App Development Process

Pinal Jakhar– an Android developer at the firm, takes an hour long session on Android app architecture and how its implementation can help overcome the most common challenges developers face. The engaging and resourceful session earned her much regard followed by a token of appreciation. Here is a layout of the session:

A report (pdf) published at the University of Luxembourg in 2015, found that over 60% of an Android apps’ code was contributed by common libraries. Most of such libraries include ads and analytics from Google, social plugins, common widgets, among others. That means more than half the resources (of which mobile devices are highly constrained) is drained by processes irrelevant to core business logic.  And given that we still use most of those libraries, it can be safely assumed the situation hasn’t changed much since 2015.

No, libraries themselves aren’t the problem. They are extremely resourceful and there is no way we can build apps without them. But the point is if more than half the code and device resources are channeled to common housekeeping tasks, it becomes essential that the code we do write for the core business logic brings the highest level of efficiency.  And that is what this post is about- the problems in Android app development and the how we can streamline the process by effective implementation of latest libraries to boost quality while managing deadlines.

The current scenario

To understand the better way to building an app, we first have to outline what actually constitutes building an app. In its most rudimentary form, the process involves these broad steps:

Routine repetitive tasks

Building applications always start with the same basic set of steps- creating packages, managing versions and elements, and those dozens of other tasks that have to be repeated like clockwork for each application.

Network communication

The next in line is network management. Because mobile devices often work in patchy network reception, apps need to be highly resilient to server timeouts, lost response, or any other kind of network error for that matter.

Data storage

Applications essentially run on data and while there is always the main database at the backend, the tricky part is to decide how data flows through different processes and which data source to use for each type of user action. Eventually, it all boils down to the speed of local storage vs accuracy of fetching it from the server.

Data display

This relates to the UI aspect of the application that users actually see. While the primary task of UI components is to display data, it also has to change its own behavior depending on the data being displayed.

Data manipulation

This is where the core business logic is applied and has to take into account all different components.

Architecture

Both of the above operations are implemented in specific architectures of which two of the most popular are MVP and MVVM:

• MVP (Model-View-Presenter)

Model refers to the data layer that applies business logic and communicates with database and network. View is the UI layer that displays data and forwards user actions to the presentation layer, which in turn retrieves data from the Model layer, applies UI logic and decides what to display for each particular user action.

Image source: gwtproject.org

• MVVM (Model-View-Viewmodel)

This architecture too works pretty much the same way as MVP but has one crucial difference- the view is completely insulated from model. That is, the business logic can be easily altered without having any affect on UI components. This also means that creating UI test cases is relatively simple and performing unit tests is much easier.

While these approaches work well, there are a few subtle problems whose severity grows in proportion to size and complexity of the concerned app.

Notable problems:

Modular programming

Generally, action of a dependent component is implemented in the lifecycle method of activities and methods of any other component. And as the application grows, this results into a web of dependencies, poorly organized code, and proliferation of errors.

Frequent data fetching

Repository modules are responsible for fetching data from different sources (both local and server), keeping the rest of the application abstracted from the complexity involved. But the problem is, it doesn’t keep the fetched data anywhere. This means every time a user leaves an application and comes back, it has to fetch the same data all over again. Not only does this waste valuable data bandwidth but also creates a perception of the app working slow.

Data caching

To solve the problem of frequent data fetching we generally use data caching- which itself can be problematic in some cases. There are instances when two or more requests would essentially fetch the same user data- causing inconsistency and a confusing user experience.

Testing

The confusing web of dependencies we talked about earlier not only affect code manageability but also spills over to the testing phase. The more interdependent the components are, the tougher it is to run unit tests

Now if you take a collective look at all the problems mentioned, it is evident that none of them are caused due to some inherent flaw in Android app architecture but for the lack of its proper implementation.

Here are some key Architecture Components that when deployed can easily plug all those loopholes:

Lifecycle-aware components

The use of lifecycle-aware components lets us move the code of dependent component from lifecycle methods to components themselves. The android.arch.lifecycle package offers classes and interfaces to build lifecycle-aware components that automatically adjust their behavior based on current lifecycle state of an activity or fragment.

At implementation stage, a LifecycleOwner is a single method interface that denotes any particular class has a lifecycle, which a LifecycleObserver can register to watch.

LiveData

LiveData is an observable data class holder that is lifecycle-aware and thus only updates app component observers that are in an active lifecycle state. LiveData considers an observer to be active if it is in a RESUMED or STARTED state. Using LiveData offers numerous perks including consistency between UI and data state, resource sharing, and most importantly, eliminates the need to handle lifecycles manually.

ViewModel

ViewModel is a lifecycle-aware class used to store and manage UI-related data. It enables data to survive any configuration changes like screen-rotation. One of the key benefits of using ViewModel objects is that they are designed to outlive specific instantiations  of LifecycleOwners as depicted here:

Image source: developer.android.com

Room

Room is a persistence library that enables us to create an abstraction layer over SQLite by having a cache of our app’s data on local device- which drastically improves database access and ensures data consistency.

To sum things up, the final architecture of your Android app should resemble the diagram below:

Image source: developer.android.com

Benefits

• Data persistence
• The use of Room library
• Lifecycle management
• Error reduction
• Less boilerplate code