This class is currently used by both search and slice, in the future
will be used by DashboardFragment to build controller list. So the scope
of this class is beyond search now.
Test: rerun robotests
Change-Id: If43ebca065aac31ad24f95a94bfe5be784109605
Adds a new abstraction layer between preference controllers
and the AbstractPreferenceController. The layer is used to
consolidate the logic for each the setting type for getting
and setting values. This will be extended to support UI
information for Slices.
For reference how this fits into Slices, look at the
like-named classes added in this prototype:
ag/3221891
The changes in Search are as a transition into deprecation.
The code for Search in Settings is out-of-date from the
unbundled counterpart, and this change is made so that the
current code behaves as normal.
Test: robotests
Bug: 67996707
Change-Id: Ib1faab706485039edad66119a27a3fd5cabe6009
Pre-patch, settings search provider would push all of its
fragments into to search via SearchIndexableResources with
an implicit contract of if the resource's xml == 0, then
it was a settings fragment with an Index provider.
One, implicit contract is bad. Two, it was messy at indexing time.
So this patch moves htat conversion into the search index provider.
Such that all of the indexables are either real Resources or Raw.
Change-Id: I39f4351c03d123bb9b45edb4df7f924cfaff2b38
Fixes: 65376542
Fixes: 37741509
Test: robotests
Remove the the indexing check for the
index data's locale to match the locale of
the device. We don't require locale for
indexables, and we reindex on locale change.
It had introduced a bug where when locale
changed, the default us-en results would
not be added to the db.
Change-Id: I43a4284f5c23bc51ee3efdfcabe511eac2d3317d
Fixes: 66916397
Fixes: 68380443
Test: robotests
Security Settings was returning a search indexable
resource without an xml resource (in this case id = 0).
Settings search did not handle this exception and crashed.
This patch catches the exception, and adds a TODO to fix
the indexing in security settings.
Change-Id: Ic7f05c98d99cc45fbebbdc672c7e346c27daa0f0
Fixes: 67967367
Test: robotests
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
For the sake of incremental updates, we moved all of the
conversion from PreIndexData to IndexData, and the
insertion of the rows into the SQLite DB into a new class,
IndexDataConverter. However, it's real role is just to
convert PreIndexData into IndexData.
So this CL moves the insertion of the rows back into
DatabaseIndexingManager.
Again, for the sake of simplicity, I did not change the
conversion flow. Rather, instead of inserting a row at the
end of the conversion, I just put it into a list which is
then returned. This lets me move the tests to appropriate
locations, without having to change them too much.
In the tests, the references to real xml layouts are
changed to fake references. Hooray for being less brittle.
IndexDataConverter now just tests that the IndexData
has the appropriate data from PreIndexdData.
Independently, we test that IndexData gets inserted in
DatabaseIndexingManager.
In the next CL, I'll refactor the conversion
flow for readability.
Bug: 33577327
Test: make RunSettingsRoboTests
Test: Took a database dump before and after change,
and they were the same. Cool.
Change-Id: I39cc812d1f736e13a0a51af50984c239961ecf7a
This is a small refactor in the large game of refactoring
DatabeseIndexingManager, and the general indexing pipeline
for Settings search.
This change is centered around hiding the normalization of
data (title, summary, keywords) from the data collector,
and putting that responsibility into the IndexData object.
In a future CL, we may move this again to the controller
that actually indexes the data.
Note, the conversion from PreIndexData to IndexData is
still messy, but until I can write a CL that just
rearranges the code, we must stay patient and vigilant.
Bug: 33577327
Test: make RunSettingsRoboTests
Change-Id: I53543d3d9c74a61380601297c55b6e4fea13031a
Step 2 in refactoring DatabaseIndexingManager.
This step moves the insertion of data into the database
into a new class. This removes the remaining bulk of the
code outside of DIM, but it does not fix the actual issue
with the indexing code.
The indexing code still chains functions together to
insert data into the database at the end of the functions.
It is exceedingly hard to read, and hard to track down bugs.
I would like the converter to eventually return a list of
IndexData objects, which lets us dissociate the database
from the data collection. I.e. we can store the database
in the Search app, and just pass IndexData objects via
IPC.Fixing this requires more of a refactor, and will be
done in a subsquent CL.
Bug: 33577327
Test: make RunSettingsRoboTests
Test: Took a database dump before and after change,
and they were the same. Cool.
Change-Id: Ia9bb815657b76f6cb9163014e746ec5eb6db8c5e
