My previous app was an android banking app. It is a neo bank. And it got tons of features relative to different financial products. I establish the basic architecture with mvvm + navigation component . One activity with fragments. Everything works perfectly thanks for jetpack. Easy to refactor and developing based on this architecture. Also a lot of interesting details with di, motionlayout, paging, navigation, coroutine, viewmodel. Again still work perfectly.
What makes this app more special is the multiple modular developing, we manage 8 engineers at the whole time, 10+ with out-source agencies developers. How do we avoid code conflicts and make codes more clear. I introduce the concept of the multiple modular developing. There are some modern software companies are already using them and share their experience on the internet. (#1)
Basically design your app separated by features. and I believe those features are in distinguish UI layer in your app (If you are saying it's not, I serious doubt the UX and everything on that app). For example your app is a tab-layout, each tab represented a feature. Then you can separate your app into different features. The whole launch app was in the App module and each tabs' codes are lying each `Feature #` modules. And move the whole common codes(string res, network, database, utilities..etc) into the bottom layers of modules. So the basic diagram would looks like this.
Furthermore as your app growth, the diagram can be designed more and more complicated like this
There are pros and one con of this developing methods.
- Good for you team members to know where they should focus on and totally ignore other teams simultaneously developing codes.
- All the features are reusable, disposable based on requirement. As long as you manager your project dependencies clean and compact.
- Google play now support `Dynamic Feature` based on this architecture, maybe someday your pm has crazy thoughts on this feature.
- Test would be easier and single launch is possible if you design and mock it right.
The con is. As the modules growth, the required build time of android studio takes longer. And there are some methods to avoid this.
- Use di to inject blank UI so other modules won't be involved during builds.
- Use local maven to store the local build of each modules. They won't be rebuild anymore. Only focus and rebuild on the module you work on.(#2)
Here I shared a simple app demonstrate such a concept.
https://github.com/hydrated/CurrencySample
https://github.com/hydrated/CurrencySample
Appendix
#2
