When to use Android Loaders

Question

Loaders

1. monitor data source and deliver new results
2. After a configuration change : no need to re-query the data

I read the android guide about Loaders. I read Alex Lockwood 4 parts tutorial . Tested his sample app too. Tried to read the Google App for I/O 13, there's a Stream feature and reading its code find out it uses Loaders since it provides code to create a StreamLoader. Here is the Link I suppose they use it to monitor for new data and add them to their view.

Same for Alex's app. There's an observer and when there is new data entries triggers a refresh for the UI.

So far it seems to me, Loaders are ideal choice for a "livescore" app. When there's a new update ( which means a new data entry ) it appears on your screen.

Maybe something like Twitter. New messages for you, custom Observer to notice for changes, custom Loader brings the data and an adapter to display them. No need to "pull-to-refresh". But then again Twitter has its own RESTful API which kinda does the same job. No need for a pointer to the new data. ( don't know how they do it but I guess somehow the "push" new data to your device ).

So my question is :

Loaders are best option when we want to observe a data source and change our view so it will display the new data?

Are there any examples/app I can check dealing with that logic : monitor the data source -> get the data -> refresh UI

Any characteristic cases ( like the one with the "livescore" previously mentioned by me ) that when we have to deal with them we have to choose Loaders?

The second part of the Loaders ( configuration change, keeping the data ) I think its clear. No one want's to re-download an Image gallery when the user rotates the device.

Thank you and excuse my confusion

Anglesite

Answer 1

The best way I can describe a Loader is a Handler that is always on. Both Loaders and Handlers pass data between objects.

I agree with what you said about the "livescore" app. The Loader monitors the source of their data and delivers new results when the content changes.

To answer your questions:

1) Loaders are best option when we want to observe a data source and change our view so it will display the new data?

A: Yes. if your data source is constantly updating. For example, like a stock-ticker app. If your data isn't constantly updating, then no, don't use a loader. For example, if your data source is only retrieved once, then there's no need for a Loader.

2) Are there any examples/app I can check dealing with that logic : monitor the data source -> get the data -> refresh UI

A: https://www.youtube.com/watch?v=3d9BeWqlfTk

Intensive

Answer 2

Yes, they are what you want to use for the flow you're describing. Tangentially, there's also AsyncTasks and Services that have similarities.

AsyncTasks

Description (from docs):

AsyncTask is designed to be a helper class around Thread and Handler and does not constitute a generic threading framework. AsyncTasks should ideally be used for short operations (a few seconds at the most.)

Caution: Another problem you might encounter when using a worker thread is unexpected restarts in your activity due to a runtime configuration change (such as when the user changes the screen orientation), which may destroy your worker thread. To see how you can persist your task during one of these restarts and how to properly cancel the task when the activity is destroyed, see the source code for the Shelves sample application.

If you specifically just want a wrapper to basic threading boilerplate, use an AsyncTask otherwise I'd suggest you use an AsyncTaskLoader if you need a general purpose way to run intensive operations in an Activity or Fragment. You get the same benefits from AsyncTask, but it handles lifecycle issues for you. There are also specialty loaders, such as CursorLoader that will are made to handle specific data sources and have conveniences for interacting with certain UI elements.

Services

Description (from docs):

A Service is an application component that can perform long-running operations in the background and does not provide a user interface. Another application component can start a service and it will continue to run in the background even if the user switches to another application. Additionally, a component can bind to a service to interact with it and even perform interprocess communication (IPC). For example, a service might handle network transactions, play music, perform file I/O, or interact with a content provider, all from the background.

You would use a service to handle data being pushed to a phone. Otherwise, the user would have to open your app to get any pushed data. Services do not interact with your UI. So a common design pattern is to use a Service to gather data from a server (whether pushed real time or if you poll) and store it in your database for use both when your app is opened or when not. There are many other use cases for Services, but this one is probably the most popular.

Conclusion So no, you aren't required to use a Loader to load data or do long running operations on a background thread and pass the results (or progress) to your UI thread, but they are the best option for most use cases.

Panchito

Can you provide a link to a source? I don't find anything saying AsyncTask is being deprecated. – Phobos