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!)

This article is based on Android Jetpack: How to Smartly Use Fragments in Your UI (Google I/O ‘18).

The Story So Far

#

Everybody Started Writing Activity

#

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

Enter Tablets

#

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

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 a factory you provide
• LiveData allows easy (lifecycle-aware!) reconnection
• Replaces 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 owners of Lifecycle, ViewModel, and views, so Google wants to make it easy for developers to use them.

• Focusing on making “how you move from one screen to another” 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 the 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:
  • Directly manage menus as Toolbar View data

Testing Fragments

#

Driving 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 officially deprecated

Impressions / Summary / Key Takeaways

#

• Use one Activity for one entry point, and use Fragments to display content on the screen.
  • The trend is to leave Fragment back stack management and screen transition animations entirely to Navigation.
• By delegating the role of displaying content entirely to Fragments as reusable components, we can achieve reusable and “pain-free” app development => This is the purpose of AAC, and specifically Navigation, which was prepared for Fragments this time.
• By using Navigation, developers no longer need to worry about the “pain” of Fragments and boilerplate code around animations.
• While some “painful” existing platform APIs and support library APIs remain, in the future, they will be rebuilt on top of new APIs like AAC (similar to how LoaderManager was rebuilt to depend on LiveData).
• Using AAC in app development seems likely to become essential for safer and faster app development in the future.

That’s all!