No way to create custom enum TypeAdapters
artyommironov opened this issue · 4 comments
Because you can't access type from adaptFromPreferences(String value). For example, I want my prefenence return null if I renamed enum field. Now it will produce java.lang.IllegalArgumentException: No enum constant for...
or I may want to choose first enum field as default value for all enums etc.
For the IllegalArgumentException I can workaround this and make it return null instead, although this doesn't seem ideal. The correct solution here would be to allow for versioning (in a similar fashion to how the SQLiteOpenHelper does it) and letting the client implementation decide how to handle this change, whether to clear the value or update it.
However if it's the default value that you're concerned about ('default' in this case meaning when it is absent, not when there is a value in the preferences which no longer matches against a changed enum declaration), then I would suggest using a getter with a default (or perhaps me adding an annotation for this, to go along with @DefaultValue). This solution would remove the need for supplying a custom type adapter for a type which is already supported, as I'm not particularly sure of the benefits.
I mostly concerned about changes in code that can crash app after updating its version, such as changing preference type (for example from Integer to String) without changing the key or renaming enum values. I would try catch all such errors by default and return null, but maybe better solution to pass something like ErrorHandlingStrategy to StoreBox build method. Versioning for preference look like overkill, they meant to be simpler than sqlite db.
Let's say that you weren't using StoreBox and you changed the type of a stored preference (ie using your integer to string example) or changed an enum, how would you handle this? Would you put try-catch blocks when getting these values? Would you clear these values when starting up the updated version of the app for the first time?
Preferences are meant to be simpler, but if you've changed the schema of how the values are stored then that needs to be accounted for. Detecting when this has happened and provide some kind of sensible strategy on this (ie sending out nulls/0/0f/0d/etc could hardly be considered 'safe') would be difficult, and could potentially mask other issues -- not something I'd like to see.
After having left this ticket stale for a while, I have decided to remove the preference version handling support for now. I will considering adding it back in if it will look like there might be more demand for it.
For now people will just have to be careful about changing the schema of their stored preferences, which is something that they would have needed to do without using this library as well.