vmadalin

Android Modular Architecture

šŸ“š Sample Android Components Architecture on a modular word focused on the scalability, testability and maintainability written in Kotlin, following best practices using Jetpack.
Under Apache License 2.0
By vmadalin

kotlin android architecture hacktoberfest mvvm-architecture jetpack best-practices testing android-architecture clean-architecture clean-code solid dynamic-features android-boilerplate component-architecture solid-principles gradle-kotlin-dsl modular-architecture android-showcase modern-android-development

Android Components Architecture in a Modular Word



Android Components Architecture in a Modular Word is a sample project that presents modern, 2020 approach to Android application development using Kotlin and latest tech-stack.


The goal of the project is to demonstrate best practices, provide a set of guidelines, and present modern Android
application architecture that is modular, scalable, maintainable and testable. This application may look simple, but it
has all of these small details that will set the rock-solid foundation of the larger app suitable for bigger teams and
long application lifecycle management.


Table of Contents

Mentions

The project received different mentions/reference from Android Developer Community:



Development
Environment setup

First off, you require the latest Android Studio 4.1.0 (or newer) to be able to build the app.


You need to supply keys for Marvel API. You can find information about how to gain access by using the link.


When you obtain the keys, you can provide them to the app by putting the following in the local.properties project root file:


```properties


Marvel API KEYS

marvel.key.public =
marvel.key.private =
```


Code style

To maintain the style and quality of the code, are used the bellow static analysis tools. All of them use properly configuration and you find them in the project root directory .{toolName}.


| Tools | Config file | Check command | Fix command |
|---------------------------------------------------------|----------------------------------------------------------------------------------:|---------------------------|---------------------------|
| detekt | /.detekt | ./gradlew detekt | - |
| ktlint | - | ./gradlew ktlint | ./gradlew ktlintFormat |
| spotless | /.spotless | ./gradlew spotlessCheck | ./gradlew spotlessApply |
| lint | /.lint | ./gradlew lint | - |


All these tools are integrated in pre-commit git hook, in order
ensure that all static analysis and tests passes before you can commit your changes. To skip them for specific commit add this option at your git command:


properties
git commit --no-verify


The pre-commit git hooks have exactly the same checks as CircleCI and are defined in this script. This step ensures that all commits comply with the established rules. However the continuous integration will ultimately be validated that the changes are correct.


Design

App support different screen sizes and the content has been adapted to fit for mobile devices and tablets. To do that, it has been created a flexible layout using one or more of the following concepts:



In terms of design has been followed recommendations android material design comprehensive guide for visual, motion, and interaction design across platforms and devices. Granting the project in this way a great user experience (UX) and user interface (UI). For more info about UX best practices visit link.


Moreover, has been implemented support for dark theme with the following benefits:
- Can reduce power usage by a significant amount (depending on the deviceā€™s screen technology).
- Improves visibility for users with low vision and those who are sensitive to bright light.
- Makes it easier for anyone to use a device in a low-light environment.


| Mode | Characters list | Characters favorite | Character detail |
|-------|--------------------------------------------------------------------------|------------------------------------------------------------------------------|---------------------------------------------------------------------------|
| Light | | | |
| Dark | | | |


Architecture

The architecture of the application is based, apply and strictly complies with each of the following 5 points:




Modules

Modules are collection of source files and build settings that allow you to divide a project into discrete units of functionality. In this case apart from dividing by functionality/responsibility, existing the following dependence between them:




The above graph shows the app modularisation:
- :appĀ depends onĀ :core and indirectly depends on :features by dynamic-features.
- :features modules depends onĀ :commons, :core, :libraries and :app.
- :core and :commons only depends for possible utils on :libraries.
- :libraries donā€™t have any dependency.


App module

TheĀ :appĀ module is anĀ com.android.application, which is needed to create the app bundle. It is also responsible for initiating the dependency graph, play core and another project global libraries, differentiating especially between different app environments.




Core module

The :coreĀ module is an com.android.library for serving network requests or accessing to the database. Providing the data source for the many features that require it.




Features modules

The :features module are an com.android.dynamic-featureĀ is essentially a gradle module which can be downloaded independently from the base application module. It can hold code and resources and include dependencies, just like any other gradle module.


| features |
|:----------------------------------------------------------------------------------------:|
| |
| |
| |


Commons modules

The :commons modules are an com.android.library only contains code and resources which are shared between feature modules. Reusing this way resources, layouts, views, and components in the different features modules, without the need to duplicate code.


| ui | views |
|:----------------------------------------------------------------------:|:-------------------------------------------------------------------------:|
| | |


Libraries modules

The :libraries modules are an com.android.library, basically contains different utilities that can be used by the different modules.




Architecture components

Ideally, ViewModels shouldnā€™t know anything about Android. This improves testability, leak safety and modularity. ViewModels have different scopes than activities or fragments. While a ViewModel is alive and running, an activity can be in any of its lifecycle states. Activities and fragments can be destroyed and created again while the ViewModel is unaware.


Passing a reference of the View (activity or fragment) to the ViewModel is a serious risk. Lets assume the ViewModel requests data from the network and the data comes back some time later. At that moment, the View reference might be destroyed or might be an old activity that is no longer visible, generating a memory leak and, possibly, a crash.



The communication between the different layers follow the above diagram using the reactive paradigm, observing changes on components without need of callbacks avoiding leaks and edge cases related with them.


Build variants

The application has different product flavours: Dev, QA, Prod. Each variant has a specific target environment and to make easier to distinguish them the app uses a specific icon colour for debug and release build variant with descriptive app name. In this case and given that it's a sample, all variants have the same Marvel API endpoint.
But the idea is to have different environments target for Development and QA respectively, what doesn't affect the production environment. This is applicable to any tool, platform, service what is being used. For more information about build variant, check this link.


| Types | DEV | QA | PROD |
|---------|:-------------------------------------------------------------------------------:|:------------------------------------------------------------------------------:|:----------------------------------------------------------------------------:|
| Debug |

MarvelDEV

|

MarvelQA

|

Marvel

|
| Release |

MarvelDEV

|

MarvelQA

|

Marvel

|


Documentation

The documentation is generated following KDoc language (the equivalent of Java's JavaDoc) via documentation engine for Kotlin Dokka.


To consult it check this link or open the project /docs directory.


Tech-stack

This project takes advantage of many popular libraries, plugins and tools of the Android ecosystem. Most of the libraries are in the stable version, unless there is a good reason to use non-stable dependency.


Dependencies

Test dependencies

Plugins

Resources
Projects

This is project is a sample, to inspire you and should handle most of the common cases, but obviously not all. If you need to take a look at additional resources to find solutions for your project, visit these interesting projects:



Articles

A collection of very interesting articles related last android community tendencies and recommendations for start to take in consideration for your current/next project:



Libraries

The open-source community create and maintains tons of awesome libraries making your job more easy, giving the opportunity to use them in your developments. Here are a very important collection of them:



Best practices

Avoid reinventing the wheel by following these guidelines:



Codelabs

Google Developers Codelabs provide a guided, tutorial, hands-on coding experience. Most codelabs will step you through the process of building a small application, or adding a new feature to an existing application. They cover a wide range of android concepts to learn and practice:



Contributions

All contributions are welcome!
Please feel free to post questions, recommendations, ideas, bugs by create new issue following the template or if you want create directly new pull request.


Authors




Madalin Valceleanu



License

```license
Copyright 2019-2020 vmadalin.com


Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at


http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.
```