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 announced that he will discontinue any work on his library : Loaderex. Commonsguy also said "Loaders are a failed abstraction."
I'm obviously missing something here and I would like to learn more and understand why are Loaders bad and why should one avoid them.
Note: I have created an Android application (perhaps of middle complexity) where I use Loaders and haven't had any troubles with Loaders. That's why it's puzzling me.
I would also like to know about other better alternatives to Loaders. Thanks in advance
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
.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With