Does the `Navigation component` thing require seri...

# compose

[ursus]

Does the Navigation component thing require serializable arguments AGAIN? I thought compose was new start and trying to lift this limitation.
This means I'll serialize/deserialize objects to json on main thread, right?
And let me guess the advice is to not pass in complex argument .. great.

[Ian Lake]

You shouldn't be passing complex types between screens at all. Pass the ID of the object and have a single source of truth that has the observable source for that data.

https://youtu.be/0z_dwBGQQWQ?t=930▾

[ursus]

Thats very minimal view of the world. Obviously if such truth exists, passing id is easier, however it's not always the case. Say reacting to events which carry a payload etc. And having a static cache just to set arguments to, and then clear then once consumed is..eh self imposed limitation.

Basically, there is state, and there are events. Not everyting is state.

[Ian Lake]

Arguments are always state though

[Ian Lake]

it is literally the identity of the screen

[ursus]

I disagree. Then userId you want passed it is state and therefore should be indirectly pulled in via some static layer by that logic

[Ian Lake]

I feel like your tone is being argumentative for the sake of being argumentative and that's not constructive. Maybe you can explain a concrete use case and we can talk through that

[ursus]

Let's say there is some data layer code fetching for new Stories. If there are new stories to display, you should display the IG-like stories ui with argument of List<Story>

You'd want to have the "to be displayed" stories set to some static cache, generate a key, set the key as event payload, and on the ui receiveing end, navigate to StoriesScreen with that string key argument, and pull the data from the cache on the other end?

[Ian Lake]

Taking this a step at a time, so you have a Home screen that talks (indirectly or directly) to a data layer that is your source of truth for Story data?

[ursus]

Lets say Activity collects StoriesChecker.newStoriesFound : Flow<Event<List<Story>>> as sort of event bus, that list is not kept anywhere to be pulled from

[Ian Lake]

So how do you handle configuration changes? Process death and recreation?

[ursus]

I see what you are getting at. Issue is with your approach, when do you evict the cache? If I clear it right upon displaying, then orientation change happens and data is gone, process death is the same thing. So it needs to be cleared then user is done with the stories. And that requires thinking. As opposed to just passing in the list of stories as argument, since theyre not backed by a cache anyway, as they're not to be cached semantically. Thats why this issue comes up again and again - caching just for sake of passing in screen arguments

[ursus]

class Activity {
	onCreate {
		scope.launch {
			storiesChecker.newStoriesFound
				.collect { stories ->
					screens.push(StoriesScreen(stories))
				}
		}
	}
}

something like this

[Ian Lake]

Mmm, so with this setup, you just...lose the user's state entirely?

[ursus]

when

[Ian Lake]

when there's a configuration change, when your process is killed and restarted because the user took a phone call or decided to take a picture, etc.

[ursus]

well, and that the issue, that this is a very android thing, configuration change restarts hopefully will go away with the manifest configs as activity recreation during same process runtime is silly; but yes process restart is a problem; and mostly because of this issue, even big apps don't handle it at all

and basically what you're implying is everything should be database cached

[Ian Lake]

Do you view 'even big apps don't handle it all' as a problem? Should taking a picture in the camera app wipe out your app's state?

[ursus]

well im just frustrated because ios doesnt have this problem, atleast the arguments thing is localized to the nav controller graph and my screens can be pure, unlike fragments

and its exaggerated by the fact that on modern phones it never happens

therefore whole design is limited by what is a edge case in practise

[Ian Lake]

Do you think it is an issue to lose the user's state in those edge cases?

[ursus]

if it were everytime or half the time .. but its never for my pixel 5, which is not even a high end

[Ian Lake]

Do you think it is an issue where you don't lose the user's state on a $700, released in the last year phone but you do lose the state quite a bit more on a $250 phone or a phone from 4 years ago?

[Ian Lake]

FWIW, A Nexus 4, released in 2012, runs Android 5.1.1 (API 21) and would be compatible with Compose's minSdkVersion

[ursus]

I know the reasoning and how it works, but someone chose how it works and I believe it wouldn't look like that if it were designed today, even if targeting the 250 dollar phone, since those don' have 56MB of ram or whatever it was in android 1

[ursus]

Just turn on the Dont keep activities dev setting and try to use Uber. And they have a 200+ developer android team, and a billion dollar company .. someone there made a deliberate choice to ignore process restore, not just for fun.

[ursus]

and these are just apps, which are tiny. look at games etc, nobody design games around android process restore, even though they're the biggest offender

[Ian Lake]

Do you think that those specific examples are issues that those teams should solve?

[ursus]

What I think is they made a calculation where they decided to not support it, and therefore optimized their arch. for developer velocity, and arguably made the correct choice as I never had issues with the app, and realistically users of 10year old phones don't browser play store for new apps etc. Sure you might argue emerging markets but thats a different story

[ursus]

also even google apps dont 100% restore, see youtube, basically anything thats not sql cached is thrown away

see instagram, it looses scroll state, which is like their n1 use case

so I guess the "market" has spoken

[Ian Lake]

Android already supports saved instance state (which Compose exposes as rememberSaveable) precisely for state that needs to be saved over process death and recreation, but not persisted to disk

[Ian Lake]

Do you think losing not only the scroll position, but the whole state of what screen you were on, what video you were watching would be worse? Or about the same?

[tad]

There are other good reasons to keep nav destinations simple. Deep linking is one of them, which also requires building a screen with no prior state.