2

I am using a ContentProvider to query a database and return a Cursor that is used in a CursorLoader:

ItemsActivity:

public class ItemsActivity extends SherlockActivity implements LoaderCallbacks<Cursor> {

    @Override
    public void onCreate(Bundle savedInstance) {
        ....
        getSupportLoaderManager().initLoader(LOADER_ID, null, this);
        ...
    }

    @Override
    public Loader<Cursor> onCreateLoader(int loaderId, Bundle bundle) {
        return new CursorLoader(getApplicationContext(), itemsListUri, ...); 
    }

    ...
}

ItemsContentProvider:

public Cursor query(Uri uri, String[] projection, String selection, ...) {
    SqliteQueryBuilder builder = new SqliteQueryBuilder();
    builder.setTables(ItemsTable.NAME);
    return builder.query(db, projection, selection, ...);
}

The activity has a ListView, and I am using a CursorAdapter (updated via the LoaderCallbacks) to represent the data within the cursor.

This is working fine, until I need to lookup the items in a large data set (for example, over 30,000 rows). Observing the logs I see that the lookup exceeds memory limits and some rows are dropped from the resulting cursor.

My question: what is the best way of handling very large datasets when using cursors like this?

My current solution is to break up the SQLite query in the ContentProvider into a sequence of queries with offsets and limits, then combine these queries using the MergeCursor class:

private static final int LIMIT = 5000;

// Ignoring projection, selection, etc for simplicity here
public Cursor query(Uri uri, String projection, String selection, ...) {
  List<Cursor> cursors = newList();
  int offset = 0;
  Cursor c = db.rawQuery("select * from items limit " + LIMIT + " offset " + offset, null);
  while (c.getCount() > 0) {
    cursors.add(c);
    offset += c.getCount();
    c = db.rawQuery("select * from items limit " + LIMIT + " offset " + offset, null);
  }
  return createMergedCursor(cursors);
}

private Cursor createMergedCursors(List<Cursor> cursors) {
    if (cursors.size() == 1) {
        return cursors.get(0);
    }
    return new MergeCursor(toCursorsArray(cursors));
}

This will load all the data, but there's a long delay while doing the lookups for the first time. The list view is empty for about 5 seconds while multiple queries are performed.

Note that when I try a single lookup (rather than batched lookups), the loading is almost instantaneous, although there are slight pauses when scrolling the list as memory limits are reached.

So:

Using a single query: fast list view updating, but scrolling pauses and memory limits reached.

Using batched queries: slow list view updating, but scrolling is smooth and no memory limits reached.

I'm wondering if there's a better solution that will update the list view quickly, but will also fetch more data as required when scrolling the list.

Android 4.2.1, Nexus 7

Mohd Mufiz
  • 2,236
  • 17
  • 28
John Q Citizen
  • 321
  • 1
  • 6
  • 15
  • 1
    Why is it necessary to have 30000 items in a list view? – CL. Dec 05 '12 at 12:53
  • My app displays the contents of a music library: 1100 artists, 3200 albums, 36000 tracks. I've got tabs containing a list view for each, with a search field at the top. The UI works for the artists/albums views, but the tracks view has the issue noted above. – John Q Citizen Dec 05 '12 at 20:15

2 Answers2

5

Mobile devices are not designed to handle these amounts of data.

However, if you really want to inflict such a large scrolling list on your poor users, you can design it as a virtual list where entries are loaded only on demand; see Android Endless List.

Note: Using the OFFSET clause is inefficient; see Scrolling Cursor for details.

Community
  • 1
  • 1
CL.
  • 173,858
  • 17
  • 217
  • 259
  • Thanks for the tip on EndlessAdapter. It may be close to what I am seeking. At first glance it seems to require an explicit 'load more' action. I'm looking for an adapter that will automatically load the next batch of results as the list is scrolled. More investigation required ... – John Q Citizen Dec 08 '12 at 03:10
  • The Tapatalk app (for reading various discussion forums) is an example of what I'd like to implement: when scrolling the list of conversations it will automatically load more conversations as required. There's a spinner icon at the bottom to show this is happening. – John Q Citizen Dec 10 '12 at 11:58
2

I agree with CL that you shouldn't do this. This isn't a good idea on mobile and neither is it on desktops. Who wants to scroll 30000 elements? What for? Most probably the user is looking for one result only, isn't she? So provide an easy way to filter the result set.

Until the result set is small enough to be actually usable (this is not the same as the list scrolling fine - it's probably a much smaller number of results) you simply should display the total number of hits for the current query and maybe some elements as a sample to the user. The user must filter the list to get to actually usable sizes.

Wolfram Rittmeyer
  • 2,402
  • 1
  • 18
  • 21
  • Thanks for the comment. I've struggled with the UI a bit here: the approach taken is to show all the results then allow the user to filter down to what they want. Showing all the results also allows the user to peruse the list and discover what is there, rather than assuming the user always knows exactly what they want to see. – John Q Citizen Dec 08 '12 at 03:06
  • Well they won't find out when scrolling 30.000 list entries. But yes, sometimes they don't know for sure about what they're after. That's why I suggested to show some samples (a limit xyz query). You should state right away: 30.000 records found. Only the top x results are shown. So they know *themself* that they won't find what they are looking for without filtering. – Wolfram Rittmeyer Dec 08 '12 at 14:33