Another one is - what with saving state/process de...
# compose
m
Another one is - what with saving state/process death? In old framework views have a possibility to save/restore their state, how about Compose?
r
This would still be the same. But instead of saving the view state, we would save and restore the state of the model, which in turn will restore the view state.
👍 2
g
+1
also no more implicit magic with view id and view state, everything should be explicit in model, because view have no state anymore
5
m
Makes sense I guess, but what about transient state like for example EditText? Right now if you start typing and rotate the screen, the text is automatically preserved. Does it mean that model now will have to become aware of every single change in the text and save it itself?
g
Of course, did you see the talk from Google IO about compose? it’s their first example
The state is not a part of View (which do not exist for compose, only componetns)
r
@mzgreen yes, that is correct.
m
Yeah I saw the talk but it wasn’t clear for me what is happening under the hoods. Would have to see how a Compose UI component works under the hood or play with it and try to create one myself. Thanks for clarification.
m
But not ALL state is saved in the model
example from IO talk only saves the text
g
Because it has only text state
m
but there are other properties of the EditText (current cursor position, selection, etc.)
would that require developer to save all of those manually if he wants to preserve them over configuration change?
r
@Matej Drobnič Cursor position and selection are handled by the component for you. You only have to deal with text.
m
okay
what if I want to set cursor position?
then I need to handle whle thing myself?
m
@ragunathjawahar so there has to be some way for a component to save/restore data after all? (that was my initial question)
r
@mzgreen that makes sense 🤔
a
the goal is to be able to save and restore all the necessary state. how exactly - we will investigate further later I guess
👍 4