```var state by savedInstanceState{0} Button(onClick ={state++}) { Text(text = "Increase $state"...

# compose

[Fudge]

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

[Adam Powell]

Depends on what kind of restart we're talking about

[Fudge]

the one where I press the debug icon again

[Adam Powell]

Long-winded context incoming 😄

[Adam Powell]

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.

[Adam Powell]

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

[Adam Powell]

@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

[Fudge]

Oh I see, the words "process recreation" made me think it's an alternative to saved preferences

[Adam Powell]

The above is just where we're starting from today 🙂

[Adam Powell]

Ahhh, ok

[Adam Powell]

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

[Fudge]

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

[Adam Powell]

Expected use cases for it are things like your current navigational state or scroll positions

[Adam Powell]

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

[Adam Powell]

But as a quick proof of concept, yes, rigging something like that up should be quite possible

[Adam Powell]

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

[Adam Powell]

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

[Fudge]

oh, shared preferences is getting replaced? finally the data storage solution will have a sensible name

[Timo Drick]

Anyway it would be better to handle peristent data not in the UI code directly.

[Joost Klitsie]

@Fudge if I am correct, you can simulate a system killing the process with the black square Terminate Application button in for example logcat

[Joost Klitsie]

if you then start the application again (so not reinstalling 🙂 ) it will be recreated

[Joost Klitsie]

and you can test the savedinstancestate

[Adam Powell]

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"

[Joost Klitsie]

@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)

[Adam Powell]

that is a long and contentious question 🙂 the default mode of operation for it is that reads are suspend functions

[Adam Powell]

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

[Joost Klitsie]

that is good to hear 🙂

[Joost Klitsie]

I guess on app startup you can show a startscreen while loading the preferences at first

[Adam Powell]

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

[Joost Klitsie]

the ingenuity of the human mind 😅

[Fudge]

@Adam Powell How does the new data store thing compare to Room?

[Adam Powell]

nosql vs. sql, in a very rough analogy