Why are Loaders bad in Android

Question

I have read a couple of tweets and comments here and there about Loaders being bad and using them is a good way to \"shoot yourself in the face\". Also commonsguy

Answer 1

why are Loaders bad and why should one avoid them

You will note that this is not what I said. I said that loaders are a failed abstraction. There's a difference.

A general recommendation, when trying to create a framework for significant reuse, is to design and create three discrete implementations of the framework. If your framework can support three different approaches, the design is probably flexible enough to handle future implementations.

The Loader framework, at the end of the day, is designed around one implementation: CursorLoader. Period. There are no other concrete implementations of Loader in the SDK. In particular, the Loader framework has a contract that requires that implementations of Loader be able to deliver updated results automatically. While this is a lovely contract from the standpoint of users of the Loader framework, it makes things difficult for those who might create implementations of the Loader framework.

I attempted to create two separate implementations of the Loader framework, for SQLite and SharedPreferences (three if you count SQLCipher for Android separately). The SQLite one sucks, because the only way to do the automatic-reload stuff is for the Loader to know what needs to be reloaded, which is clunky. The SharedPreferences one used to work, but it was pointed out that nowadays onLoadFinished() will not be called if the object representing the results (the Cursor for a CursorLoader, SharedPreferences for SharedPreferencesLoader) is the same object as before. That breaks SharedPreferencesLoader, since the SharedPreferences object is updated in situ when preferences are changed.

After writing my Loader implementations and using them for a bit, I concluded that they weren't worth it. I'd rather load stuff myself asynchronously using AsyncTask or IntentService and use a message bus (Otto, greenrobot's EventBus, etc.) for notifying interested parties about changes in data. While I could wrap that stuff inside of Loader, I am unconvinced that it would solve enough problems to be worth the effort.

Now, if you are using a ContentProvider and wish to use CursorLoader, that's fine. It may have its own issues, but at least it's supposed to work.

With respect to the CWAC-LoaderEx library, I am discontinuing it because:

• I only have so many hours in the day, and so as part of the great AAR-ification of the CWAC libraries, I am deciding which libraries are worth the effort to maintain

• I do not use CWAC-LoaderEx personally, outside of a couple of book examples

• CWAC-LoaderEx is dependent upon too much internal implementation of Loader for me to be comfortable that I will be able to keep it working over the long haul (see SharedPreferencesLoader)

CWAC-LoaderEx isn't going anywhere, but I just will not be putting more time into it. If somebody with a maintained/extended fork contacts me, I'll be happy to link to their fork from the project README.

I would also like to know about other better alternatives to Loaders

All a Loader does is asynchronously load content, re-load that content upon a detected change in the content, and retain said content across a configuration change. A retained model (or headless) fragment can do the same thing, in concert with an AsyncTask.