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

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

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を使ったアプリ開発は、より安全かつより早くアプリ開発をする上で必須になりそう

以上です！

The Story so far#

Everybody started writing Activity#

Enter tables#

Fragments of an Activity#

Can we fix some other APIs?#

Factoring Activities#

Factoring Activities Fragments#

Things Fragments do#

Architecture Components#

LifecycleObservers#

ViewModel#

Navigation#

Why Fragments in 2018?#

Android layering#

Package Managing#