You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Adding support for custom attributes would make it easier for users to coerce the resulting classes just the way they want, while extending functionality by being able to specify non-standard types.
Initial ideas:
valueType - Specify a custom type to cast the value to.
Useful for things like String -> CharSequence.
EditTextPreference is considered a String by shared prefs but can be a numerical value. Current behavior reads it as an int (Rewrite in Kotlin #5)
This would also be useful for specifying non-xml-friendly types that SharedPreferences supports, such as StringSet or Long.
entryName - Custom name for the entry in xml. Would take precedence over generating one from the key.
From @hzsweers on September 1, 2015 22:0
Adding support for custom attributes would make it easier for users to coerce the resulting classes just the way they want, while extending functionality by being able to specify non-standard types.
Initial ideas:
valueType
- Specify a custom type to cast the value to.String
->CharSequence
.EditTextPreference
is considered a String by shared prefs but can be a numerical value. Current behavior reads it as an int (Rewrite in Kotlin #5)SharedPreferences
supports, such asStringSet
orLong
.entryName
- Custom name for the entry in xml. Would take precedence over generating one from the key.skip
- Don't generate a block for this preferenceCopied from original issue: Flipboard#2
The text was updated successfully, but these errors were encountered: