Best practices for a modularized app with dynamic features

Leo Chu
LINE App Dev Team1 Android Engineer
https://linedevday.linecorp.com/2020/ja/sessions/6647
https://linedevday.linecorp.com/2020/en/sessions/6647

Transcript

2. Agenda › Introduction › Android Modularization › Best Practices › Implementation Example
3. LINE History & Features › 2011: Free text messaging, Free Calls, Stickers › 2012: Home, Timeline › 2013: Video calls › 2014: “LINE Premium Call” More Services & Features: LINE Out (LINE Premium Call), LINE Pay, LINE NEWS, LINE Shopping, LINE MUSIC, LINE Official Account, LINE Ads, LINE LIVE, LINE Coupon, LINE Kakeibo, LINE Meeting, LINE Square (Open Chat), LINE Sticker Premium, Timeline Stories, FacePlay, Icons Suggestion, Android wear support, Combined Search, Pop-up Stickers, In-App Browser, LIFF (LINE Front-end framework), BLE support, quick reply, Dark mode ...
4. LINE Android Project Status in 2019 › 100+ contributors at the main repository › 33 modules › 1.4 million lines of source code
5. 66% of code is in the app module
6. Issues of App Module with 66% Code › Unreadable structure › Slow build time: ≈17mins (for the first build without remote cache) › Large app size: ≈248MB
7. Modularize App Module
8. Current Modularization Project status › New 20 modules are created › New 0.27M lines of source code are created in separate modules (Still ongoing) › 10% of source code in app modules are moved to other modules
9. Agenda › Introduction › Android Modularization › Best Practices › Implementation Example
10. Four types of modules in a multi-module android app › Dynamic Feature Module › Android Library Module › Application Module › Pure Java/Kotlin Library Module
11. Four types of modules in a multi-module android app › Dynamic Feature Module › Android Library Module › Application Module › Pure Java/Kotlin Library Module
12. › Is a standalone module › Can be reused by other apps › Is for library development › Improves build time Library Module › Depends on Application Module › Can delay the delivery (onDemand/ Instant) › Improves build time › Reduce app size Dynamic Feature Module Difference between Library and Feature module
13. How to approach the modularization?
14. › Uses Library Module › Splits independent utility/library › May require large refactoring Top-down: › Uses Dynamic Feature Module › Splits features depending on app module › May minimize affected code Bottom-up: Two different approaches
15. › Uses Library Module › Splits independent utility/library › May require large refactoring Top-down: › Uses Dynamic Feature Module › Splits features depending on app module › May minimize affected code Bottom-up: Two different approaches
16. Top-down Approach with library module
17. Top-down Approach with library module
18. › Uses Library Module › Splits independent utility/library › May require large refactoring Top-down: › Uses Dynamic Feature Module › Splits features depending on app module › May minimize affected code Bottom-up: Two different approaches
19. Bottom-up Approach with dynamic feature module
20. Bottom-up Approach with dynamic feature module
21. Top-down (Library module) Bottom-up (Feature module) Access App Module Can’t Can Refactoring cost High Small Side-effect Large Limited
22. › Testability: › Performance: › Dependency Structure: Disadvantages of Dynamic Feature Module › 50+ installed features on single device lead to performance issue › 10+ removable install-time delivery modules increase the download and install time › Known Issues: › Uploaded bundle required › Data Binding issue and Unit Testing issue › Dynamic feature module depends on application module
23. Only apply dynamic feature module when it is necessary!
24. Decision Making Flowchart
25. Agenda › Introduction › Android Modularization › Best Practices › Implementation Example
26. Best Practices › Set ProGuard rule for data binding › Use Service Locator › Decide conventions of resources › Manage Library version at root directory For Dynamic Feature Modules › Separate interface and implementation at different modules
27. Best Practice #1: Use Service Locator Lich Component Library (https://github.com/line/lich/tree/master/component) Related talk: Modernize the development of LINE Messenger for android - Masakuni Oishi (https://speakerdeck.com/line_devday2019/ modernize-the-development-of-line-messenger-for- android)
28. Modernize the development of LINE Messenger for Android https://speakerdeck.com/line_devday2019/modernize-the-development-of-line-messenger-for-android?slide=40
29. Inside App Module
30. Inside App Module
31. Inside App Module
32. Inside Dynamic Feature Module
33. Inside Dynamic Feature Module
34. Inside Dynamic Feature Module
35. Inside Dynamic Feature Module
36. Inside App Module
37. Inside App Module
38. Inside App Module
39. Modernize the development of LINE Messenger for android https://speakerdeck.com/line_devday2019/modernize-the-development-of-line-messenger-for-android?slide=41
40. Best Practices › Set ProGuard rule for data binding › Use Service Locator › Decide conventions of resources › Manage Library version at root directory For Dynamic Feature Modules › Separate interface and implementation at different modules
41. Data Binding with obfuscation: Problem › Cause: Related DataBinderMapper at dynamic feature module is not found
42. Data Binding with obfuscation: Problem › Cause: Related DataBinderMapper at dynamic feature module is not found
43. Data Binding with obfuscation: Problem › Cause: Related DataBinderMapper at dynamic feature module is not found
44. Data Binding with obfuscation: Problem › Cause: Related DataBinderMapper at dynamic feature module is not found
45. Data Binding with obfuscation: Solution › Best Practice #2: Set a ProGuard rule to keep `DataBinderMapper` classes name explicitly
46. Best Practices › Set ProGuard rule for data binding › Use Service Locator › Decide conventions of resources › Manage Library version at root directory For Dynamic Feature Modules › Separate interface and implementation at different modules
47. Resources conflict: Problem › Cause: Different modules share the same resource IDs but with different contents
48. Resources conflict: Solution › Add module name prefix › Create a common resources library › Best Practice #3: Decide conventions to avoid ID conflicts
49. Best Practices › Set ProGuard rule for data binding › Use Service Locator › Decide conventions of resources › Manage Library version at root directory For Dynamic Feature Modules › Separate interface and implementation at different modules
50. Library versions conflict: Problem › Cause: Different modules use the same library but different versions
51. Library versions conflict: Solution › Best Practice #4: Manage Library versions at root directory
52. Best Practices › Set ProGuard rule for data binding › Use Service Locator › Decide conventions of resources › Manage Library version at root directory For Dynamic Feature Modules › Separate interface and implementation at different modules
53. Best Practice #5: Separate interface and implementation at different modules › Can reuse the feature on the other apps › Restrict the unnecessary dependency › Can easily convert the dynamic feature module to android library module
54. Dynamic Feature Module: Android Library Module: Best Practice #5: Separate interface and implementation at different modules
55. Agenda › Introduction › Android Modularization › Best Practices › Implementation Example
56. Project structure
57. Project structure
58. App module
59. Project structure
60. Dynamic feature contract module
61. Project structure
62. Dynamic feature module
63. Summary › Avoid using any classes or resources from the app module in feature modules › Modularize your app as soon as possible › Apply dynamic feature module ONLY when it is necessary
64. More information Sharing experiences of adapting AppBundle on LINE Android CI (Young-Cha) › About how to adapt dynamic feature module on CI Enforcing code conventions with Lint (Daniel Vila) › Using lint to maintain the code health of your modular app project
65. Thank you