https://kotlinlang.org logo
Join Slack
Powered by
```var state by savedInstanceState{0} Button(onCli...
# compose
f
Copy code
var state by savedInstanceState{0}
Button(onClick ={state++}) {
    Text(text = "Increase $state")
}
Am I right in thinking 
state
should be saved when I restart the app? Because it doesn't do that
a
Depends on what kind of restart we're talking about
f
the one where I press the debug icon again
a
Long-winded context incoming 😄
This saves the state for surviving configuration changes and process recreation, but if you swipe an app away in the system overview UI, the task is removed and associated saved instance state with it.
Android studio's restart UI uses some pretty harsh mechanisms to do a full reset to make sure your app starts from a clean slate, (I think it's the full force stop mechanism,) as opposed to the Apply Changes operation which tries to preserve as much running state as possible
@nosuid might be able to answer further questions down that road better than I can, but the Studio UI question and expectation is helpful feedback, thanks
f
Oh I see, the words "process recreation" made me think it's an alternative to saved preferences
a
The above is just where we're starting from today 🙂
Ahhh, ok
We've tried not to introduce new terms for this so as not to potentially create more confusion; Android uses, "saved instance state" for this specific concept pretty consistently, but it sounds like we made some assumptions about knowledge of that context in our docs
f
to be honest it's probably easy to make a method / delegated property like that that does what I was thinking of, as long as you supply it some String key or even use the local variable name as the key
a
Expected use cases for it are things like your current navigational state or scroll positions
Do beware of pushing too much private state down into individual composables though, it may make more sense to hoist it up further and remove that kind of long-term persistence need from this layer of your UI
But as a quick proof of concept, yes, rigging something like that up should be quite possible
MutableState<T>
is probably not the right abstraction for many forms of disk-persisted data since it makes it very difficult to know what has been confirmed written to disk or not
SharedPreferences has this problem, hence why https://cs.android.com/androidx/platform/frameworks/support/+/androidx-master-dev:datastore/ is currently in progress, to try to help address some of these things
f
oh, shared preferences is getting replaced? finally the data storage solution will have a sensible name
t
Anyway it would be better to handle peristent data not in the UI code directly.
j
@Fudge if I am correct, you can simulate a system killing the process with the black square 
Terminate Application
button in for example logcat
if you then start the application again (so not reinstalling 🙂 ) it will be recreated
and you can test the savedinstancestate
a
finally the data storage solution will have a sensible name
that's kind of the first indicator that SharedPreferences was never a general purpose data storage solution to begin with 😄 though people have certainly ran with it over the years. it was basically written to hold things of the same level of complexity and importance as, "I prefer dark mode"
j
@Adam Powell will it also be prohibited to call it from the main thread? I have seen people storing (and fetching every activity startup) a user object including a base64 encoded profile picture 😅 slowing down everything thing (yay hidden disk IO)
a
that is a long and contentious question 🙂 the default mode of operation for it is that reads are 
suspend
functions
but there are still plenty of cases where you really can't reasonably move forward to show anything meaningful until you have the data, like the aforementioned dark mode
j
that is good to hear 🙂
I guess on app startup you can show a startscreen while loading the preferences at first
a
and we've seen time and time again that people will figure out a way to block a thread if you give them an async API. In this case someone tossing a 
runBlocking
around a suspend call on the main thread can lead to things going considerably slower than just performing the operation there in the first place, thanks to things like kernel scheduling and priority inversions across the system
j
the ingenuity of the human mind 😅
💯 2
f
@Adam Powell How does the new data store thing compare to Room?
a
nosql vs. sql, in a very rough analogy
2 Views
Open in Slack
PreviousNext
Powered by