Settings now collects search results from a single
loader which fetches from an aggregator. This is to
facilitate the separation of search functionalitiy,
where "query" becomes a single synchronous call.
In this case, the aggregator will move to the
unbundled app and would be called on the
other end of the Query call. i.e. the new search
result loader will just call query, and unbundled
search will handle everything else.
An important implication is that the results will
be returned in a ranked order. Thus the ranking and
merging logic has been moved out of the RecyclerView
adapter (which is a good clean-up, anyway).
The SearchResultAggregator starts a Future for each
of the data sources:
- Static Results
- Installed Apps
- Input Devices
- Accessibility Services
We allow up to 500ms to collect the static results,
and then an additional 150ms for each subsequent
loader. In my quick tests, the static results take
about 20-30ms to load. The longest loader is installed
apps which takes roughly 50-60ms seconds (note that
this will be improved with dynamic result caching).
To handle the ranking in DatabaseResultLoader,
we start a Future to collect the dynamic ranking before
we start the SQL queries. When the SQL is done, we
wait the same timeout as before. Then we merge the
results, as before.
For now we have not changed how the Dynamic results
are collected, but eventually they will be a cache
of dynamic results.
Bug: 33577327
Bug: 67360547
Test: robotests
Change-Id: I91fb03f9fd059672a970f48bea21c8d655007fa3
This is entirely implementation detail, the public
interface and tests get to stay the same.
- The Raw, Resource and Provider methods now return single
or lists of IndexData rather than adding to a member var.
- Some code duplication was removed for Raw IndexData.
- Extra methods were squashed or removed
The only remaining refactoring in IndexDataConverter is
moving work done on IndexProviders to get the raw and
resources into PreIndexDataCollector.
Bug: 33577327
Test: make RunSettingsRoboTests, Database dump before & after
Change-Id: If6011046955f242ba2614400cfeca3bea5b683cb
The first step in refactoring the god class,
DatabaseIndexingManager.
The class has one major entry point: indexDatabase
which begins a chain of calls that first collects all the
data from the fragments, and then massages that data into
the SQLite database. Unfortunately, most of the methods
do not return data, and just pass along some mutated
form of the data until it can be insterted.
Reading and testing this class is very difficult.
This first step moves the collection of the indexable data
into a new class which has a few benefits:
- The data can be easily mocked in tests
- Reduces complexity of D.I.M.
- Separates data collection from indexing, which allows the
indexable data to be piped into a new API that unbundled
search can consume.
Bug:33577327
Test: make RunSettingsRoboTests
Test: Grabbed a DB dump before change, compared to DB dump after change
to make sure everything is still indexed.
Change-Id: Ibc91e3d75ff5dcf5274b93b29bf3544f90b2194d
This will avoid unnecessary static ranking if smart ranking is used.
Since loader does not need to provided sorted collection of results,
the loading data type has changed from List<> to Set<>. This will also
faster lookup in the Adapter.
Fixes: 38447799
Test: make RunSettingsRoboTests
Change-Id: I448b29bd4e8700c8ec4b5766cbeab4b3087ae39a
- SearchResult stableIds are now DocIds from the database
- DocIds are data reference key's hash, when the key is not
empty or null
- Otherwise, DocIds are a hashcode from a set of fields.
Change-Id: Id36f7bf4ceaaa3a2bd326ecafbfe97fd0b247df2
Fixes: 37327194
Test: make RunSettingsRoboTest
