[Mateusz Herych] Architecture for App Bundles

Presentation from GDG DevFest Ukraine 2018 - the biggest community-driven Google tech conference in the CEE.

Learn more at: https://devfest.gdg.org.ua

__

Android App Bundles were one of the most exciting announcements during this years Google I/O - they help you leverage the modular architecture of your apps in order to optimize your users' downloads. This all sounds cool, but what if your current codebase isn't modular at all?

During this presentation Mateusz will guide you through his team's journey of splitting a huge, monolithic app into smaller, independent pieces responsible for specific experiences. The journey that they started even before AppBundles were a thing. Join this talk to learn how:

- You can set up your dependency injection (e.g. with Dagger) with a multimodular project structure that AppBundles enforce.
- To navigate between different modules within your app.
- You can benefit from AppBundles beyond 'just' the architecture
- To structure your app modules in the version control system.
- You can reuse those modules across different apps.
- And more!

Transcript

1. Architecture for AppBundles DevFest Ukraine
2. Architecture for Dynamic Feature Modules DevFest Ukraine
3. What dynamic feature modules mean for my existing architecture? DevFest Ukraine
4. Will my team need to spend 2 man-years refactoring the code just to make our app compatible with that new thing Google announced at the I/O? DevFest Ukraine
5. Architecture for AppBundles DevFest Ukraine
6. Mateusz Herych Android Team Lead, IG Co-organizer, GDG Kraków Ex-organizer, Droidcon Kraków GDE
7. Trading 101
11. Our developer life up to January 2018
12. Our developer life up to January 2018 - app module for the Android stuff
13. Our developer life up to January 2018 - app module for the Android stuff - core module for the business logic
14. Our developer life up to January 2018 - app module for the Android stuff - core module for the business logic - data module for Jackson POJOs, Retrofit gateways, etc. - App depends on core & data. Data depends on core.
15. Problems?
16. Our developer life up to January 2018 - Lots of useless interfaces just to map stuff from one module to another.
17. Our developer life up to January 2018 - Lots of useless interfaces just to map stuff from one module to another. (aka well abstracted, clean code)
18. Our developer life up to January 2018 - Lots of useless interfaces just to map stuff from one module to another. (aka well abstracted, clean code) - Mappers everywhere
19. Our developer life up to January 2018 - Lots of useless interfaces just to map stuff from one module to another. (aka well abstracted, clean code) - Mappers everywhere - Even simplest changes required recompiling all of the modules - quite a massive incremental build times.
20. Our developer life up to January 2018 - Lots of useless interfaces just to map stuff from one module to another. (aka well abstracted, clean code) - Mappers everywhere - Even simplest changes required recompiling all of the modules - quite a massive incremental build times. - Single feature spread across entire codebase.
21. New challenge
22. New challenge - Expanding to a new market
23. New challenge - Expanding to a new market - Produce a new trading app for that market
24. New challenge - Expanding to a new market - Produce a new trading app for that market - It has a relatively small functionality subset of the ‘monolith’
25. New challenge - Expanding to a new market - Produce a new trading app for that market - It has a relatively small functionality subset of the ‘monolith’ - Most of those features behave the same
26. New challenge - Expanding to a new market - Produce a new trading app for that market - It has a relatively small functionality subset of the ‘monolith’ - Most of those features behave the same - … and look the same
27. New challenge - Expanding to a new market - Produce a new trading app for that market - It has a relatively small functionality subset of the ‘monolith’ - Most of those features behave the same - … and look the same - Core logic - dealing… is completely different.
28. New challenge - Expanding to a new market - Produce a new trading app for that market - It has a relatively small functionality subset of the ‘monolith’ - Most of those features behave the same - … and look the same - Core logic - dealing… is completely different. - All the logic we do for the new app - we want it to be reusable in the monolith later on.
29. Structure
30. Onboarding Session Markets Payments Dealing
31. Onboarding Session Markets Payments Dealing Base App
32. Payments Onboarding Session Markets Payments Dealing Base App TINY! Only utilities here TINY! Just gluing stuff together.
33. Few decisions - Feature modules don’t depend on each other - UI and the business logic are split - App depends on all the feature modules - All feature modules depend on base - (which means ‘base’ has to be app-agnostic)
34. Let’s see some code.
35. Navigation
36. Because modules need to navigate between each other.
37. Imagine - User see a market list (that belongs to the `markets` module)
38. Imagine - User see a market list (that belongs to the `markets` module) - Tapping on the market item moves you to a dealing screen
39. Imagine - User see a market list (that belongs to the `markets` module) - Tapping on the market item moves you to a dealing screen - (which belongs to the `dealing` module, which isn’t known by the `markets` module)
41. markets
42. app
43. app, again
44. Navigation - Within the module, you just inject your navigator interface… voila!
45. Navigation - Within the module, you just inject your navigator interface… voila! - Each module defines the interface with all the cross-module navigation actions it may trigger.
46. Navigation - Within the module, you just inject your navigator interface… voila! - Each module defines the interface with all the cross-module navigation actions it may trigger. - Then, the exact behavior, is defined by the `app` module (which defines the navigation between modules)
47. Decorators.
48. Sometimes you display things from different modules, on a single Activity.
50. markets markets onboarding dealing accounts
51. NavigationDrawer
52. NavigationDrawer Base
54. Base
55. Decorators - Actual DecoratorCommand implementations can be defined within modules
56. Decorators - Actual DecoratorCommand implementations can be defined within modules - App decides which DecoratorCommands to use
57. Decorators - Actual DecoratorCommand implementations can be defined within modules - App decides which DecoratorCommands to use - Some Decorators make use from the contract - e.g. you need to have R.id.bottomContainer within your Activity’s layout
58. Guess what, we were pretty happy about this.
59. And then… AppBundles!
61. First impression: nice, we’ll be able to benefit from our shiny & fresh modular structure!
62. Second impression: …. Ooops!
64. Some blogposts claim, that Dynamic Feature Modules are like Android Library Modules. But there’s a pretty fundamental difference.
65. Dynamic Feature modules depend on your ‘base app’. Not vice versa.
66. In other words: ‘app’ (or ‘base’) won’t be able to access the classes of a dynamic feature module.
67. Instead, dynamic feature module, will have an access to the classes of the `base` module.
68. But this actually makes a lot of sense.
69. You don’t have to change your architecture to support AppBundles - you can benefit from them without much of the effort.
70. Purpose of our modular approach: good separation, lack of coupling between features enforced in compile-time.
71. Purpose of Dynamic Feature Modules: smaller APK size (good separation coming more as a ‘side-effect’).
72. Onboarding Session Markets Payments Dealing Base App
73. Onboarding Session Markets Payments Dealing Base App Dynamic Feature Module A Dynamic Feature Module B
74. Common Issues - Starting Activities
75. Common Issues - Starting Activities - Attaching Fragments / other UI components to ‘base’ activities
76. Starting Activities Not much to talk about really. Simple as:
77. What about non Activities? TODO TODO TODO
78. What is a good candidate for a dynamic feature module? - Something that only portion of your users need. - Something that users won’t likely need in a short-time after the installation.
79. What is a good candidate for a dynamic feature module? - Something that only portion of your users need. - Something that users won’t likely need in a short-time after the installation. Document Upload feature? Maybe Payments?
80. Start using AppBundles.
81. You can benefit from them at nearly zero effort.
82. Dynamic Feature Modules - you may need them, but you may not.
83. Also… they aren’t that scary and don’t really require you to rewrite everything at once.
84. Thanks! QA time