Change theme
Help
Press space for more information.
Show links for this issue (Shortcut: i, l)
Copy issue ID
Previous Issue (Shortcut: k)
Next Issue (Shortcut: j)
Sign in to use full features.
Vote: I am impacted
Notification menu
Refresh (Shortcut: Shift+r)
Go home (Shortcut: u)
Use Markdown for this comment
Set severity, which reflects how much the issue affects the use of the product
Assign issue to yourself
Pending code changes (auto-populated)
[ID: 84651]
Story points rate the relative effort of work in a Fibonacci-like format: 0, 0.5, 1, 2, 3, 5, 8, 13, 20, 40, 100. Each team will estimate work on a slightly different scale, which means the values in this field are likely only meaningful to the team that owns the Buganizer component in which the issue resides.
See Atlassian's Agile Coach for more information on how to use story points for estimation: https://www.atlassian.com/agile/project-management/estimation [ID: 746686]
Set the version(s) of the product affected by this issue (comma-separated list)
Set the version(s) of the product in which the issue should be fixed (comma-separated list)
Set the version(s) of the product in which the issue fix was verified (comma-separated list)
Set if this issue occurs in production
[ID: 85206]
Set Reporter
Set Type
Set priority, which reflects how soon the issue should be fixed
Set Status
Set Assignee
Set Verifier
Remove item
View or edit staffing
View issue level access limits(Press Alt + Right arrow for more information)
Description
* Set sharedPreferences
* Watch for changes in sharedPreferences
for simple things like persistent UI state (beyond remembered state).
In my implementations, I'm duplicating state between the viewmodel and the preferences (loading prefs on instantiation), and updating them both with a "setValue" on the viewmodel.
Putting all the boilerplate into the viewmodel for a bunch of observable UI states based on preferences is overly verbose, and the preferences might be 1:1 with the viewModel anyway.
There should be an out-of-the-box mechanism for quickly setting a shared preference and observing the results to cause a recomposition.
Example usecase: Conditionally showing an AlertDialog based on the current app version, compared to a last seen app version.
val currentVersion = stringResource(R.string.current_app_version)
val lastSeen = ObservableSharedPreference("lastSeenVersion","") // default shared preferences
if (lastSeen.value < currentVersion){
AlertDialog(
text={Text(currentVersion)},
onDismissRequest = {
lastSeen.value = currentVersion // or
lastSeen.apply(currentVersion) // or
lastSeen.commit(currentVersion) // with setValue being whatever makes sense for the recomposition usecase, either commit or apply
}
)
}
I was going to provide an example of putting the business logic on a viewmodel and updating an ObservableSharedPreference from there (e.g. calling "viewModel.setHasSeenLatestVersionReleaseNotes()" from onDismissRequest), but the amount of boilerplate required doesn't justify not treating the sharedPreferences as the model+viewmodel. Other example usecases might be DarkModeOverride, CurrentActiveViewEnum, EditModeEnabled, EnabledColumnsBitMask etc. Some may justify transforms in business logic, but most of these don't, IMO.
Either way,
class MyViewModel : ViewModel() {
var viewMode by observableDefaultSharedPreferenceOf("viewMode","")
var lightMode by observableDefaultSharedPreferenceOf("lightMode",true)
// nothing else
}
looks reasonably approachable.