You can help me improve by giving me advice on my LinkedIn!
This application has the objective of containing basic things for a good architecture in android projects, this project will improve sequentially first by migrating the MVVM project to Modular Architecture. This project is carried out in my National University of the Altiplano as a basic work, which I am refactoring to become a guide for android developers. Any comment you can communicate with me through my Linkedin CESAR
In the proyect i used Firestore, Bugsnack, Coroutines, Navigation Dynamic,Mockk , JUnit5 and Others.
The elements of the project change according to some things, such as if you are logged in, if you are an administrator and many other things. The project only displays basic flowchart options. Modules such as viewing applications, super user type user and many more are missing.
| Mode | Light | Dark |
|---|---|---|
| HOME |  |
 |
| CATEGORY |  |
 |
| DETAIL ADD |  |
 |
| PROFILE |  |
 |
| AUTH |  |
 |
| AUTH CODE |  |
 |
| POSTULATE |  |
 |
| MY ADDS |  |
 |
The architecture of the application is based, apply and strictly complies with each of the following 5 points:
- A single-activity architecture, using the Navigation component to manage fragment operations.
- Android architecture components, part of Android Jetpack for give to project a robust design, testable and maintainable.
- Pattern Model-View-ViewModel (MVVM) facilitating a separation of development of the graphical user interface.
- S.O.L.I.D design principles intended to make software designs more understandable, flexible and maintainable.
- Modular app architecture allows to be developed features in isolation, independently from other features.
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:
:appdepends on:coreand indirectly depends on:featuresby dynamic-features.:featuresmodules depends on:commons,:core,:librariesand:app.:coreand:commonsonly depends for possible utils on:libraries.:librariesdon’t have any dependency.
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.
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.
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.
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.
The :libraries modules are an com.android.library, basically contains different utilities that can be used by the different modules.
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.
Cesar Mamani
