Buzzvil Client Modularization

by Buzzvil

Embed

Start on current slide

Slide 1

Slide 1 text

Buzzvil Client Modularization Created by Ethan Yoo

Slide 2

Slide 2 text

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.”

Slide 3

Slide 3 text

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

Slide 4

Slide 4 text

Faster build time App Feature Feature Library Library Build only what we need Build by Parallel Feature Feature Library Library

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

Fine-grained dependency control ● Reusability ● Scalability ● Testability Appshell Feed Locker Tutorial Auth Ad Content

Slide 7

Slide 7 text

Improved reusability across other apps H/S Feed Locker Tutorial Auth Ad Content S/J

Slide 8

Slide 8 text

Improved the ownership & the quality of the codebase H/S Feed Locker Tutorial Auth Ad Content S/J JD MJ Josh

Slide 9

Slide 9 text

How to modularize ● Modularization by Feature ● Modularization by Library

Slide 10

Slide 10 text

Modularize by Feature Feature is a unit of app functionality App App Feature Feature Feature

Slide 11

Slide 11 text

Modularize by Library App Feature Feature Feature App Feature Feature Feature Library Library Library Make a library module for sharing code

Slide 12

Slide 12 text

● Appshell Module ● Feature Module ● Library Module Multi Module Architecture App Appshell Feature Feature Feature Library Library Library

Slide 13

Slide 13 text

Appshell Module Appshell Feature Feature Feature Library Library Library ● Dependency Injection ○ Feature Module ○ Library Module ○ Navigator ● Project build script ● Project conﬁgs. (ex : APP_KEY)

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

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 speciﬁc feature ○ Stateless

Slide 16

Slide 16 text

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 deﬁne auth module? ● Should we design each module to follow a speciﬁc architecture? ● Should we make the dynamic feature module?

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

Should we design each module to follow a speciﬁc 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 deﬁned for the architecture we must follow

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

Module Navigation ● Each feature modules don’t know class in another module ● Therefore, navigator should be injected to the feature modules ● How to implement? ○ Reﬂection ○ DI Interface ○ Jetpack Navigation

Slide 23

Slide 23 text

Navigation with Reﬂection (Google) Google’s example

Slide 24

Slide 24 text

Navigation with Reﬂection (Airbnb) Airbnb’s example

Slide 25

Slide 25 text

Navigation with Interface

Slide 26

Slide 26 text

Navigation with Jetpack’s Navigation

Slide 27

Slide 27 text

Navigation with Jetpack’s Navigation

Slide 28

Slide 28 text

Navigation with Jetpack’s Navigation If you wanna more information, visit this

Slide 29

Slide 29 text

Which implementation of navigation should we choose ● Navigation is one of the most important module on modularization ● Navigation needs changeable abstraction ● Reﬂection 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

Slide 30

Slide 30 text

Module Communication ● Callback or Listener Interface ● RxJava ● LiveData

Slide 31

Slide 31 text

Callback or Listener Interface

Slide 32

Slide 32 text

RxJava

Slide 33

Slide 33 text

LiveData

Slide 34

Slide 34 text

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

Slide 35

Slide 35 text

Source Repository ● Multirepo vs Monorepo Monorepo is better

Slide 36

Slide 36 text

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

Slide 37

Slide 37 text

Branching Strategy ● Git Flow ○ Well-deﬁned branching procedures ○ There can be many conﬂicts during the merging process. ● Trunk Based Development ○ Always ready to be released ○ Universal versioning ○ Simple merging strategy Trunk Based Development is better for monorepo.

Slide 38

Slide 38 text

Git Flow

Slide 39

Slide 39 text

Trunk Based Development

Slide 40

Slide 40 text

Version Management ● Do not assign a version to each module ○ Management of each version causes dependency hell ● Just assign only universal version

Slide 41

Slide 41 text

Build Tool ● Gradle ○ Google Standard ○ Simple and easy ○ Slow in many modules ● Buck ○ Used by Facebook, Uber, and Twitter ○ Challenging conﬁguration ○ Fast in many modules ● Bazel ○ Used by Google ○ Challenging conﬁguration ○ Fast in many modules Depends on the code scale. Gradle is better for now

Slide 42

Slide 42 text

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