[Mateusz Herych] Architecture for App Bundles

[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!

3a6de6bc902de7f75c0e753b3202ed52?s=128

Google Developers Group Lviv

October 13, 2018
Tweet

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

  8. None
  9. None
  10. None
  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)
  40. None
  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.
  49. None
  50. markets markets onboarding dealing accounts

  51. NavigationDrawer

  52. NavigationDrawer Base

  53. None
  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!

  60. None
  61. First impression: nice, we’ll be able to benefit from our

    shiny & fresh modular structure!
  62. Second impression: …. Ooops!

  63. None
  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