Merged refreshAllPreferences into DashboardFragment. This hopefully
makes it more modular to manage preference display logic in each
dashboardFragment, and makes it more efficient to monitor category
changes.
Now subclasses needs to implement 2 methods:
- displayResourceTiles(): for 'static' preferences from xml
- getDashboardTiles(): returns a list of dashboard tiles and superclass
will wire it up to preference screen.
If getDashboardTiles() return null (aka no dashboardCategory available),
the fragment will not attempt to monitor category change. The edge case
is that if a package starts to provide a tile for this category, we will
not be notified. I have not seen this case coming up. If we indeed need
to handle this case, the category listener needs to have a way to
monitor specific category rather than globally.
Bug: 31781480
Test: make RunSettingsRoboTests -j40
Change-Id: Ia9f9541b95816214df0d0bb27e3e41078c36c5ca
In order to move the preference and its logic cleanly, created a
controller object that encapsulates the preference/click handler.
Bug: 31801428
Test: RunSettingsRoboTests
Change-Id: I332384e20fbf0e21d2f3becb531d97b20f7f7ef1
- Use activity-alias to define which activity shows up in what category.
We choose activity-alias because it creates a reference to UI we need
without having to define a new set of intent-filter and/or category
keys. This reduces maintainence in the long run. We should merge
metadata from activity-alias into targetActivity when cleaning up.
- Created new System dashboard activity that hosts all system category
tiles dynamically, and a static tile for checking system update.
Bug: 31781480
Test: manual
Test: make RunSettingsRoboTests -j40
Change-Id: Ia2d762e3e1aebd17423a395c5e6c286dc3326492
