メインコンテンツへスキップ

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

f🆔shaunkawano:20190509003256p:plain

※Notes記事では、英語のセッション動画やポッドキャストの内容を(雑に)英語でメモに書き残すことを行っています。本記事は、あくまで動画を見ながら、参考程度に読んでいただくことを想定しています。Notes記事には雑メモ程度のものだったり、書き起こしのようなものもあります。これから実際の動画を見る際には、本記事の内容が少しでもお役に立てば幸いです。(内容において不備、誤字脱字等ありましたら気軽にご連絡いただけると嬉しいです!m(__)m)

本記事は、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

所感・まとめ・個人的に印象に残ったことなど
#

  • モジュール化することでCIでのテスト実行時間も短縮できそう

  • DFM対応のプロジェクトの画面遷移の実装方法は、今後Navigation Architecture Componentsでより自然な形に改善されそう

  • Roomには今後マルチモジュールを見据えた機能が追加されそう

  • アーキテクチャが良いからという理由で☆5つをくれるユーザーはいないよ!何するにしてもユーザーのこと考えてね!が刺さった

以上です!