Notes - Build a Modular Android App Architecture (Google I/O '19)

In this Notes article, I roughly jotted down notes in English from the content of the English session video/podcast. This article is intended to be read as a reference while watching the video. I hope this article helps you even a little when you watch the actual video. (Please feel free to contact me if there are any errors or typos! m(__)m)

This article is based on Build a Modular Android App Architecture (Google I/O'19).

Why Modularize your app?

#

• People can specialize in certain sections of the application

• Maintainability

  • grouping layouts based on features

• Faster compilation

• Faster CI

  • Only modified module and the modules that depend on that module need to be tested.

  • How we do it in AndroidX

    • Discover dependency graph

    • Find changed fines from Git History

    • Execute all testes of affected modules

    • URL: goo.gle/androidx-dependency-tracker

• Good for business

  • Smaller APKs using the Android App bundle

• Isolated feature testing

How to modularize?

#

Dynamic Feature Module

#

• App can’t depend on modules; modules depend on app

• onDemand=“false”, onDemand=“true”

• Feature Modularization

Layer modularization

#

• Plaid Features

  • Persistence

  • API client / Authentication

  • Custom Styling Library

  • Feed UI

  • Post UI

Isolation via modules

#

• api vs implementation

  • if module is provided through api all of the public api are available for all the modules depending on that module.

  • if module is provided through implementation then all the modules depending on that module cannot see any public api

Feature modularization

#

• Encapsulation

• Possibility for dynamic delivery

Layer modularization

#

• Isolation to your app

• Structure to your app

If you are starting from the monolithic app

#

• Start with layer modularization

Working with dynamic feature modules

#

• Navigation

  • starting activity

    • setClassName

  • starting fragment

  • Class.forName()..

    • Needs ProGuard

    • No runtime performance hits

=> Currently working on it with navigation jetpack library to make this navigation as natural as possible.

Databases

#

• One common database

  • Pros

    • Very easy to maintain database connection

    • Easy to share tables

  • Cons

    • No isolation between modules

    • Feature specific entities are in shared domain

• One database per module

  • Pros

    • Isolation between modules

  • Cons

    • Database connection maintenance

    • Duplicate data

• A hybrid approach

A bright feature with Room

#

• Multi-module databases with room

  • Separate databases combined at runtime

  • Cross-module database queries

• Not available yet

Android free modules

#

The benefits of it will be..

• Faster tests

• Minimize dependencies

• Separation of concerns

• Better abstractions

But do not do this if ..

• you don’t have a use case for it / do not use it

• you don’t have time; abstraction takes time

TL;DR

#

• Start re-writing your application in modules

• Just options

• Always keep your customers and users in your mind

Impressions / Summary / Key Takeaways

#

• Modularization could also shorten test execution time in CI.
• The implementation of screen transitions in DFM-compatible projects is likely to be improved to a more natural form with Navigation Architecture Components in the future.
• Room is likely to add features anticipating multi-module environments in the future.
• The message “No user will give you 5 stars because your architecture is good! Whatever you do, think about the users!” really resonated with me.

That’s all!