Skip to content

Conversation

@BrayanDSO
Copy link
Owner

Purpose / Description

Supersedes ankidroid#12161 and ankidroid#8066

I'm open to opinions about the design. This is significantly simpler than ankidroid#12161 because I feel that it is overengineered, and 95%+ of our shared preferences usage is simply accessing a preference.

Fixes

Approach

In the commits.

The methods and settings are implemented incrementally to ease the reviewing process and to simplify the workflow.

How Has This Been Tested?

Unit tests + Manually checking if the changed settings still work

Learning (optional, can help others)

I haven't used much until now Java/Kotlin mock methods for tests. Probably there are better ways to do what I have done, but it was a nice learning experience.

Also learned more about kotlin reflection

Checklist

Please, go through these checks before submitting the PR.

  • You have a descriptive commit message with a short title (first line, max 50 chars).
  • You have commented your code, particularly in hard-to-understand areas
  • You have performed a self-review of your own code
  • UI changes: include screenshots of all affected screens (in particular showing any new or changed strings)
  • UI Changes: You have tested your change using the Google Accessibility Scanner

This starts the implementation of an internal API for settings.

Some design notes:

1. The settings are going to be POJOs, which are simple to understand, simple to write, and aren't obligated to have a setter
2. Key constants are listed in SettingKey. I'm not using the constants in `constants.xml` because
a. It requires a `Context` dependency
b. Some places of the code need the keys as strings
and implement an example (sync username)
and implement and example (reviewer frame style)
and implement and example (answer button size)

`preferences_accessibility` is being changed because the unit test showed that it was wrongly using `app:defaultValue`
and implement an example (enable dev options)
@BrayanDSO BrayanDSO force-pushed the app-settings branch 7 times, most recently from fa3b0d3 to f910a6a Compare January 15, 2025 14:32
@BrayanDSO BrayanDSO force-pushed the app-settings branch 3 times, most recently from 744afee to 7ed16d5 Compare January 15, 2025 15:53
they guarantee that the getter and the setter use the same key. Also, they reduce the boilerplate of writing a simple setter

more delegates can be added later

also made `username` nullable to make more obvious that the value wasn't set yet
@BrayanDSO BrayanDSO closed this Jan 15, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants