Android-Architecture

Provides information on Android Architecture.

Libraries and tools included:

• Support libraries
• RecyclerViews
• RxJava and RxAndroid
• Retrofit 2
• Dagger 2
• DBFlow
• Butterknife
• Timber
• EventBus
• JobManager
• PlayService

This architecture is basically forked from android-boilerplate and improved by studying with other android architectures such as Androidstarter, Android-CleanArchitecture, Architecting Android…The evolution.

Before starting a new project please read Guidelines: Android

Please see Bibliography end of this page to get more detail about this architecture.

New project setup

To quickly start a new project from this boilerplate follow the next steps:

• Download this
• Change the package name.
  • Rename packages in main, androidTest and test using Android Studio.
  • In app/build.gradle file, packageName and testInstrumentationRunner.
  • In src/main/AndroidManifest.xml and src/debug/AndroidManifest.xml.
• Create a new git repository, GitHub tutorial.
• Replace the example code with your app code following the same architecture.
• In app/build.gradle add the signing config to enable release versions.
• Add Fabric API key and secret to fabric.properties and uncomment Fabric plugin set up in app/build.gradle
• Create keystore folder under app. Keep keystore in here. If you don't know how to create keystore please read Guidelines: Android
• Update proguard-rules.pro to keep models (see TODO in file) and add extra rules to file if needed.
• Update README with information relevant to the new project.
• Update LICENSE to match the requirements of the new project.

How to implement a new screen following MVP

Imagine you have to implement a sign in screen.

1. Create a new package under ui called signin
2. Create an new Activity called ActivitySignIn. You could also use a Fragment.
3. Define the view interface that your Activity is going to implement. Create a new interface called SignInMvpView that extends MvpView. Add the methods that you think will be necessary, e.g. showSignInSuccessful()
4. Create a SignInPresenter class that extends BasePresenter<SignInMvpView>
5. Implement the methods in SignInPresenter that your Activity requires to perform the necessary actions, e.g. signIn(String email). Once the sign in action finishes you should call getMvpView().showSignInSuccessful().
6. Create a SignInPresenterTestand write unit tests for signIn(email). Remember to mock the SignInMvpView and also the DataManager.
7. Make your ActivitySignIn implement SignInMvpView and implement the required methods like showSignInSuccessful()
8. In your activity, inject a new instance of SignInPresenter and call presenter.attachView(this) from onCreate and presenter.detachView() from onDestroy(). Also, set up a click listener in your button that calls presenter.signIn(email).

Please see the SampleActivity implementation.

Architecture Guidelines

The architecture of our Android apps is based on the MVP (Model View Presenter) pattern.

• View (UI layer): this is where Activities, Fragments and other standard Android components live. It's responsible for displaying the data received from the presenters to the user. It also handles user interactions and inputs (click listeners, etc) and triggers the right action in the Presenter if needed.

• Presenter: presenters subscribe to RxJava Observables provided by the DataManager. They are in charge of handling the subscription lifecycle, analysing/modifying the data returned by the DataManager and calling the appropriate methods in the View in order to display the data.

• Model (Data Layer): this is responsible for retrieving, saving, caching and massaging data. It can communicate with local databases and other data stores as well as with restful APIs or third party SDKs. It is divided in two parts: a group of helpers and a DataManager. The number of helpers vary between project and each of them has a very specific function, e.g. talking to an API or saving data in SharedPreferences. The DataManager combines and transforms the outputs from different helpers using Rx operators so it can: 1) provide meaningful data to the Presenter, 2) group actions that will always happen together. This layer also contains the actual model classes that define how the data structure is.

Looking at the diagram from right to left:

• Helpers (Model): A set of classes, each of them with a very specific responsibility. Their function can range from talking to APIs or a database to implementing some specific business logic. Every project will have different helpers but the most common ones are:

  • Network Services : Retrofit interfaces that talk to Restful APIs, each different API will have its own Retrofit service. They return Rx Observables.
  • DatabaseHelper: It handles inserting, updating and retrieving data from a local SQLite database. Its methods return Rx Observables that emit plain java objects (models)
  • PreferencesHelper: It saves and gets data from SharedPreferences, it can return Observables or plain java objects directly.
  • ConfigurationHelper : It saves and gets data from SharedPreferences too. It can return some instant config data related project. such as base api etc
  • JobManager : Priority Job Queue is an implementation of a Job Queue specifically written for Android to easily schedule jobs (tasks) that run in the background, improving UX and application stability.
  • Interceptors(Optional) : Interceptors are a powerful mechanism that can monitor, rewrite, and retry calls. For example if you need to add header for each call you may use.

• Data Manager (Model): It's a key part of the architecture. It keeps a reference to every helper class and uses them to satisfy the requests coming from the presenters. Its methods make extensive use of Rx operators to combine, transform or filter the output coming from the helpers in order to generate the desired output ready for the Presenters. It returns observables that emit data models.

• Presenters: Subscribe to observables provided by the DataManager and process the data in order to call the right method in the View.

• Activities, Fragments, ViewGroups (View): Standard Android components that implement a set of methods that the Presenters can call. They also handle user interactions such as clicks and act accordingly by calling the appropriate method in the Presenter. These components also implement framework-related tasks such us managing the Android lifecycle, inflating views, etc.

• Event Bus: It allows the View components to be notified of certain types of events that happen in the Model. Generally the DataManager posts events which can then be subscribed to by Activities and Fragments. The event bus is only used for very specific actions that are not related to only one screen and have a broadcasting nature, e.g. the user has signed out.

Distribution

The project can be distributed using the Google Play Store.

Play Store

We use the Gradle Play Publisher plugin. Once set up correctly, you will be able to push new builds to the Alpha, Beta or production channels like this

./gradlew publishApkRelease

Read plugin documentation for more info.

Crashlytics

You can also use Fabric's Crashlytics for distributing beta releases. Remember to add your fabric account details to app/src/fabric.properties.

To upload a release build to Crashlytics run:

./gradlew assembleRelease crashlyticsUploadDistributionRelease

Bibliography

• Ribot click
• Android-CleanArchitecture click
• Architecting Android…The evolution click
• Reak click
• Android Dev Summit 2015 click
• Mosby click
• Approaching Android with MVVM click