Original link: https://fernandocejas.com/2014/09/03/architecting-android-the-clean-way/over the past few months, on Tuenti with peers such as @pedro_g_ S and @flipper83 a few discussions. I decided to write an article about the Android app architecture. The purpose of writing this article is to show you some of my own methods that have been in my mind for months, mainly from my own study and research.
Start ActionWe all know that writing high-quality software is difficult and complex: it's not just about meeting requirements, it's about being robust, maintainable, testable, and extensible. So the idea of "simple architecture" is a good way to develop any software application. The idea is simple: "Concise architecture" represents a set of practices its system contains the following:
- Stand-alone framework
- Test-able
- Stand-alone UI
- Stand-alone Database
- Independent external institutions
It is not necessary and can only be represented in 4 circles (shown above), but there is one subordinate rule that must be known. The subordinate rule is that the code's dependencies can only be pointed inward, and only the inner ring can know the contents of the outer ring. That is, the outer circle cannot know the contents of the inner circle. Here are some of the noun explanations that will make us better acquainted with and understand this approach:
- Entities: The business object of the application
- Use Cases: Also known as an interactive device. A user instance consists of a stream of data that is entities.
- Interface Adapter: Here are some adapters that convert data into the format that user case and entities can use. Presenters and Controllers belong to this layer.
- Framework and drivers: Here is the real implementation area, such as: UI, tools, frameworks and so on.
For a better explanation, please refer to this article and video.
Our solutions:I'll explain the scheme in a simple example, creating a simple app that uses a background cloud to get a list of friends or users, and a detailed page is displayed when the user clicks on an item in the list.
Android ArchitectureThe purpose is to separate business units, where the business unit is unknown to the periphery, but the business unit can be independently tested. I propose to divide the project into 3 layers, each of which has its own purpose and is independent from the other layers. Because each layer has its own data model, it is possible to be independent (you can see that there is a data map table in the code that is used to carry out the data transfer, which is not the cost of using a common set of models across the entire application) Here's the schematic: note: I'm not using an external class library (except using Gson to parse JSON data and junit,mockito,robolectic and espresso for testing). The purpose of this is to make the example more concise. Also don't hate to add orms to store hard drive data or other related injection frameworks or other tools or libraries you're familiar with. (Remember not to make the wheels repeatedly)
Presentation LayerThe renderer is composed of inteactors in this layer, which works on a thread other than the main UI thread, and then passes the callback function back to the data and updates the UI. If you want a better impact on the MVP and MVVM in the Android UI, you can read this article.
Domain LayerBusiness rules here, all the logical relationships are here. Check out the Android project and you will find all the interactors implementations here. This layer is composed of pure Java code that is not related to Android. All external components use interfaces to contact the business block.
Data LayerAll the data in the application comes from this layer, they are implemented by Userrepository (this interface in the domain layer), using a strategy of repository pattern, through the Factory mode, to obtain a variety of different data sources depending on the central condition. In the instance, when we get the user instance by ID, we first select the disk cache, and if it does not exist, it will fetch the data over the network and save it on the local disk. The premise of this mechanism is that the data source is transparent to the client, and it does not have to be related to the data from memory, disk, or cloud database. Just believe that you can get the data. Note: In the instance, because just for the sake of learning, I implemented a simple and primitive disk cache through a file system and Android preferences. Once again remember not to make the wheel repeatedly.
Error HandlingThis is something we should always prioritize and if sharing your solution would be better. My strategy is to use a callback function, and if some errors occur in the database, then the callback will have two methods Onresponse () and OnError (). The second method is to encapsulate the exception in a "Erorbundle" Class: This method will bring some difficulties because there is a chain callback, one by one know the error to the presentation layer, but if the code write easy to read will reduce this difficulty. On the other hand, I will implement a EVETN bus system to handle error events, called Goto. In my opinion, sometimes if you subscribe to too many events, but not tightly controlled, some events are lost.
TestingFor the test work, I chose several solutions that correspond to different layers.
- Prestation layer: Use Android Instrumtntation and espresso to do integration and functional testing.
- Domain layer:junit plus Mockito for unit testing.
- Data layer:robolectric plus JUnit plus mockito are used for integration and unit testing.
Code ShowThe code is https://github.com/pedrovgs/EffectiveAndroidUI/on GitHub, and the code folder structure needs to be explained by different layers using different modules.
- Presentation: This is the Android module, which represents the Presetntaion Layer.
- Domain: Pure Java modules do not have any Android affinity.
- Data: The Android module that gets the information.
- Data-test: Test for the data layer. Because of the limitations of using robolectric, I have to separate them separately.
Summary:As Uncle Bob said "Architecture is about Intent,not frameworks". We always encounter challenges in our work, but if you use these technologies, you can do the following for your application:
- Easy to maintain
- Easy to test
- High cohesion
- Low coupling
As a summary I highly recommend you to try and share your results and experiences. We believe that continuous improvement is always a good thing. I hope you can get useful information through this article.
How to build Android in a simple way?
