Presentation by Gabor Varadi (@zhuinden)
What Activity and Fragment actually are in Android
What are the problems they solve, and what are their downsides
How to use a custom solution that simplifies navigation in Android applications
https://github.com/Zhuinden/navigation-example
2. What do we think we know about
Activities?
From https://developer.android.com/guide/components/intents-filters.html
„Starting an activity
An Activity represents a single screen in an app.
You can start a new instance of an Activity by
passing an Intent to startActivity().
The Intent describes the activity to start and
carries any necessary data.”
3. What do we think we know about
Fragments?
From https://developer.android.com/guide/components/fragments.html
„A Fragment represents a behavior or a portion
of user interface in an Activity. You can combine
multiple fragments in a single activity to build a
multi-pane UI and reuse a fragment in multiple
activities.”
5. Dianne Hackborn
„How should I design my Android
application?”
Activity
Once we have gotten in to this entry-point to your UI, we really don't
care how you organize the flow inside.
Make it all one activity with manual changes to its views, use
fragments (a convenience framework we provide) or some other
framework, or split it into additional internal activities. Or do all three
as needed.
As long as you are following the high-level contract of activity (it
launches in the proper state, and saves/restores in the current state),
it doesn't matter to the system.
6. What does that tell us?
• Activities are not „screens”, they are entry points to the
app (like a main function)
• The high-level Activity contract is showing UI for current
state, handling initial state, and persist state across
configuration change and process death
• Fragments are just a „convenience framework” —
technically they are ViewControllers with lifecycle
integration
• Android does NOT care how you handle the flow inside
your application!
7. Wait, process death?
• Step 1: put app in background with HOME
• Step 2: press „Terminate application”
• Step 3: restart app from launcher
• Step 4: enjoy strange behavior
(app restart, statics are cleared, savedInstanceState != null)
8. What IS the flow inside your
application?
• Navigation
– where you are in your application (and what to show)
– where you came from, back/up navigation
– remembering navigation state across config change
and process death
• Scoping
– what data needs to be shown
– what services need to exist (singleton and subscopes)
– how to keep scoped services alive across config
change
10. Passing objects through the context
hierarchy: getSystemService() trick
• Any object can be exposed via the Context
hierarchy by overriding getSystemService()
• Objects from Activity (and the activity!) can be
exposed directly via Activity.getSystemService()
• Objects in subscope of Activity can be exposed
through ContextWrapper.getSystemService()
by inflating the view with a cloned layout inflater
LayoutInflater.from(baseContext)
.cloneInContext(contextWrapper);
11. Exposing objects through the Context
from the Activity
public class MainActivity
extends AppCompatActivity {
private static final String TAG = "MainActivity";
public static MainActivity get(Context context) {
// noinspection ResourceType
return (MainActivity)context.getSystemService(TAG);
}
@Override
public Object getSystemService(String name) {
if(TAG.equals(name)) {
return this; // <-- now MainActivity.get(context) works
}
return super.getSystemService(name);
}
}
12. public class KeyContextWrapper extends ContextWrapper {
public static final String TAG = "Backstack.KEY";
LayoutInflater layoutInflater;
final Object key;
public KeyContextWrapper(Context base, @NonNull Object key) {
super(base);
this.key = key;
}
public static <T> T getKey(Context context) {
// noinspection ResourceType
Object key = context.getSystemService(TAG);
// noinspection unchecked
return (T) key;
}
@Override
public Object getSystemService(String name) {
if(Context.LAYOUT_INFLATER_SERVICE.equals(name)) {
if(layoutInflater == null) {
layoutInflater = LayoutInflater.from(getBaseContext())
.cloneInContext(this);
}
return layoutInflater;
} else if(TAG.equals(name)) {
return key; // <-- now KeyContextWrapper.getKey(context) works
}
return super.getSystemService(name);
}
}
14. Scoping
Allowing data and services to exist for the entire duration of
when the screen is visible, and not be killed on configuration
changes.
Child scopes should be able to inherit from their superscope.
Things that set out to solve scoping problem:
- Activity: onRetainCustomNonConfigurationInstance()
- Fragment: retained fragments
- Loaders
- square/Mortar: MortarScope
- lyft/Scoop: Scoop
- zhuinden/Service-Tree: ServiceTree
- Architectural Components: ViewModel
15. Goal of scoping
• The goal is to make sure the data and services exist for as long as
the scope
• When the scope is destroyed (as it is no longer needed), the data
and services are torn down along with it
• In advanced use:
– scoped data becomes a dependency that is provided to
constructor, but obtained asynchronously and observed for
changes
(LiveData, BehaviorRelay, Observable + RxReplayingShare)
– Dagger component is subscoped, and provides the data as
scoped dependency
– The Dagger component is stored in the scope to survive
configuration changes
18. The common approach to simplifying
the problem
• Create only Singleton scope (and a single global
injector), everything else is unscoped
• Unscoped dependencies have their state
persisted to Bundle, and restored if state exists
• Also: if the ViewController is preserved even
without its view hierarchy, then it can BE the
scope!
(retained fragments, Conductor’s Controller)
19. Navigation
• We must know where we are, remember where we have been
• This state must be preserved across configuration changes and
process death
• Things that set out to solve Navigation problem:
– Activity record stack
– Fragment backstack
– square/flow 0.8
– lyft/scoop
– square/flow 1.0-alpha3
– terrakok/Cicerone (no backstack, only command queue)
– bluelinelabs/Conductor
– zhuinden/simple-stack
– wealthfront/magellan (don’t use it – does NOT preserve state
across process death!!!)
20. Checklist for what a backstack should
be able to do
• Handling state persistence across config change /
process death
• Should receive both the previous and the new state on
state change
• Animations are asynchronous – operations must be
enqueued
• State changer is not always available (after onPause) –
operations must be enqueued
21. How do Activities handle navigation?
• Intents to start new Activities
• Parameters are provided in the extras Bundle, generally
as a dynamically typed storage with string keys
• Intents have „intent flags” to manipulate „task stack”
(CLEAR_TOP, REORDER_TO_FRONT, etc.)
• Downsides:
– You can’t easily tell what Activities exist in the background
– Modifying stack needs tricky combinations of intent flags
(no fine-grained control)
– No notifications about change (previous state, new state)
– Complicated lifecycle if multiple Activities exist
23. How are Fragments generally used for
navigation?
• FragmentTransactions (begin/commit)
• Tutorials typically show „replace()” in conjunction with
„addToBackStack()”
• The backstack stores transactions (operations) with a tag to
pop to (inclusive/exclusive)
• (Parameters are also provided as Bundle, called arguments)
• Downsides:
– onBackstackChanged() provides change notification, but does
not provide previous and new states (also it’s kinda random)
– Stack stores operations instead of active fragments, so
asymmetric navigation is super-difficult
– commit() runs transaction on the NEXT event loop
(what about onPause?
„Cannot perform after onSaveInstanceState()”)
24. Principle of Flow (and its variants)
• „Flow” is a custom backstack to store current state and
history
• Content of the backstack is saved to and restored from
Bundle (for process death) as Parcelables
• State is represented as immutable parcelable value objects,
called Keys
• Keys contain all necessary data in order to set up the initial
state (like Intent extras), but as typed values of the class
• List of previous / new keys are both available („Traversal”,…)
25. @AutoValue
public abstract class TaskDetailKey
implements Key, Parcelable {
public abstract String taskId(); // <- instead of static final TASK_ID = „TASK_ID”;
public static TaskDetailKey create(String taskId) {
return new AutoValue_TaskDetailKey(R.layout.path_taskdetail, taskId);
}
@Override
public int menu() {
return R.menu.taskdetail_fragment_menu;
}
@Override
public boolean isFabVisible() {
return true;
}
@Override
public View.OnClickListener fabClickListener(View view) {
return v -> {
((TaskDetailView)view).editTask();
};
}
@Override
public int fabDrawableIcon() {
return R.drawable.ic_edit;
}
}
26. @PaperParcel
data class TaskDetailKey(val taskId: String)
: Key, PaperParcelable {
override fun layout() = R.layout.task_detail
override fun menu() = R.menu.taskdetail_fragment_menu
override fun isFabVisible() = true
override fun fabClickListener(view: View) {
return View.OnClickListener {
v -> (view as SecondView).editTask()
}
}
override fun fabDrawableIcon() = R.drawable.ic_edit
companion object {
@JvmField val CREATOR = PaperParcelTaskDetailKey.CREATOR
}
}
28. Displaying the View for a given Key
• Our Key specifies what we want to show
• We need to handle the events of the views (clicks, text
changes, etc.)
• For that, we need a „ViewController” (which can be used
inside an Activity, so not an Activity)
• Possible options:
– Custom ViewGroup
– Fragment
– lyft/scoop’s ViewController
– square/coordinators’s Coordinator
– bluelinelabs/Conductor’s Controller
32. Same thing using library defaults
Navigator.install(this, root,
HistoryBuilder.single(FirstKey.create()));
Or showing off some configuration builders...
Navigator.configure()
.setStateChanger(DefaultStateChanger
.configure()
.create(this, root))
.install(this, root,
HistoryBuilder.single(FirstKey.create()));
34. But what about Fragments?
• Fragments are also ViewControllers
• Activity provides them with lifecycle integration
out of the box
• FragmentManager keeps track of them and their
state transitions
• All added fragments are recreated after process
death by super.onCreate() in Activity
• (Supports nesting out of the box... with caveats)
35. Fragment Ops beyond „replace”
• Other useful operators of FragmentTransaction:
– Add/remove:
• Create fragment and its view hierarchy
• Destroy view hierarchy, and fragment as well
– Attach/detach:
• Restore view state, (re-)create view hierarchy
• preserve view state, but destroy view hierarchy
– commitNow():
• Execute the fragment transaction synchronously
• Note: this method cannot be used alongside addToBackStack()
• Using these operators, we can combine this with a custom
backstack, by keeping the fragments and their state alive,
but only the currently visible view hierarchy.
36. Key for the Fragment
public abstract class BaseKey implements Key {
@Override
public String getFragmentTag() {
return toString();
}
@Override
public final BaseFragment newFragment() {
BaseFragment fragment = createFragment();
Bundle bundle = fragment.getArguments();
if (bundle == null) {
bundle = new Bundle();
}
bundle.putParcelable("KEY", this); // => <T> T getKey() { … }
fragment.setArguments(bundle);
return fragment;
}
protected abstract BaseFragment createFragment();
}
37. Handling state change with Fragments
• Remove all Fragments that were in previous
state, but are no longer in the new state
(if they are still in new state, then just detach
them)
• Create and add all fragments that are in the new
state and not yet added
• In the new state, if the current top already exists
but is detached, then attach it, if it doesn’t exist,
then create it and add it
(and detach all other non-top fragments)
• Commit transaction now
41. Additional resources
Advocating against Android Fragments
Simpler Apps with Flow and Mortar
Michael Yotive: State of Fragments in 2017
Simplified Fragment Navigation using a custom
backstack
Communication between same-level components => superscoped service with change listeners
Flow: Traversal, Scoop: RouteChange, Simple-Stack: StateChange, Conductor: RouterTransaction
Keys were also once called „Screen”
This code runs for the current top state, both on forward AND back navigation!
Mortar’s ViewPresenter was responsible for Custom Viewgroup’s onSaveInstanceState() integration. It wasn’t particularly good though and could result in very hard to fix state persistence bugs.
