Android application architecture. Part II - architectural styles and patterns
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 more effectively use the accumulated knowledge and skills.
Maybe I was looking badly, but in the Android documentation there is no mention of any templates. Despite this, Android has implemented some templates and architectural styles, which we will now discuss.
')
The Android architecture is framework-based, as opposed to a free-style architecture.
What is the difference? Free applications written in Java begin with a class that has a main () method, and are developed in full accordance with the developer's mood.
In contrast, framework-oriented applications are based on an existing framework. Their development boils down to the expansion of certain classes or the implementation of interfaces provided by the framework. Such an application can not be run without or without the framework. An example would be Java web applications in which developers implement the Servlet interface or extend one of its implementations, or Eclipse RCP applications in which the developer extends one of the Editor or View classes.
A framework-oriented architecture restricts the freedom of developers, prescribing them what to do and how. But, as a result, the repeated sections of the code (boilerplate code) disappear, and developers have to (I would like to believe in it) to 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 why they did this was the need to maintain a unique memory management system.
In a “regular” Java, the objects are in memory until the garbage collector reaches them. This happens only when the object has no links from “live” objects (you can read more here ). In Android, it is not. 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 if the application is 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 completely destroyed by Android OS (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 now on, screen A has become invisible. This means that screen A and all of 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 as long as screen B. is visible. Screen logic B should not be tied to finding screen objects A in memory. A side effect is that the Android architecture forces the use of the “shared nothing” architectural style. This means that different parts of the Android application can call each other and interact with each other only formally; none of them can directly access the other.
Well, what happens if the user decides to return to screen A? Perhaps he wants to see him in the same condition 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 redefined by the developer. These methods are called by the framework at predetermined key moments, for example, when the user interface is shown on the screen, hidden, etc. In these methods, the developer can implement logic for storing and restoring the state of objects.
Such processing of hiding user interfaces and the existence of a “back” button on Android devices necessitates a user interface stack in which the current visible interface is placed on top, and all others are moved down (stack operation “push”). Clicking “back” removes the interface from the top of the stack and shows the element that was behind it (the “pop” stack operation). A similar stack exists in Android. In the documentation, it is called “activity stack” or sometimes “back stack” .
In terms of processing the interaction between the user interface and its Android logic, it follows the architectural pattern “Model-View-ViewModel” (MVVM). This is good news for developers, because MVVM is the best GUI application architecture at the moment.
The MVVM architecture was created with the aim of separating the designer and programmer’s work, which is impossible when a Java developer tries to build a Swing GUI or a Visual C ++ developer 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 have. This work is more suitable for interface designers. Good interface designers know better what users, rather than experts in the field of design and writing code, know. Clearly, it will 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 to do this.
The MVVM architecture solves this problem by a clear division of responsibility:
The MVVM architecture is used in one form or another by all modern technologies, such as Microsoft WPF and Silverlight, Oracle JavaFX, Adobe Flex, AJAX.
We mentioned that different parts of an Android application can call each other and interact with each other only formally. How is this achieved? The Android framework uses several interaction templates:
Do not worry if any of this sounds incomprehensible. Detailed explanations will be in the following articles.
That's all for today.
Previous article: Android application architecture. Part I - the origins
The following articles:
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 more effectively use the accumulated knowledge and skills.
Maybe I was looking badly, but in the Android documentation there is no mention of any templates. Despite this, Android has implemented some templates and architectural styles, which we will now discuss.
')
The Android architecture is framework-based, as opposed to a free-style architecture.
What is the difference? Free applications written in Java begin with a class that has a main () method, and are developed in full accordance with the developer's mood.
In contrast, framework-oriented applications are based on an existing framework. Their development boils down to the expansion of certain classes or the implementation of interfaces provided by the framework. Such an application can not be run without or without the framework. An example would be Java web applications in which developers implement the Servlet interface or extend one of its implementations, or Eclipse RCP applications in which the developer extends one of the Editor or View classes.
A framework-oriented architecture restricts the freedom of developers, prescribing them what to do and how. But, as a result, the repeated sections of the code (boilerplate code) disappear, and developers have to (I would like to believe in it) to 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 why they did this was the need to maintain a unique memory management system.
In a “regular” Java, the objects are in memory until the garbage collector reaches them. This happens only when the object has no links from “live” objects (you can read more here ). In Android, it is not. 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 if the application is 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 completely destroyed by Android OS (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 now on, screen A has become invisible. This means that screen A and all of 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 as long as screen B. is visible. Screen logic B should not be tied to finding screen objects A in memory. A side effect is that the Android architecture forces the use of the “shared nothing” architectural style. This means that different parts of the Android application can call each other and interact with each other only formally; none of them can directly access the other.
Well, what happens if the user decides to return to screen A? Perhaps he wants to see him in the same condition 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 redefined by the developer. These methods are called by the framework at predetermined key moments, for example, when the user interface is shown on the screen, hidden, etc. In these methods, the developer can implement logic for storing and restoring the state of objects.
Such processing of hiding user interfaces and the existence of a “back” button on Android devices necessitates a user interface stack in which the current visible interface is placed on top, and all others are moved down (stack operation “push”). Clicking “back” removes the interface from the top of the stack and shows the element that was behind it (the “pop” stack operation). A similar stack exists in Android. In the documentation, it is called “activity stack” or sometimes “back stack” .
In terms of processing the interaction between the user interface and its Android logic, it follows the architectural pattern “Model-View-ViewModel” (MVVM). This is good news for developers, because MVVM is the best GUI application architecture at the moment.
The MVVM architecture was created with the aim of separating the designer and programmer’s work, which is impossible when a Java developer tries to build a Swing GUI or a Visual C ++ developer 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 have. This work is more suitable for interface designers. Good interface designers know better what users, rather than experts in the field of design and writing code, know. Clearly, it will 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 to do this.
The MVVM architecture solves this problem by a clear division of responsibility:
- User interface development is done by the interface designer using technology that is more or less natural for such work (XML).
- The user interface logic is implemented by the developer as a component of the ViewModel.
- Functional links between the user interface and the ViewModel are implemented through bindings, which, in essence, are rules like "if the button A was pressed, the onButtonAClick () method from the ViewModel should be called." Binding can be written in code or defined in a declarative way (Android uses both types).
The MVVM architecture is used in one form or another by all modern technologies, such as Microsoft WPF and Silverlight, Oracle JavaFX, Adobe Flex, AJAX.
We mentioned that different parts of an Android application can call each other and interact with each other only formally. How is this achieved? The Android framework uses several interaction templates:
- Messaging with the Intent class
- Observer using the Intent and BroadcastReceiver classes
- Later binding with a subsequent method call is used to access content providers ( ContentProviders ) and local (intra-process) services ( Services )
- Late binding and interprocess communication ( Inter-process Procedure Communication , IPC) for service call (AIDL)
Do not worry if any of this sounds incomprehensible. Detailed explanations will be in the following articles.
That's all for today.
Previous article: Android application architecture. Part I - the origins
The following articles:
Source: https://habr.com/ru/post/140655/
All Articles