2. What is the App modularization
Modular programming
● Is a software design technique
● Separates a program into modules according to the functionality
Module
● Is independent and interchangeable
● Contains everything necessary
● Contains only one aspect of the desired functionality
“App Modularization is to modularize the Android App.”
3. Why do we need to modularize app
● Faster build time
● Separation of concerns
● Fine-grained dependency control
● Improved reusability across other apps
● Improved the ownership & the quality of the codebase
5. Separation of Concerns
● A basic principle of software design
● Software modules should have distinct responsibilities as much as
possible
Appshell
Feed Locker Tutorial
Auth Ad Content
14. Feature Module
Appshell
Feature Feature Feature
Library Library Library
● Feature is a unit of app functionality
● Feature module can be divided into more smaller feature modules
○ The smaller is the better
● Boundary depends on stakeholder’s decision
● Feature module is not referred by other feature modules
● Feature module may have the view or not
● Dependency scope should be created for each module
15. Library Module
Appshell
Feature Feature Feature
Library Library Library
● There can be redandant codes between feature modules
● Redandant codes should be extracted into the library
● Recommendations
○ No business logic for specific feature
○ Stateless
16. Considerations
● Do we need a core module?
○ Core module is a module that has no state and has removed its business logic completely
● Should android service belong to feature module?
● How can we define auth module?
● Should we design each module to follow a specific architecture?
● Should we make the dynamic feature module?
17. Should we need a core module?
● Core module is a module that has no state and has removed its business
logic completely
● There are not many modules yet
● It is better to manage Library and Core modules together
Library
Core Library
Core
Feature Feature Feature
Appshell
18. Should android service belong to feature module?
● Android service
○ Could be a feature module
○ Could be a library module, otherwise
○ Depends on the stakeholder’s decision
19. How can we define auth module?
Appshell
Feed Locker Tutorial
Auth Ad Content
● Define auth module as a library module that has purely authentic logic
without any feature-specific logic
● Define feed module as a feature module that handles to login using auth
module
20. Should we design each module to follow a specific architecture?
● Each module can be built with independant architecture
● Some modules have data and domain layer
● Some modules have only one class
● Therefore, no rule can be defined for the architecture we must follow
21. Should we make the dynamic feature module?
● One of module belongs to the app bundle, being pushed by google
○ Allowing the module not to be installed at the initial installation
○ Reducing the app size
● The key point is the inversion of dependency between app and module
● If we have well architectured modules, we can integrate it easily at anytime
22. Module Navigation
● Each feature modules don’t know class in another module
● Therefore, navigator should be injected to the feature modules
● How to implement?
○ Reflection
○ DI Interface
○ Jetpack Navigation
29. Which implementation of navigation should we choose
● Navigation is one of the most important module on modularization
● Navigation needs changeable abstraction
● Reflection seems to be the best for now
○ There are use case of major company
○ It can implement without any dependencies
● Jetpack’s navigation seems to be restricted yet
34. LiveData
● Callback or Listener : simple and easy
● RxJava : reactive stream and functional operator
● LiveData : reactive stream and lifecycle management
We do not have to enforce certain principles
36. Source Control Management
● Git
○ DVCS
○ Based on Snapshot
○ Sensitive to the size of repository
● Mercurial
○ DVCS
○ Based on Patch
○ Not sensitive to the size of repository
Depends on the code scale.
→ Git is better for now
37. Branching Strategy
● Git Flow
○ Well-defined branching procedures
○ There can be many conflicts during the merging process.
● Trunk Based Development
○ Always ready to be released
○ Universal versioning
○ Simple merging strategy
Trunk Based Development is better for monorepo.
40. Version Management
● Do not assign a version to each module
○ Management of each version causes dependency hell
● Just assign only universal version
41. Build Tool
● Gradle
○ Google Standard
○ Simple and easy
○ Slow in many modules
● Buck
○ Used by Facebook, Uber, and Twitter
○ Challenging configuration
○ Fast in many modules
● Bazel
○ Used by Google
○ Challenging configuration
○ Fast in many modules
Depends on the code scale.
Gradle is better for now
42. Continuous Integration
● There are so many tools for CI
● It does not matter which tool we use
● The most important part is to build and test the exact modules we need