Common problems with Fragments

their life cycle : complex (11 states) to whom we must add the coordination with the host activity

the asynchronicity of fragment transactions : not intuitive, can lead to unexpected behaviours

a confusion between fragment and view

Answers

On the mindset to have with Fragments

you don’t have to know the full fragment’s life cycle

Fragments are situated at a low level of abstraction (it is complex)

Android N

new life cycle method onAttachFragment() :

correspondence with Activity.onAttachFragment() called after the attachment of the fragment to the activity, to use for configuration tasks (eg : dependency injection, listener attachment, etc.)

already present in the support library

: correspondence with Activity.onAttachFragment() called after the attachment of the fragment to the activity, to use for configuration tasks (eg : dependency injection, listener attachment, etc.) already present in the support library FragmentTransaction.commitNow() :

transaction commit made synchronous, commit specific to the current transaction (FragmentManager.executePendingTransaction execute all the pending transactions, potentially initiated outside the current logic, eg : third-party libraries, etc.).

already present in the support library

: transaction commit made synchronous, commit specific to the current transaction (FragmentManager.executePendingTransaction execute all the pending transactions, potentially initiated outside the current logic, eg : third-party libraries, etc.). already present in the support library Following an orientation change, child Fragments will now be re-inflated (during super.onCreate()), they weren’t before.

no mention in the support library

no mention in the support library Guarantee of access to the ChildFragmentManager after super.onCreate() (before, when the execution of the transaction was forced by FragmentManager.executePendingTransaction(), the ChildFragmentManager was only accessible long after the onCreate()).

no mention in the support library

Some warnings

onAttach() and onCreate() can already have been executed when the Fragment transaction is effectively processed

Abstraction level of Fragments closer to Activities than Views

Similarities with Activity : single entry point, composable, life cycle managed by the framework, manage or not an user interface

Differences with View

a view manages a mechanism, a fragment a policy

a view is a widget, it manages actions on the UI (potentially complex), whereas a fragment is a controller, it connects app logic

These differences can also be found in the package structure : android.app contains application components, including Activity and Fragment, android.widget the standard views and android.view the basic views.

Toward smarter components

Adam Powell, the speaker, calls to develop smarter components with a single high level entry point. The use of Fragments from the layout file is an example of that.

Particular usage of Fragments

This presentation has led to some talks, in particular on libraries reconsidering the use of Fragments like Flow or more recently Conductor. The general idea is to use composed views to replace fragments. They permit in particular to manage the multipane screens like List/Detail screens (based traditionally on Fragments).

Flow proposes a navigation mechanism based on states corresponding to the different screens of the application.

As for Conductor, it wraps views to give access to life cycle methods.

To the opposite, as evoked in the reference article on Flow, it is also possible to use Fragments only (1 unique host Activity is still necessary). Benefit : your screen transitions will be faster and easier to set up than with Activities (use of view animations).

References :

Android Developer at jacquesgiraudel.com