- Renames CloseTabsSettingsFragment.kt to TabsSettingsFragment.kt
- Renames close_tabs_preferences.xml to tabs_preferences.xml
- Adds preference options for the switching between the Grid and List tab views
The difficulty in mocking StrictMode.resetAfter is concerning.
I'm starting to second-guess whether or not making strict mode manager a class
was a good idea.
I believe this was a premature optimization: it's unclear that it would
actually improve performance and yet we had to add several weird
workarounds to make it work that broke encapsulation. It's also
possible it would be worse for the APK size because of excessive
inlining.
set save button state by calling invalidateOptionsMenu, causing onPrepareOptionsMenu to be called which will enable/disable the save button depending on if changes have been made or not
In a followup PR, we need to add state to strictModeManager (the
number of suppressions). This is much simpler to do when this is defined
as a class rather than an object. However, when this is defined as a
class, `resetAfter` needs access to the strictModeManager. Instead of
passing it in as an argument, it made sense to move this function onto
the strictModeManager instead.
Since folks are used to calling:
```
StrictMode.ThreadPolicy.allowThreadDiskReads().resetAfter
```
We're going to have to add a lint check to prevent them from doing that.
I originally tried to create this PR leaving this as an object to keep
the change simple but it wasn't worth it - once the object started to
keep state, we'd need to manually reset the state between runs. Also,
the tests were already getting hacky with static mocking so it was
easier to address some of those issues this way too.
Additional branching introduces complexity so we should avoid it when
possible. This branch was also unused so it's more likely to have bugs
if we tried to use it after some refactor.
This is not the super fancy version yet - since we still need to restore into SessionManager and
haven't fully switched to BrowserStore yet. However AC having knowledge about "undo" and whether
it was performed or not, will help us with features like "recently closed tabs". And once we
can improve "undo", Fenix will get all the nice things automatically.
Requires:
https://github.com/mozilla-mobile/android-components/pull/8449