Preferred method of loading dependent queries with LoaderManager

Question

What is the preferred method of loading dependant queries with the LoaderManager API in Android? As of now the best I could come up with is something along the lines of:

@Override
public void onCreate( Bundle savedInstanceState ) {
    getLoaderManager().initLoader( FIRST, null, this );
}

@Override
public void onLoadFinished( Loader<Cursor> loader, Cursor data ) {
    switch ( loader.getId() ) {
    case FIRST:
        Bundle args = new Bundle();
        args.putInt( ID, somethingFromData( data ) );
        getLoaderManager().restartLoader( SECOND, args, this );
        break;

    case SECOND:
        somethingElseFromData( data );
        break;
    }
}

This works fine most of the time, but it crashes horribly under one special case. Say I launch a second activity or push a fragment on top of this that modifies the data of FIRST. Now when I navigate back to the activity/fragment with the code above it first refreshes me with the old data of FIRST and SECOND, and since FIRST initiates SECOND, SECOND is reloaded with the new data. Now since FIRST is changed it is loaded again, which causes yet another load of SECOND to initiate.

First of all if you count that that sums up to two loads of FIRST (one old and one new) and three loads of SECOND (two old and one new), which seams at least a bit wasteful. I don't really mind that, except it is a hassle to debug, but it also seems to me to behave non-deterministically, because you don't know which loads will finish first. Will I end up with the new data for SECOND if the relation between FIRST and SECOND changed, or will I end up with the cached values?

I know that I can mitigate this by keeping score of when to restart the second loader, but there has to be a better way of doing this.

To clarify a bit: The problem is most prominent if rows in FIRST contains a reference to rows in SECOND and after the back navigation the row(s) in FIRST loaded does not point to the same row(s) in SECOND as before.

Answer 1

Given that the only thing your first loader does is effectively prepare arguments for your second loader, you should subclass your own AsyncTaskLoader and do the whole operation within one loader.

This article contains a very in-depth example of a custom AsyncTaskLoader, which I'm sure you could adapt to your own needs. You also should look at the CursorLoader source code for a better grasp of how to write your own.