saved data not exist after restarting app

[fatfatson]

so what's the difference with just using the raw ViewModel?

[husaynhakeem]

Not sure what you mean by raw, but you'll still be using a normal ViewModel when using the saved state api. You'll just have access to a handler that allows you to write and read data from the saved state -data that will persist even if the app process is killed-.

[fatfatson]

but I have download the source and build it to run in emulator, then kill the app from task manager , and reopen it, the saved state data is completely empty...
so I don't know what's the effect of using SavedStateVMFactory?

[husaynhakeem]

I don't think that would work, since you're manually killing the app yourself. In order to simulate the system killing your app process, you can try one of two things:

1. Go to Developer options on your phone, and enable Do not keep activities. Now on the app, enter some values, click on the home button (this will kill the app), open the app once again, the values you entered will be displayed.

2. With the app in the foreground, run this command

adb shell ps -A |grep com.husaynhakeem.savedstateplayground

You should see an output similar to this

u0_a291    23673    701 3725304   71896 0    0 S com.husaynhakeem.savedstateplayground

Note that 23673 is the process id for the app. Now click on the home button, then run

adb shell am kill com.husaynhakeem.savedstateplayground

This will kill the app's process. Open the app once again*, you'll see that whatever values you had entered previously are displayed.

(*) After re-opening the app, you can run the first command to make sure that the PID (process id) of the app is different.

[fatfatson]

thanks for teaching me so much~
but how about the manually killing? it's a common behaviour for users( such as me) .
are there something for saving state at once( just when setting them)?

[husaynhakeem]

When the app process is killed by the system, it isn't the user's fault, which makes sense for the system to offer a way to get back whatever data was in use when that happened.

On the other hand, the scenario you're describing is intentionally done by the user, saved state doesn't work for this case (it wouldn't have made sense that much if it did). If you want to persist some data even when the app is killed by the user, you could just use local persistence (database, shared preferences, etc).

[fatfatson]

ok, I have got the idea.
but if I have already use some local persistence way, it should also satisfy the scenario where SavedStateVMFactory make sense, so I still don't know where it's necessary.

[husaynhakeem]

Let's take an example. You have a food delivery app with a screen where the user chooses what they want to buy from a restaurant. If a user starts an order (selects a burger, adds fries and chooses a drink) but doesn't complete it, you'd want the user to find this same order even if they quit this screen and come back to it later (even if the system killed it at some point).

You may choose to store this information in a database. This approach isn't wrong, but it feels a bit too much, you'd need to create the database, data access object, tables, and handle the interactions with the database. Instead, you can just store it in the saved state, it's easier (and accomplishes the same with less code). Additionally, using the saved state can go really well if you have the state of your UI in the ViewModel, and that's exactly the purpose of SavedState, storing the state of a screen so that when a user comes back to it later, it would be the same as they left it.

I think persisting data locally with a database works really well to support an offline mode of the app. So in the same context of the restaurant app, information such as the user's profile, orders history and favorite restaurants (notice how they all require an internet connection to get) would make sense to store locally.

[fatfatson]

thanks again~
I think I have known its usage: save something not very important -- such as UI-related data, may be some temp data, keeping it only because it's just there before. its target is recovering the UI to origin state, not to save the important data.
am I right?

[husaynhakeem]

Correct. The typical example is saving a list's current index.