[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
   

   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