Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (20)
Similar a Android Modularization
Similar a Android Modularization (20)
Más de Young-Hyuk Yoo
Último
Último (20)
Android Modularization
- 1. Buzzvil Client Modularization Created by Ethan Yoo
- 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
- 4. Faster build time App Feature Feature Library Library Build only what we need Build by Parallel Feature Feature Library Library
- 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
- 6. Fine-grained dependency control ● Reusability ● Scalability ● Testability Appshell Feed Locker Tutorial Auth Ad Content
- 7. Improved reusability across other apps H/S Feed Locker Tutorial Auth Ad Content S/J
- 8. Improved the ownership & the quality of the codebase H/S Feed Locker Tutorial Auth Ad Content S/J JD MJ Josh
- 9. How to modularize ● Modularization by Feature ● Modularization by Library
- 10. Modularize by Feature Feature is a unit of app functionality App App Feature Feature Feature
- 11. Modularize by Library App Feature Feature Feature App Feature Feature Feature Library Library Library Make a library module for sharing code
- 12. ● Appshell Module ● Feature Module ● Library Module Multi Module Architecture App Appshell Feature Feature Feature Library Library Library
- 13. Appshell Module Appshell Feature Feature Feature Library Library Library ● Dependency Injection ○ Feature Module ○ Library Module ○ Navigator ● Project build script ● Project configs. (ex : APP_KEY)
- 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
- 23. Navigation with Reflection (Google) Google’s example
- 24. Navigation with Reflection (Airbnb) Airbnb’s example
- 26. Navigation with Jetpack’s Navigation
- 27. Navigation with Jetpack’s Navigation
- 28. Navigation with Jetpack’s Navigation If you wanna more information, visit this
- 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
- 30. Module Communication ● Callback or Listener Interface ● RxJava ● LiveData
- 31. Callback or Listener Interface
- 32. RxJava
- 33. LiveData
- 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
- 35. Source Repository ● Multirepo vs Monorepo Monorepo is better
- 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.
- 38. Git Flow
- 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
- 43. 3rd Party Library ● Dagger ● RxJava ● LiveData ● ViewModel Just use it
- 44. Q & A