heihei blog

Blog icon by Unsplash https://unsplash.com/@virussinside

Notes - Android Jetpack how to smartly use Fragments in your UI (Google IO 18)

content-notes android io18

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

本記事は、Android Jetpack how to smartly use Fragments in your UI (Google IO 18)の記事です。

f:id:shaunkawano:20180512195201p:plain

The Story so far

Everybody started writing Activity

  • Entry point to your application system
  • main() with lifecycle
  • Creates views
  • Binds view

Enter tables

  • Phone UI + Phone UI = Tablet UI
  • How do I stick two phone UIs together?
  • Enter tables

Fragments of an Activity

  • Design goal of fragments allow splitting up huge Activity classes
  • Requirement: anything an Activity can do, a Fragment can do
    • Lifecycle events
    • Managing view hierarchies
    • Saved instance state
    • Non-configuration instance object passing
    • Back stacks

Can we fix some other APIs?

  • onRetainNonConfigurationInstance
  • Activity#showDialog
  • TabHost/LocalActivityManager

Factoring Activities

  • Recipe for breaking up monoliths:
    • Move loosely related code to separate fragments
    • Repeat

↓

Factoring Activities Fragments

  • Recipe for breaking up monoliths:
  • Move loosely related code to separate fragments
  • Repeat

Things Fragments do

  • Lifecycle hooks
  • Back stack management
  • Retain objects across configuration changes
  • (Instance:)Stateful presence in the FragmentManager
  • Manage a View subtree
  • inflatable, reusable components

Architecture Components

Focuses on doing one thing well

LifecycleObservers

  • Strict ordering callback: Last in, first out
  • Created by you, not recreated via reflection
  • NO stateful restoration by the system
  • Isolated, minimal component, easy to test, easy to inject

ViewModel

  • Instances are created by factory you provide
  • LiveData allows easy (lifecycle aware!) reconnection
  • Replace retained instance Fragments
  • Your Activities or Fragments do not have to know where the data comes from; ViewModel is responsible for getting and passing data

Navigation

Fragments are good to be owner of Lifecycle, ViewModel, and views, so Google wants to make it easy for developers to use.

  • Focusing on making "How you move one screen to another screen" better
  • Works well with Fragments
  • Replaces back stack transactions

Why Fragments in 2018?

Android layering

Package Managing

android.widget vs. android.app

  • android.widget - Mechanism

    • Shows state to the user
    • Reports user interaction events

  • android.app - Policy

    • Defines state to bind to widgets
    • Responds to user interaction and issues changes to model

Inflatable Components

ViewGroups that got too smart

  • Composed high-level controls
  • Self-sufficient
  • Lifecycle aware
  • Inflated attributes can become Fragment arguments

=> Cross-cutting UI policy

  • Self sufficient components
  • Ads
  • Independent info cards
  • Parent doesn't need to be involved in data routing from repository

App Screens

Tastes great with Navigation!

Use Activity just as an entry point, and Fragments for showing actual contents

  • Single-Activity apps
  • Common app chrome, decoupled destinations
  • Transitions and animations managed by Navigation, not by hand
  • Can inflate sub-components to help

DialogFragment

Managing another interaction

  • Interaction with another..
    • Floating UI
    • System interaction
  • Leverage instance state restoration
  • Dialogs, bottom sheets
  • Transient UIs you don't want to lose

Options Menus

We still don't have a great answer for this

Merging menus for your Toolbar

  • Fragments support options menus
  • Common use case: setSupportActionBar
    • Useful for fixed common chrome
    • FragmentPagerAdapter
  • Alternative:
    • Directory manage menus as Toolbar View data

Testing Fragments

Diving Fragment Lifecycles

  • FragmentController drives lifecycle
  • Test your larger components in greater isolation
  • Possible, if not the best interface

Loaders

Now decoupled from Fragments!

  • Rebuild on top of LiveData and ViewModel
  • use Loaders from any LifecycleOwner+ViewModelStoreOwner

Where are we going?

  • Separate desired behavior from incidental behavior
  • Reimplementing existing APIs on top of new primitives
    • e.g. LoaderManager on LiveData
  • Make primitive signals and Activity callbacks available to any interested component
  • If you don't like Fragments, write your own!
    • No more magic
    • Use the same composable hooks
  • Fragments + your components working together
  • android.app.Fragment is now official deprecated

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

  • 1つのエントリーポイントに対して1つのActivityを、画面にコンテンツを表示するにはFragmentを利用していこう
    • その際のFragmentのBack Stack管理や画面遷移時のアニメーションなどは全てNavigationに任せようという流れ
  • 使いまわし可能なコンポーネントとして、コンテンツを表示する役割をFragmentに完全に任せることで、再利用可能かつ"つらみ"のないアプリ開発ができるようになる => そのためのAAC、そして今回特にFragmentのために用意されたNavigation
  • Navigationを使うことでFragmentのつらみ、Animation周りボイラープレートコードを開発者が気にする必要がなくなる
  • 未だに"つらみ"のある既存のプラットフォームAPIやサポートライブラリのAPIはあるが、今後はAACなどの新しいAPIの上に乗せる形で作り直すような例も出てくる(LoaderManagerがLiveDataに依存する形で作りなおされたように)
  • 今後はAACを使ったアプリ開発は、より安全かつより早くアプリ開発をする上で必須になりそう

以上です！