Android application architecture. Part II - Architectural Styles and Patterns

Original author: Vlad Nevzorov
  • Transfer
In this article, we will talk about architectural patterns used in Android applications.

Why is it important to understand patterns implemented within a certain architecture? Because in this way the new architecture we are studying fits into the context of our previous experience and allows us to use our accumulated knowledge and skills more effectively.

I may have searched poorly, but there is no mention of any templates in the Android documentation. Despite this, Android has implemented some templates and architectural styles, which we’ll talk about now.

Android architecture is a framework-based architecture, as opposed to a free-style architecture.

What is the difference? Free Java applications start with a class that has a main () method, and are developed in full accordance with the mood of the developer.

In contrast, a framework-oriented application builds on an existing framework. Their development comes down to the expansion of certain classes or the implementation of interfaces provided by the framework. Such an application cannot be launched outside the framework or without it. An example would be Java web applications in which developers implement a Servlet interface or extend one of its implementations, or an Eclipse RCP application in which a developer extends one of the Editor or View classes .

A framework-oriented architecture limits the freedom of developers by prescribing what and how to do. But, in the end, the repeating boilerplate code disappears, and the developers have to (I would like to believe it) carefully follow the design patterns.

There are many frameworks for Java. However, the Android team decided to create their own. Perhaps one of the reasons they did this was the need to maintain a unique memory management system.

In “normal” Java, objects are in memory until the garbage collector reaches them. This happens only when there is not a single link to the object from "live" objects (more details can be read here) In Android, this is not the case. If a certain user interface is hidden (that is, it is no longer visible on the screen), then there is no guarantee that it is in memory, even there is an application going to use it in the future. If the Android OS has enough free memory, these objects can be stored in it, but the garbage collector can destroy them at any time when the OS decides that there is too little memory left. The same is true for processes. A process that currently does not show the user any graphical interface can be destroyed by the Android OS on absolutely legal grounds (there is one exception to this rule - services ; we will talk about this later).

Consider an example. Let our application have screens A and B. The user first opens screen A, and then screen B; from that moment, screen A became invisible. This means that screen A and all the logic contained in it may or may not be in memory. So, there is no guarantee that objects associated with screen A are in memory while screen B is visible. The logic of screen B should not be tied to finding objects of screen A in memory. A side effect is that the Android architecture forces the use of the architectural style of the “shared nothing” style . This means that different parts of an Android application can call each other and interact only formally; none of them can address the other directly.

Well, what happens if the user decides to return to screen A? He probably wants to see him in the same state in which he left him, right? Here's how the Android framework solves this problem: for each state of the life cycle, there are methods, each of which can be overridden by the developer. These methods are called by the framework at predetermined key points, for example, when the user interface is displayed on the screen, hidden, etc. In these methods, the developer can implement logic for storing and restoring the state of objects.

Similar processing for hiding user interfaces and the existence of a back button on Android devices makes it necessary to have a stackuser interfaces, in which the current visible interface is placed on top, and all the others are shifted down (the stack operation "push"). Pressing “back” removes the interface from the top of the stack and shows the element that was behind it (stack operation “pop”). A similar stack exists in Android. In the documentation, it is called an “activity stack” or sometimes a “back stack” .

In terms of handling the interaction between the user interface and its logic, Android follows the architectural Model-View-ViewModel (MVVM) pattern . This is good news for developers, since MVVM is the best GUI application architecture at the moment.

The MVVM architecture was created to separate the work of the designer and programmer, which is not possible when a Java developer tries to build a GUI in Swing or a developer in Visual C ++ tries to create a user interface in MFC. Developers are smart guys and have a lot of skills, but creating user-friendly and attractive interfaces requires completely different talents than the ones they possess. This work is more suitable for interface designers. Good interface designers know better what users though than experts in designing and writing code. It is clear that it would be better if the interface designer creates an interface, and the developer writes code that implements the logic of this interface, but technologies like Swing or MFC simply do not allow you to do this.

MVVM architecture solves this problem by clearly sharing responsibilities:

  • User interface development is done by the interface designer using technology more or less natural for such work (XML)
  • The user interface logic is implemented by the developer as a component of ViewModel
  • Functional connections between the user interface and the ViewModel are implemented through bindings, which, in essence, are rules like “if button A was pressed, the onButtonAClick () method from the ViewModel should be called”. Bindings can be written in code or defined declaratively (Android uses both types).

MVVM architecture is used in one form or another by all modern technologies, for example Microsoft WPF and Silverlight, Oracle JavaFX, Adobe Flex, AJAX.

We mentioned that various parts of an Android application can call each other and interact only formally. How is this achieved? The Android framework uses several interaction patterns:


Do not worry if any of this sounds confusing. Detailed explanations will be in the following articles.

That's all for today.

Previous article: Android Application Architecture. Part I - the origins of the

following articles:

Also popular now: