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 Slide

  2. Architecture for Dynamic Feature Modules
    DevFest Ukraine

    View Slide

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

    View 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 Slide

  5. Architecture for AppBundles
    DevFest Ukraine

    View Slide

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

    View Slide

  7. Trading 101

    View Slide

  8. View Slide

  9. View Slide

  10. View Slide

  11. Our developer life up to January 2018

    View Slide

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

    View Slide

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

    View Slide

  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.

    View Slide

  15. Problems?

    View Slide

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

    View Slide

  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)

    View Slide

  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

    View Slide

  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.

    View Slide

  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.

    View Slide

  21. New challenge

    View Slide

  22. New challenge
    - Expanding to a new market

    View Slide

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

    View Slide

  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’

    View Slide

  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

    View Slide

  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

    View Slide

  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.

    View Slide

  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.

    View Slide

  29. Structure

    View Slide

  30. Onboarding Session Markets Payments Dealing

    View Slide

  31. Onboarding Session Markets Payments Dealing
    Base
    App

    View Slide

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

    View Slide

  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)

    View Slide

  34. Let’s see some code.

    View Slide

  35. Navigation

    View Slide

  36. Because modules need to navigate
    between each other.

    View Slide

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

    View Slide

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

    View Slide

  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)

    View Slide

  40. View Slide

  41. markets

    View Slide

  42. app

    View Slide

  43. app, again

    View Slide

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

    View Slide

  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.

    View Slide

  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)

    View Slide

  47. Decorators.

    View Slide

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

    View Slide

  49. View Slide

  50. markets
    markets
    onboarding
    dealing
    accounts

    View Slide

  51. NavigationDrawer

    View Slide

  52. NavigationDrawer Base

    View Slide

  53. View Slide

  54. Base

    View Slide

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

    View Slide

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

    View Slide

  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

    View Slide

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

    View Slide

  59. And then… AppBundles!

    View Slide

  60. View Slide

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

    View Slide

  62. Second impression: …. Ooops!

    View Slide

  63. View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  68. But this actually makes a lot of sense.

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  72. Onboarding Session Markets Payments Dealing
    Base
    App

    View Slide

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

    View Slide

  74. Common Issues
    - Starting Activities

    View Slide

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

    View Slide

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

    View Slide

  77. What about non Activities?
    TODO TODO TODO

    View Slide

  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.

    View Slide

  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?

    View Slide

  80. Start using AppBundles.

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  84. Thanks! QA time

    View Slide