This repository contains a detailed sample application that uses MVP as its presentation layer pattern. The app aims to be extremely flexible to creating variants for automated and manual testing. Also, the project implements and follows the guidelines presented in Google Sample MVP+dagger2+dagger-android.
Essential dependencies are Dagger2 with Dagger-android, RxJava with RxAndroid, Room, Retrofit and Espresso. Other noteworthy dependencies would be Mockito, Chrome CustomTabs, Picasso and Guava.
Mr. News is an app that displays news headlines from all around the world. A fixed number of headlines are continuously being fetched realtime. If offline, the app displays the most recent loaded headlines and offers the possibility of saving headlines for further reading when back online.
As shown in the below diagram, the View layer is as passive as possible. The Presenter handles most of the logic, cancelling any dependancy between the View Layer and the Model Layer.
The model layer is completely isolated and centralized throught the repository pattern.
The model layer is structured on repository pattern so that the presenter has no clue on the origins of the data. Following this idea, the repository has two main use-cases, online and offline. In the online use-case data is first being fetched from NewsRemoteDataSource defined by a REST API consumed with Retrofit, and the repository data is refreshed. In case of failure, NewsLocalDataSource defined by a SQL database consumed with Room is queried. As for the offline use-case, NewsLocalDataSource has priority.
When data is being retrieved (from any source), every response is propagated through callbacks all the way to the NewsPresenter that handles them accordingly.
The same way as the Presenter-View relationship depends entirely on interfaces defined in NewsContract, decoupling is reinforced within the Model layer (entirely consisted by NewsRepository). Therefore, lower level components (which are the data sources: NewsRemoteDataSource and NewsLocalDatasource) are decoupled through NewsDataSource interface.
In this manner, the project respects the DIP (Dependency Inversion Principle) as both low and high level modules depend on abstractions.
It is extremely important to note that this project has a low level of reactiveness, it might barely dream to the possibilities of a effective reactive approach. Nevertheless, the app was intended to have a flexible and efficient testing capability, rather than a fully reactive build.
Even in this case, you will be able to notice RxJava's benefits when data is being retrieved by NewsRemoteDataSource from the REST client (News API):
- threading is much easier, with no need for the dreaded
AsyncTasks - error handling is straightforward and comfortable
- any reactive process is immediately stopped in certain situations of the apps' life cycle with the help of
Disposable
Dagger2 is used to externalize the creation of dependencies from the classes that use them. Android specific helpers are provided by Dagger-Android and the most significant advantage is that they generate a subcomponent for each Activity through a new code generator.
Such subcomponent is:
@ActivityScoped
@ContributesAndroidInjector(modules = NewsModule.class)
abstract NewsActivity newsActivity(); The below diagram illustrates the most significant relations between components and modules. You can also get a quick glance on how annotations help us define custom Scopes in order to properly handle classes instantiation.
Note: The above diagram might help you understand how Dagger-android works. Also, only essential components/modules/objects are included here, this is suggested by the "…"
The apps' components are easy to test due to the project's structure and also due to DI achieved through Dagger. Unit tests are conducted with the help of Mockito and Instrumentation tests with the help of Espresso.
In order to synchronize the background tasks with the testing environment provided by Espresso, a custom implementation of IdlingResource has been integrated into the app. I have given more details on this topic in this medium article.
- possess high flexibility to create variants for automated and manual testing
- possess lightweight structure due to its presentation layer pattern
- is scalable and easy to expand
- maintenance effort could be lower and scalability could be better - even though the app has a solid structure and complies to some of the SOLID principles, it cannot be considered as part of Clean Architecture, mainly because the Presenter contains most of the logic, therefore substituting Interactors (use-cases)
- possess medium complexity - other approaches might lower complexity and increase efficiency
- the app is not a polished ready-to-publish product, it acts as a boilerplate project or as a starting point for android enthusiasts out there
- using this project as your starting point and expanding it is also encouraged, as at this point it is very easy to add new modules
- forks are encouraged