Paginate scrolling in test result screen

[aanorbel]

Fixes ooni/probe#1430

Proposed Changes

• Introduce Pagging to use Android Pager
• Move away from HeterogeneousRecyclerAdapter
• Depricated classes no longer required

Sample Pager logs

V/FlowLog: Executing query: SELECT * FROM `Result` ORDER BY `start_time` DESC LIMIT 20 OFFSET 0 
V/FlowLog: Executing query: SELECT * FROM `Result` ORDER BY `start_time` DESC LIMIT 20 OFFSET 20 

[hellais]

If while you have fetched the first page of data, another result is written to the results table (because there is a test currently running), fetching the next page will be off by one.

You could instead use the result_id as a pagination handler and query WHERE result_id < $last_result_id to get the next page worth of data.

[aanorbel]

The query mechanism has been updated to use result_id based pagination

[hellais]

Do you actually need the previous key? In which circumstances are you using this?

I don't think you can derive this by just subtracting 20, because some test results may have been removed and so the list of IDs may have "holes" in it.

[bassosimone]

We need the previous key to return it and allow navigation, IIUC the code.

I don't know how the code behaves when there are holes. It may be that, while you are scrolling back, the Android code will continue to query until it has enough elements to fill the screen, so it may be that we don't need to be more precise at the cost of executing more queries.

I think @aanorbel should clarify this.

[aanorbel]

To optimize the load time and memory usage, the records loaded will not always stay in memory, so the previous key is used when the records previously loaded are no longet in memory.

[bassosimone]

Mainly comments related to how querying the database works

[bassosimone]

Suggested change

	Integer nextKey = (!response.isEmpty()) ? Iterables.getLast(response).id : null;
	Integer nextKey = (!response.isEmpty()) ? Iterables.getLast(response).id + 1 : null;

Conceptually, the next page seems to start at index $last + 1 rather than at index $last. That said, I can see how smooth scrolling means that probably we want to keep the last element in scope.

[aanorbel]

The operand used for the query is lessThan so using Iterables.getLast(response).id + 1 will mean we lose a record.

[bassosimone]

We need the previous key to return it and allow navigation, IIUC the code.

I don't know how the code behaves when there are holes. It may be that, while you are scrolling back, the Android code will continue to query until it has enough elements to fill the screen, so it may be that we don't need to be more precise at the cost of executing more queries.

I think @aanorbel should clarify this.

[aanorbel]

The scroll back will need to use the prevKey only when there are no records in memory are don't meet the scroll back parameter since previous records are not kept in memory after a certain threshold is reached.

[aanorbel]

Stale