Skip to content
This repository has been archived by the owner on Dec 12, 2020. It is now read-only.

"keys" should be moved from strings.xml to keys.xml #278

Closed
eisbehr opened this issue Jul 19, 2012 · 1 comment · Fixed by #390
Closed

"keys" should be moved from strings.xml to keys.xml #278

eisbehr opened this issue Jul 19, 2012 · 1 comment · Fixed by #390

Comments

@eisbehr
Copy link
Contributor

eisbehr commented Jul 19, 2012

The keys (e.g. TODOTXTPATH_key) are used for storing and accessing shared preferences. Currently they are located in the strings.xml which contains the strings that are meant to be localized. As changing the keys during localization (for whatever reason) would potentially break the app (if the user changes the phone's locale), the keys shouldn't be mixed together with other strings.

I also noticed that some of the keys are used as hardcoded strings at some occasions throughout the code. When moving them to the new xml this should also be fixed.

There are also some of the shared preferences keys stored in Constants.java (The ones not used in the preference activity) that should probably be moved to the keys.xml as well
chuckbjones added a commit to chuckbjones/todo.txt-touch that referenced this issue Jan 8, 2013
@chuckbjones
Keys should be DRY
f0f568e 
Partially fixes todotxt#278

Move sharedPreferences keys from strings.xml to keys.xml.
Remove keys from Constants.java.
Implement Keys.java to read keys from the xml file.
Use methods in Keys.java instead of hard coding the key strings
or duplicating them in Constants.java.

This is not an ideal solution, as we need a Context to look up the
key values in the resource file. A Context is not always available,
and makes the code ugly.

Will refactor into a better solution before submitting pull request.
@chuckbjones
Copy link
Contributor

Started working on this (see chuckbjones/todo.txt-touch@f0f568e). The only issue with putting the keys in a resource file is that we need a context in order to retrieve them (assuming we don't want to duplicate the strings in, e.g, in Constants.java). Will have to refactor the code a bit to remedy this, probably by subclassing SharedPreferences and creating dedicated methods for getting and setting the various values.

@chuckbjones chuckbjones mentioned this issue Jul 7, 2013
Merged
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Refactored all sharedPreferences access into its own class. chuckbjones/todo.txt-touch
2 participants
@eisbehr @chuckbjones