A demo showcasing the industry standard approach (Multi modules , MVVM , CLEAN, Compose) for developing in android
This application takes the approach of extreme code isolation by distributing various components of the application in modules. The following modules together make the application
This module would not have any dependencies. However THIS WILL BE a dependency for the other modules in the application. As the name suggests this module will house common functionality that is required throughout the application. Most importantly this will host
- Base classes of various android components ( Fragments, Activites)
- Extension methods that would be used in the application
- Styles
None
This module will be the one which would be the entry point of our application. This module will be responsible for creating our DI container and also host the main build gradle file as well as the android manifest. This module will be dependent on all the other modules in the application. This is necessary for it to create the DI Container graph. Other than creating the dependency graph , this module has no other purpose than to launch the landing page of the application (which would reside in another module)
- Create the DI container
- Launch the landing page of the application
- implementation project(":common")
- implementation project(":repositories")
- implementation project(":network")
- implementation project(":stocksListFeature")
- implementation project(":business")
This module will hold all the non UI code of our application. In clean architecture way of speaking , this would hold the usecases for our application. This module will not be aware of the UI which would use the business it exposes. This module will have dependencies over the repository module of our application
- Provide usecases for our application (used by the UI )
- implementation project(":repositories")
- implementation project(":common")
- implementation project(":dtos")
This module will hold the repositories for all the data entities we are to work with in our application.
- Provide data to the business module
- implementation project(":dtos")
- implementation project(":network")
- implementation project(":common")
This module is the glue which binds the UI with the data it needs to display. The UI is never aware of anything other than the business module. However the challenge then would be to send a piece of data upstream from repositories to business to UI. Dtos is a module on which the UI , business and repositories are together dependent , without being aware of each other directly. This gives us isolation of the UI with the rest of the system
- Provide the DTOs to the UI (which would be translated version of the actual data coming from Room/Web)
None
This module exists at the lowest level of the application module graph. By that I mean , this module has no dependencies and only the Repository module is the only module which is aware of this module
- Provide the network related functionality to the application (Retrofit lives in this module)
- implementation project(":common")
- implementation project(":dtos")
This would be the module which would host the stock list feature of the application. This feature includes two composables and takes its data from the business module. Other than business module , this UI would be completely agnostic of the rest of the system
- Provide a list of stocks.
- Provides detail of a single stock (Repeats every 8 seconds).
- implementation project(":business")
- implementation project(":common")
- implementation project(":dtos")
The only test cases in the application as of now are relating to the BaseViewModel
- BaseViewModelTest - Repository Test