In this presentation, I'm talking about a powerful tool for asynchronous loading which is provided by Android framework - loaders. Why guys from Android team added this tool and how we can customise it? We'll try to find answers for these questions.

1. and why should we use them?
Loaders

2. Problem
we want to create smooth GUI (without any lag)

3. Solution
make all “big” tasks in the background

4. Basic case

5. Tools
Java built-in multithreading tools

6. Disadvantages
● low level tools - relatively inconvenient
○ boilerplate code increases risk of mistake
● are not adopted for Android envinronment
○ performance issuer (if we don’t use thread pool)
○ know nothing about Android components lifecycle

7. Partial solution - AsyncTask
● Dramatically simplifies interthread
communication
● Uses thread pool (performance++)

8. Activities are dying
SUDDENLY!!!

9. Problem
background processes have to still alive during
activity recreation and delivery result into the
new activity

11. Solution
use components which can survive during
activity recreation

12. Available tools
● service (Robospice)
● RxJava + fragments
● loaders
● any combinations of previous 3

13. actually
AsyncTasks are
still popular ;)

14. Usually it happens
after relatively
long time after
activity stop +
network requests
aren’t such long

16. Services
+ unlikely that a system will kill an app
+ a lot of libraries
- it’s not so easy to communicate with a service
- libraries are not supported by Google

17. RxJava
+ event-oriented model
-+another programming paradigm
- a lot of boilerplate (without Retrolambda)

18. Who is loader?
Someone who can:
● load data
● store date inside itself
● listen for data updates and deliver new data
● work with activity life cycle events

19. Loader states
● started - loader loads/stores data and listens for
updates
● stopped - loader listens for updates, but doesn’t notify
about them
● reset - loader doesn’t store date, doesn’t listen for
updates

21. LoaderManager
● is bound to an activity/fragment and survives
configuration change
● stores refs to loades
● supports loaders life cycle

22. LoaderManager methods
○ initLoader() - creates and starts loader. If loader
stores data - returns it immediately
○ restartLoader() - creates or recreates loader.
Forces data loading.
○ destroyLoader() - destroys a loader.

23. LoaderCallbacks
Communication between View and LoaderManager
public class SampleActivity extends Activity implements
LoaderManager.LoaderCallbacks <D> {
public Loader<D> onCreateLoader(int id, Bundle args) {
// a loader fabric method
}
public void onLoadFinished(Loader<D> loader, D data) {
// a result processing
}
public void onLoaderReset(Loader<D> loader) {
// cleanup code
}
}

25. Before API level 11 activity had such methods:
● public void startManagingCursor(Cursor)
● public void stopManagingCursor(Cursor)
● public Cursor managedQuery(Uri, String, String, String,
String)
Why did everything start with cursors?
They are here
even now, but
deprecated

26. But something was wrong...
+ activity controls cursor by itself
- a cursor was recreated on an activity
recreation
- everything in UI thread

27. getLoaderManager().initLoader(LOADER_ID, null,
new LoaderManager.LoaderCallbacks<Cursor>() {
@Override
public Loader<Cursor> onCreateLoader(int i, Bundle bundle) {
return new CursorLoader(getActivity(), "content://com.foo.bar/dog", null,
null, null, null);
}
@Override
public void onLoadFinished(Loader<Cursor> cursorLoader, Cursor cursor) {
if (cursor != null && cursor.moveToFirst())
someView.setText(cursor.getString(0));
}
@Override
public void onLoaderReset(Loader<Cursor> cursorLoader) {
// in case of cursor adapter, it’s a good place to a swap cursor
}
});
CursorLoader solves all problems

28. Custom Loader
● it’s recommended to use AsyncTaskLoader as a
base class
● you have to reload:
○ loadInBackground()
○ onStartLoading()
○ onStopLoading()
○ onReset()
○ onCanceled()
○ deliverResult(D results)

30. ● loadInBackground()
○ Background operation. It loads data.
● onStartLoading()
○ here we should check if we have loaded data already or
we have to load it. If we already have data - return
it immediately
○ start data change listener
● onStopLoading()
○ stop notify about new data, but be prepared to start
again

31. ● onReset()
○ stop loading
○ stop listening for data changes
● onCanceled()
○ try to cancel current loading
○ erase already loaded data
● deliverResult(D results)
○ if loader is in “reset” state - free resources
○ else loader has to return new data and free resources
of “old” data

33. Demo time ;)

34. Loaders
+ are OK with activity recreation
+ are well documented
+ are “official” tool (supported by Google)
- an application can be killed by a system
- a life cycle is not simple

35. Summary
● we should use loaders
● for simple network communication loaders are a
good solution
● you can use loaders as a facade for another async
loading tool

36. ● Blog posts series about Loaders (by Alex
Lockwood)
● Android networking without pain (presentation)
● Modern techniques for implementing REST clients
on Android 4.0 and below
● CWAC-LoaderEx and Failed Abstractions
● Android tutorial to learn through small projects
(on Chinese)
● Example on GitHub
Sources
It’s clickable link

37. Thank you!
Michael Pustovit
Stanfy
https://google.com/+ПустовитМихаил