Buzzvil Client Modularization

Buzzvil Client Modularization

Buzzvil Client Modularization

15bd1106c5a327d6564f793a1951f269?s=128

Buzzvil

July 29, 2020
Tweet

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