• Loaders in Support Library 27.1.0
  • Originally written by Ian Lake
  • The Nuggets translation Project
  • Permanent link to this article: github.com/xitu/gold-m…
  • Translator: dreamhb
  • Proofread by: Starriers

To support library 27.1.0, I have rewritten the internal structure of the LoaderManager, on which the Loaders API is based. I also want to explain why these changes are made and what to expect next.

A short history of loaders and fragments

In the beginning, Loader and Fragment are closely linked. This means that there is a lot of code in FragmentActivity and Fragment to support the Loader, but in fact they are barely related. This also means that the Loader lifecycle and safeguards are completely unique and subject to interesting and exciting behavior differences and bugs compared to the Activity, Fragment and architectural component lifecycle.

Changes in 27.1.0

In 27.1.0, Loader legacy issues have been significantly reduced: LoaderManager has only a third as many lines of code as before, and there are plenty of tests to keep Loader in good shape for the future.

All of these glorify architectural components. More specifically, ViewModel (which maintains state when configuration changes) and LiveData(which supports life cycles and callbacks). Today’s Loaders are based on and benefit from these higher-level, well-tested components, reducing incremental performance losses and improving Loader reliability and correctness.

Behavior change

This does mean some behavior change.

First, initLoader, restartLoader, and destroyLoader must be called in the main thread. This provides some very special guarantees that at the end or beginning of a callback, for example after destroying a loader, you will never get the onLoadFinished callback.

Note: Technically, before this release, you could do loader operations in other threads, but LoaderManager is no longer thread-safe, resulting in frequent undefined behavior.

Most importantly, onLoadFinished is now, like LiveData Observers, always called between onStart and onStop, and not after onSaveInstanceState. This way you can safely do Fragment Transactions in onLoadFinished.

What should I use? What about loader?

As I mentioned in my previous blog Lifecycle Aware Data Loading with Architecture Components, I strongly recommend that developers use a combination of ViewModel+LiveData, I think they are definitely a more flexible and easier to understand system. However, if you already have loader-based APIs, these changes should greatly improve component dependability and stability in the future.

This many change Loader into a function, more optional, don’t need to do to LifecycleOwner/ViewModelStoreOwner is at the bottom of the modification.

Give it a try!

If you are using Loader, please take a close look at the behavior changes as soon as possible, they are all in the release.

Note: Obviously, only the support library has these changes. If you are using an Android Loader, please switch to the support library as soon as possible. There will be no bug fixes or planned improvements to the Loader APIs for the framework.

The Nuggets Translation Project is a community that translates quality Internet technical articles from English sharing articles on nuggets. The content covers Android, iOS, front-end, back-end, blockchain, products, design, artificial intelligence and other fields. If you want to see more high-quality translation, please continue to pay attention to the Translation plan of Digging Gold, the official Weibo, Zhihu column.