Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

Google Developers Group Lviv

October 13, 2018
Tweet

More Decks by Google Developers Group Lviv

Other Decks in Technology

Transcript

  1. Architecture for AppBundles
    DevFest Ukraine

    View full-size slide

  2. Architecture for Dynamic Feature Modules
    DevFest Ukraine

    View full-size slide

  3. What dynamic feature modules mean for my
    existing architecture?
    DevFest Ukraine

    View full-size slide

  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

    View full-size slide

  5. Architecture for AppBundles
    DevFest Ukraine

    View full-size slide

  6. Mateusz Herych
    Android Team Lead, IG
    Co-organizer, GDG Kraków
    Ex-organizer, Droidcon Kraków
    GDE

    View full-size slide

  7. Our developer life up to January 2018

    View full-size slide

  8. Our developer life up to January 2018
    - app module for the Android stuff

    View full-size slide

  9. Our developer life up to January 2018
    - app module for the Android stuff
    - core module for the business logic

    View full-size slide

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

    View full-size slide

  11. Our developer life up to January 2018
    - Lots of useless interfaces just to map stuff from one module to another.

    View full-size slide

  12. 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)

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  16. New challenge

    View full-size slide

  17. New challenge
    - Expanding to a new market

    View full-size slide

  18. New challenge
    - Expanding to a new market
    - Produce a new trading app for that market

    View full-size slide

  19. 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’

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  24. Onboarding Session Markets Payments Dealing

    View full-size slide

  25. Onboarding Session Markets Payments Dealing
    Base
    App

    View full-size slide

  26. Payments
    Onboarding Session Markets Payments Dealing
    Base
    App
    TINY! Only
    utilities here
    TINY! Just gluing
    stuff together.

    View full-size slide

  27. 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)

    View full-size slide

  28. Let’s see some code.

    View full-size slide

  29. Because modules need to navigate
    between each other.

    View full-size slide

  30. Imagine
    - User see a market list (that belongs to the `markets` module)

    View full-size slide

  31. Imagine
    - User see a market list (that belongs to the `markets` module)
    - Tapping on the market item moves you to a dealing screen

    View full-size slide

  32. 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)

    View full-size slide

  33. Navigation
    - Within the module, you just inject your navigator interface… voila!

    View full-size slide

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

    View full-size slide

  35. 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)

    View full-size slide

  36. Sometimes you display things from
    different modules, on a single Activity.

    View full-size slide

  37. markets
    markets
    onboarding
    dealing
    accounts

    View full-size slide

  38. NavigationDrawer

    View full-size slide

  39. NavigationDrawer Base

    View full-size slide

  40. Decorators
    - Actual DecoratorCommand implementations can be defined within modules

    View full-size slide

  41. Decorators
    - Actual DecoratorCommand implementations can be defined within modules
    - App decides which DecoratorCommands to use

    View full-size slide

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

    View full-size slide

  43. Guess what, we were pretty
    happy about this.

    View full-size slide

  44. And then… AppBundles!

    View full-size slide

  45. First impression: nice, we’ll be able to
    benefit from our shiny & fresh modular
    structure!

    View full-size slide

  46. Second impression: …. Ooops!

    View full-size slide

  47. Some blogposts claim, that Dynamic
    Feature Modules are like Android Library
    Modules.
    But there’s a pretty fundamental
    difference.

    View full-size slide

  48. Dynamic Feature modules depend on
    your ‘base app’. Not vice versa.

    View full-size slide

  49. In other words: ‘app’ (or ‘base’) won’t be
    able to access the classes of a dynamic
    feature module.

    View full-size slide

  50. Instead, dynamic feature module, will
    have an access to the classes of the
    `base` module.

    View full-size slide

  51. But this actually makes a lot of sense.

    View full-size slide

  52. You don’t have to change your
    architecture to support AppBundles - you
    can benefit from them without much of
    the effort.

    View full-size slide

  53. Purpose of our modular approach: good
    separation, lack of coupling between
    features enforced in compile-time.

    View full-size slide

  54. Purpose of Dynamic Feature Modules:
    smaller APK size (good separation
    coming more as a ‘side-effect’).

    View full-size slide

  55. Onboarding Session Markets Payments Dealing
    Base
    App

    View full-size slide

  56. Onboarding Session Markets Payments Dealing
    Base
    App
    Dynamic Feature
    Module A
    Dynamic Feature
    Module B

    View full-size slide

  57. Common Issues
    - Starting Activities

    View full-size slide

  58. Common Issues
    - Starting Activities
    - Attaching Fragments / other UI components to ‘base’ activities

    View full-size slide

  59. Starting Activities
    Not much to talk about really. Simple as:

    View full-size slide

  60. What about non Activities?
    TODO TODO TODO

    View full-size slide

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

    View full-size slide

  62. 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?

    View full-size slide

  63. Start using AppBundles.

    View full-size slide

  64. You can benefit from them
    at nearly zero effort.

    View full-size slide

  65. Dynamic Feature Modules - you may
    need them, but you may not.

    View full-size slide

  66. Also… they aren’t that scary and don’t
    really require you to rewrite everything at
    once.

    View full-size slide

  67. Thanks! QA time

    View full-size slide