-
-
Notifications
You must be signed in to change notification settings - Fork 1.9k
Replace BaseActivity.sharedPreferences with app preferences #4797
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Replace BaseActivity.sharedPreferences with app preferences #4797
Conversation
9de6bc1 to
dc32b64
Compare
dc32b64 to
6a5928c
Compare
6a5928c to
fa4f166
Compare
Codecov Report
@@ Coverage Diff @@
## master #4797 +/- ##
===========================================
+ Coverage 17.48% 17.58% +0.1%
Complexity 3 3
===========================================
Files 376 377 +1
Lines 32385 32413 +28
Branches 4569 4573 +4
===========================================
+ Hits 5661 5699 +38
+ Misses 25813 25798 -15
- Partials 911 916 +5
|
|
In general it looks good while there are now two keys for the theme which should imho be just one. |
fa4f166 to
3961fd6
Compare
|
IT test failed: https://www.kaminsky.me/nc-dev/android-integrationTests/11535 |
Yeah, I just checked the settings XML and it looks like Android is putting the UI key into the store, The rationale behind this experiment is that conceptually we have 1 key somewhere behind
Currently keys must be maintained in sync in 3 distinct places:
BTW, those sets are not 100% overlapping. Now, you could argue that we can just move those keys to and we just got rid of it recently. Those will slip through code reviews even if we stay alert. Enough ranting. 🙃 Having said that, I'm reverting my experiment as I have no good and quick workaround for antipattern of the native Android API and the solution we have right now seems work well enough. Not great - not terrible. |
3961fd6 to
f8e1de0
Compare
- Eliminate access to shared preferences when setting dark theme. - Extend AppPreferences interface to allow subscription for preference changes - Improve preferences interface documentation Fixes #4791 Signed-off-by: Chris Narkiewicz <hello@ezaquarii.com>
f8e1de0 to
6b01382
Compare
|
APK file: https://www.kaminsky.me/nc-dev/android-artifacts/11544.apk |
Codacy304Lint
SpotBugs (new)
SpotBugs (master)
|
| private static final String PREF__FOLDER_SORT_ORDER = "folder_sort_order"; | ||
| private static final String PREF__FOLDER_LAYOUT = "folder_layout"; | ||
| public static final String PREF__THEME = "darkTheme"; | ||
| static final String PREF__DARK_THEME_ENABLED = "dark_theme_enabled"; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Will likely chance when @tobiasKaminsky pushes his PR to the repo adding a 3rd option for the theme values (dark, light, system)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This will be interesting. I wild guess that the change will be based on the SharedPreferences code that I just removed and the preference will become some kind of enum instead of boolean?
I'm fine with resolving conflicts on my side, let's just make sure we don't have to do a complete rewrite. (-:
Is there any public branch I could potentially try?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there any public branch I could potentially try?
Don't know, I just saw this earlier this evening, which is why I mentioned @tobiasKaminsky here --> #4757 (comment)
|
Fine with me. Just one minor comment that this PR and a soon to be openend PR by @tobiasKaminsky will have conflicts while both PRs will change the type of the preference and thus (fine since master is in alpha state for v3.10) both PRs will break the activated dark theme (since the key changed twice then) |
|
We merge this one, and then I change it within my upcoming PR. |

AppPreferencesinterface to allow subscription for preference changes@AndyScherzinger @tobiasKaminsky @dan0xii
This is my initial proposal to deal with
AppPreferencesinterface bypass.I tried to address access to
AppPreferencesImplbut it looks like we still havemany points where we do cross-cutting calls to private implementation for various
reasons (dodgy workarounds, circular dependencies, etc). Despite my tries, I conclude
that closing
AppPreferencesImplis a bit too much work for a single change and I exhaustedmy bandwidth for today.
This PR will address only theme related concerns. I'll follow up with improvements around
*Implaccess as my time allows.Fixes #4791
Signed-off-by: Chris Narkiewicz hello@ezaquarii.com