Fragments deprecated in Android P
The rewrite in Support Library 27.1.0
Ian's medium post (Feb 28, 2018) gives us an explanation about it. He is Android Framework Developer at Google.
Loaders in Support Library 27.1.0
For Support Library 27.1.0, I rewrote the internals of LoaderManager, the class powering the Loaders API and I wanted to explain the reasoning behind the changes and what to expect going forward.
Loaders and Fragments, a history
From the beginning, Loaders and Fragments were pretty tightly tied together at the hip. This meant that a lot of the code in FragmentActivity and Fragment were there to support Loaders, despite the fact that there are indeed fairly independent. …What’s changed in 27.1.0
With 27.1.0, the technical debt of Loaders has been greatly reduced: ……
Note: Obviously, these changes only apply to Support Library Loaders. If you are using Android framework Loaders, please switch to the Support Library Loaders as soon as possible. There are no bug fixes or improvements planned for the framework Loader APIs.
It seems like the code in Fragment and FragmentActivity has been refactored in order to make Loaders an optional dependency.
According to the release note, the new implementation is based on Lifecycle.
Important Changes
The underlying implementation of Loaders has been rewritten to use Lifecycle.
Architecture Components
In Support Library 26.1.0, Fragment and FragmentActivity has adopted Lifecycle.
This is a special release to integrate the Support Library with Lifecycles from Architecture Components. If you are not using the Lifecycles library, you don’t need to update from 26.0.2. For more information, see the Architecture Components release notes.
Important changes
- Fragment and FragmentActivity (the base class for AppCompatActivity) now implement the LifecycleOwner interface from Architecture Components.
By contrast, Fragment and Activity in Android P have not implemented the interface LifecycleOwner.
In the Google+ post (mentioned in ThanosFisherman’s answer), Ian made a comment:
you can't change framework code after it has shipped - it is literally frozen in time. That means no new features and more importantly no bug fixes. That's not a good developer experience, particularly when we do have a fully supported, up to date, backward compatible version in the Support Library.
I think that’s the reason why Android P doesn't adopt Lifecycle. Consequently Fragment is deprecated in Android P.
In case anyone was looking for the way to instantiate fragments by the class name.
Old way:
Fragment.instantiate(context, fragmentClass)
New way:
val fm: FragmentManager = ...fm.fragmentFactory.instantiate(ClassLoader.getSystemClassLoader(), fragmentClass)Using an extension:
File name: FragmentManagerExt.kt
import androidx.fragment.app.Fragmentimport androidx.fragment.app.FragmentManagerfun FragmentManager.instantiate(className: String): Fragment { return fragmentFactory.instantiate(ClassLoader.getSystemClassLoader(), className)}Example usage:
val fragment = supportFragmentManager.instantiate(fragmentClassName)
Support Library Fragments are here to stay. Google encourages you to use the Support Library versions to get consistent behavior across all API levels, backported bug fixes, and Lifecycle and ViewModel support.