Buzzvil Client Modularization

Buzzvil Client Modularization

Transcript

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
25. Navigation with Interface
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
39. Trunk Based Development
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