This is the second part of the series about tools and approaches for Android background.
In the previous one we mentioned AsyncTasks have several issues with them. Let’s recall a couple of those issues:
- AsyncTasks don’t know anything about the Activity lifecycle and therefore may introduce memory leaks at best and a crash at worst if used incorrectly.
- AsyncTasks don’t support progress or result reusage.
Taking a closer look on the first one, we need to cope with the following issue: as we want update the UI in onPostExecute method we need a reference to a particular view or an entire Activity the view is inflated to. The naive approach is to store that reference inside the AsyncTask itself:
| class WeatherForecastLoader(context: Context) : AsyncTaskLoader<WeatherForecast>(context) { | |
| override fun loadInBackground(): WeatherForecast { | |
| try { | |
| Thread.sleep(5000) | |
| } catch (e: InterruptedException) { | |
| return WeatherForecast("", 0F, "") | |
| } | |
| return WeatherForecast("Saint-Petersburg", 20F, "Sunny") | |
| } | |
| } |
The problem here is that once the user rotates the device the Activity gets destroyed and the reference becomes obsolete. This leads to a memory leak. How? Remember, that our doInBackground method is invoked within a Future executed on the static member of AsyncTask class, which makes our AsyncTask instance strongly reachable from the GC root(and the activity as well), thus not eligible for garbage collection. That means that several screen rotations causes OutOfMemoryError due to relatively large memory chunk occupied by the Activity object.
The fix to this OutOfMemory issue is a usage of WeakReferences:
| public static LoadWeatherForecastTask extends AsyncTask<String, Void, WeatherForecast> { | |
| private WeakReference<Activity> activityRef; | |
| LoadWeatherForecastTask(Activity activity) { | |
| this.activityRef = new WeakReference<>(activity); | |
| } | |
| } |
Well, we got rid of OOM but the result of an AsyncTaskis lost anyway and we are doomed to launch our AsyncTaskagain draining the battery and data plan.
The Android team suggested Loaders API to address the issue several years ago. Let’s check out how to use that API. We need to implement a Loader.Callbacks interface:
| inner class WeatherForecastLoaderCallbacks : LoaderManager.LoaderCallbacks<WeatherForecast> { | |
| override fun onLoaderReset(loader: Loader<WeatherForecast>?) { | |
| } | |
| override fun onCreateLoader(id: Int, args: Bundle?): Loader<WeatherForecast> { | |
| return WeatherForecastLoader(applicationContext) | |
| } | |
| override fun onLoadFinished(loader: Loader<WeatherForecast>?, data: WeatherForecast?) { | |
| temperatureTextView.text = data!!.temp.toString(); | |
| } | |
| } |
As you may notice the onLoadFinishedis really similar with onPostExecute we were implementing with AsyncTask.
We need to create a loader itself:
| class WeatherForecastLoader(context: Context) : AsyncTaskLoader<WeatherForecast>(context) { | |
| override fun loadInBackground(): WeatherForecast { | |
| try { | |
| Thread.sleep(5000) | |
| } catch (e: InterruptedException) { | |
| return WeatherForecast("", 0F, "") | |
| } | |
| return WeatherForecast("Saint-Petersburg", 20F, "Sunny") | |
| } | |
| } |
And call initLoader() with the our Loader id:
| override fun onCreate(savedInstanceState: Bundle?) { | |
| super.onCreate(savedInstanceState) | |
| ... | |
| val weatherForecastLoader = WeatherForecastLoaderCallbacks() | |
| loaderManager | |
| .initLoader(forecastLoaderId, Bundle(), weatherForecastLoader) | |
| } |
Please, take an important note: WeatherForecastLoaderCallbacks is an inner class of our Activity; LoaderManager stores the reference to this callbacks instance meaning storing the reference to the Activity itself.
Plenty of code, right? But we gain an important advantage here. First of all the instance of the Loader gets reused during screen rotation (or other configuration changes).
Once you rotate the screen the onLoadFinished will be called with the cached result.
Another advantage we got is that we don’t have a memory leak due to saving Activity instance still being able to update the UI.
Cool, the AsyncTasks didn’t have either of that features!
Let’s figure out how that works.
The fun part begins here. My thought was LoaderManager gets stored somewhere inside Application but the actual implementation appeared to be much more interesting.
LoaderManager is created when the Activity gets instantiated:
| public class Activity { | |
| final FragmentController mFragments = | |
| FragmentController.createController(new HostCallbacks()); | |
| public LoaderManager getLoaderManager() { | |
| return mFragments.getLoaderManager(); | |
| } | |
| } |
FragmentController.createControlleris just a named constructor for FragmentControllerclass. FragmentControllerdelegates the loader manager creation to HostCallbacks(which is an inner class of our Activity) which implementation is the following:
| LoaderManagerImpl getLoaderManagerImpl() { | |
| if (mLoaderManager != null) { | |
| return mLoaderManager; | |
| } | |
| mCheckedForLoaderManager = true; | |
| mLoaderManager = getLoaderManager("(root)", mLoadersStarted, true /*create*/); | |
| return mLoaderManager; | |
| } |
As you see the LoaderManager for Activity itself is lazy-initialized; the LoaderManager is not instantiated until it is requested for the first time. Activity’s loader manager has a ‘(root)’ tag as a key in the LoadersManagers map. Access to that map is implemented like this:
| LoaderManagerImpl getLoaderManager(String who, boolean started, boolean create) { | |
| if (mAllLoaderManagers == null) { | |
| mAllLoaderManagers = new ArrayMap<String, LoaderManager>(); | |
| } | |
| LoaderManagerImpl lm = (LoaderManagerImpl) mAllLoaderManagers.get(who); | |
| if (lm == null && create) { | |
| lm = new LoaderManagerImpl(who, this, started); | |
| mAllLoaderManagers.put(who, lm); | |
| } else if (started && lm != null && !lm.mStarted){ | |
| lm.doStart(); | |
| } | |
| return lm; | |
| } |
However, this is not the final initialization of loader manager which happens. Let’s take a look into Activity#onCreate method:
| @MainThread | |
| @CallSuper | |
| protected void onCreate(@Nullable Bundle savedInstanceState) { | |
| ... | |
| if (mLastNonConfigurationInstances != null) { | |
| mFragments.restoreLoaderNonConfig( | |
| mLastNonConfigurationInstances.loaders); | |
| } | |
| ... | |
| } |
restoreLoaderNonConfig ends up with just updating the host controller, which now is a property of our new Activity, created after configuration change.
Once you call initLoader() method the loaderManager already has the info about all the loaders which were created in the destroyed activity. So it has an ability to publish the loaded result immediately:
| public abstract class LoaderManager { | |
| public <D> Loader<D> initLoader(int id, Bundle args, | |
| LoaderManager.LoaderCallbacks<D> callback) { | |
| ... | |
| LoaderInfo info = mLoaders.get(id); | |
| ... | |
| if (info == null) { | |
| info = createAndInstallLoader(id, args, | |
| (LoaderManager.LoaderCallbacks<Object>)callback); | |
| } else { | |
| // override old callbacks reference here to new one | |
| info.mCallbacks = | |
| (LoaderManager.LoaderCallbacks<Object>) callback; | |
| } | |
| if (info.mHaveData && mStarted) { | |
| // deliver the result we already have | |
| info.callOnLoadFinished(info.mLoader, info.mData); | |
| } | |
| return (Loader<D>)info.mLoader; | |
| } |
Great that we figured out two things at once: how we avoid memory leaks(by replacing the LoaderCallbackinstance) and how we deliver result into a new Activity!
The question you possible have is what the hell is mLastNonConfigurationInstances. This is an instance of a NonConfigurationInstancesclass, defined inside the Activity class:
| public class Activity { | |
| static final class NonConfigurationInstances { | |
| Object activity; | |
| HashMap<String, Object> children; | |
| FragmentManagerNonConfig fragments; | |
| ArrayMap<String, LoaderManager> loaders; | |
| VoiceInteractor voiceInteractor; | |
| } | |
| NonConfigurationInstances mLastNonConfigurationInstances; | |
| } |
This object is created with retainNonConfigurationInstance() method and then accessed by the Android OS directly. And it begins to be available to the Activitywithin Activity#attach()method(which is an Activityinternal API as well):
| final void attach(Context context, ActivityThread aThread, | |
| Instrumentation instr, IBinder token, int ident, | |
| Application application, Intent intent, ActivityInfo info, | |
| CharSequence title, Activity parent, String id, | |
| NonConfigurationInstances lastNonConfigurationInstances, | |
| Configuration config, String referrer, IVoiceInteractor voiceInteractor, | |
| Window window, ActivityConfigCallback activityConfigCallback) { | |
| attachBaseContext(context); | |
| ... | |
| mLastNonConfigurationInstances = lastNonConfigurationInstances; | |
| ... | |
| } |
So unfortunately, the main magic stays inside the Android OS itself. But it doesn’t block us from learning!
Retaining and restoring the objects during configuration change is still the magic of Android OS itself
Let’s summarize a little bit what we just discovered.
- Loaders have not obvious api, but allow to save the loading result across the configuration change
- Loaders don’t introduce memory leaks: just remember not to make them Activity’s inner classes
- Loaders offer a possibility to perform background work reusing AsyncTasks but you are free to implement your own Loader
- LoaderManager gets reused between destoyed and newly created activity through saving the actual instances in a special object.
See you in the next part about EventBus!