Architecting Android ... The clean?

Architecting Android ... The clean?
original link: http://fernandocejas.com/2014/09/03/architecting-android-the-clean-way/original Fernando Cejas

Over the past few months, with @pedro_g_s and @flipper83 (Flung said that these two are Android developers Daniel) two peers on the Tuenti site after a friendly discussion. I think this is a good time to write an article about Android application architecture.

The purpose of writing this article is to show you some of the little things I've thought about in the last few months, plus some of the small ways that I've learned from research and implementation .

Getting Started Guide

We know writing a piece of quality software is difficult and complex: not only to meet the requirements, the same time is also robust, maintainable, can be tested. and flexible enough to adapt to expansion and change. This is where the "clear Architecture" appears, and may be a good way to develop whatever software application you have.

This idea is very easy: a clear architecture indicates that the product system follows a set of practice principles:

• The framework is independent.
• can be tested.
• UI is independent.
• Database is independent.
• No matter what external agent module is independent.

It is not necessary to use the four ring structure (see), since this is only a schematic, but you should consider the principle of dependency: source code dependency can only point inward, and all the items in the kernel do not know anything outside the ring.

Here are some related words to familiarize and understand these methods in a better way :

• entities: the business object of the application.
• Use Cases: A case that combines data from a business object into an outflow. The same is known as interactors.

• Interface Adapters: This set of adapters transforms data between use cases and business objects in the most appropriate format. Presenters (presentation layer) and Controllers (control layer) belong here.
• Frameworks and Drivers: Here is the detailed implementation: UI. Tool classes, frames, and so on.

For a better and more vivid explanation, refer to this article or video.

our scene

I'm going to start with a simple scenario: Create a simple app that shows a list of friends and users retrieved from the cloud. When you click on them. A new interface displays specific information for the user.

I put a video here. So you have a ballpark image of what I'm saying:

Android Architecture

The goal is to isolate the point of concern . Let business rules know nothing about external things, so they don't have to rely on other external elements when tested.
To achieve this goal, my advice is to divide the project into three tiers , each with its own purpose and working separately from the other layers.
It is worth mentioning that each layer has its own data model to achieve this independence (you will have to pay a price when you see that you need a data map in your code to complete the data transformation, assuming you do not want to cross-use your model and the entire application).
Here is the illustration, you can feel it:

Note: I did not use any external libraries (except for the parsing of JSON data and for Gson, Mockito, robolectric, and espresso). The reason is that it can make the sample clearer.

Don't hesitate to join Orms storage data, Dependency injection frameworks, or whatever libraries you're familiar with, all of which makes you easier. (It is unwise to remember to build the wheel repeatedly.)

Presentation Layer (presentation)

in thehere, the Association of logical and view animations is represented. Here's aModel View Presenter( hereinafterMvp). But you can also use any other mode. Like MVC or MVVM .. I'm not here to describe them specifically, but herefragments and activities but views,There is no logic inside them except for the UI logic, which is where all rendering takes place.

The presenters in this layer consists of multiple interactors (use cases) that run the job on a new thread outside of the Android UI thread and retrieve the data from the callback that will render to view.

Let's say you need a cool example that uses MVP or MVVM effective Android UI to see what my friend Pedro Gómez did.

domain layer (domain tier)

Business rule definition: All logic occurs at this level. for Android projects, you'll also see all the interactors (use cases) implemented here.

This layer is a pure Java module, no matter what Android relies on.

All external components use interfaces to access business objects.

Data Layer

All the data required by the application comes from this layer, implemented through Userrepository (this interface is in the domain layer), using Repository pattern as a strategy, through a factory class, according to certain conditions to select different data sources.
For example: When you get a user by ID. Assume that the user already exists in the cache. The hard drive data will be selected, otherwise the data will be fetched from the cloud and saved on the local disk.

The idea behind all this is that the data source is transparent to the client. the client does not care about the data from memory, disk, or cloud. It is only the relational data that will arrive and be acquired.

Note: for the purposes of learning, here I implemented a very easy code, using the file system and Android preferences implementation of the original disk cache , again, assuming that there is a good completion of the work of the class library, should not reinvent the WHEEL (do not create wheels repeatedly).

error handling (fault handling)

This is a long-term topic worthy of discussion. Assuming you can share your solution, that's really great.

My strategy is to use the callback callbacks, so. If the data warehouse sends a change. The callback callback has two methods Onresponse () and OnError (). the class that finally encapsulates the exception is called "Errorbundle": This approach poses some difficulties, Because there is a callback chain one after another. Until the error is rendered to the presentation layer.

Readability can be a bit of a sacrifice.

There is one more aspect. Assuming an error occurs, I use the event bus system to throw the wrong events. But this kind of solution is like GOTO, in my opinion, when you subscribe to multiple events but not very well controlled. You might get lost.

Testing (Test)

About testing. I have chosen several solutions based on different layers:

• Presentation Layer (presentation layer): Integrated and functional testing using Android instrumentation and espresso.

• domain layer: use JUnit plus Mockito for unit testing.

• Data layer: use Robolectric (this layer has Android dependencies) plus JUnit plus Mockito for integration and unit testing.

Code Show

I guess you're wondering where the code is? Well, that's the GitHub connection I've talked about.

About the folder structure. As a reminder, different layers use modules to represent:

• presentation: is an Android module representing the presentation layer.
• domain: is a Java module that has no Android dependencies .
• Data : is an android module, the source of all the information obtained.
• data-test: data layer test. Because of the limitations of using robolectric, I had to use a separate module.

Conclusion

As Uncle Bob said,"Architecture is on Intent, not frameworks" I totally unify this statement. Of course there are many different ways to do these things (different implementations), and I'm pretty sure that every day you (like me) face a lot of challenges, but use the method above. To ensure that your app will:

• Easy to maintain.
• Easy to test.
• High cohesion.
• Low coupling.

Finally, I strongly recommend you to practice, share your results and experience. Maybe you'll find a better way: we all know that continuous improvement is always a good positive thing.
I hope this article is helpful to you, the same welcome feedback is not allowed to see.

Source Code

1. Clean architecture GitHub Repository–master Branch
2. Clean architecture GitHub Repository–releases

Further reading:

1. Architecting Android. The evolution
2. Tasting Dagger 2 on Android
3. The Mayans Lost Guide to RxJava on Android
4. It is about philosophy:culture of a good programmer

Links and Resources

1. The clean architecture by Uncle Bob
2. Architecture is on Intent, not frameworks
3. Model View Presenter
4. Repository Pattern by Martin Fowler
5. Android Design Patterns Presentation

Architecting Android ... The clean?