Could someone share a good example of production level navigation with compose? I found this by accident and now I'm questioning some decisions. When I play my app I start with the splash screen, I verify the user state. and then decide where to go. I just learned that this might be incorrect. So shouldn't I use my splash screen to load new information? Should I have some sort of dynamic destination that does this information loading and lands you in whatever the "correct" destination might be?

I think this is partially related to state saving/restoring as well Eg if a user is on a certain screen of interest then should they be returned to that screen upon app restart? If so then you will need to save some info on how to get back to that screen, possibly restoring any states of interest as well such as any text that may have been entered but not yet saved/confirmed for example, an unsaved document is usually backed up and then restored if possible upon opening the app if the app is or contains a document editor

I'm looking for a production level example. I know how this works in general and my current approach works. I never stumbled, for example, in the described issue. I would have for example, in any given deep linked screen, a handler that would check any required information for that to work. I'm a little thrown by the statements that your first destination shouldn't be splash screen.

Well a splash screen or loading screen is usually a temporary screen that is displayed while all info for the main view is loaded For example android displays a boot animation while it loads everything needed to display the UI and bring up the system For an app this depends on what the purpose of the main screen is and whether displaying a splash screen is worth it in terms of, for example, time taken to load If loading the main ui is very long then the splash screen may inform users to think that the app is hanging or unresponsive since nothing is happening If the splash screen is animated then this helps let users know that the app has not become unresponsive Otherwise another approach is to dynamically load the UI in such a way that does not need to wait for the entire UI to load in order to display itself Which is probably why it shouldn't be a splash screen because the main contents itself can be designed to load almost instantly with additional content being loaded in when ready As apposed to waiting for every single piece of content to load and be drawn before displaying the main content An example of this is usually a photo gallery app, where each picture is loaded and displayed in real time and the user can see which pictures have been loaded and which pictures are still loading, and they can even scroll while the pictures are still loading if desired Though runtime ui loading is a basic optimisation for reducing the time taken to transition to a view when it knows that it does not require certain data to actually draw itself to the screen, and can get away with drawing that data at a later point when it has finished loading I do not have much experience with real time ui loading however so I cannot help much but hopefully this helps

But again, the explanation doesn't really help, maybe @Ian Lake would know a good reference besides documentation to this because, again, even then I understand the concept, I would appreciate something more tactile. Because, again, I never had such described problems. And thank you Koneko, but I would rather have you not answering because reading trough all this to be able to formulate an answer and see if you got any points, and then realizing that nothing related to my question was exposed is kind of disappointing. I even mention in my comment after your first answer that I knew how it worked, I was looking for a production example. Places like: https://compose.academy/ wont have anything And I went to something like @Joe Birch is touching and I can't see this happening around there too, so. I really need something more than what you can read around.

Ok, sorry

I didn't meant to be rude but I'm not looking for business rules on how to use a splash screen, or the already known mechanics because the conversation I linked https://kotlinlang.slack.com/archives/CJLTWPH7S/p1610122322302700 already describes this, I'm fishing for a realistic example. Because between theory and practical, implementing this is quite complex. Mainly when your app covers what Ian is describing in this video with fragments as example. Abstracting how to do this from fragments can be done but I don't feel safe diving into this as I'm feeling blinded by the amount of layers to this. What do I mean with layers. What I feel like is that every entrance to the application (opening the app from the system icon or deep linking) now should be treated like I treat my splash screen. What confused me a bit is that if the user would open the app using deep linking I would take him trough my splash screen, load data and present. If the app would already be opened then the splash screen would have already loaded the information. I was taking the stance that the splash screen is my setup step before presenting any information. I know there is no general rule, its a case based system, no solution resolves them all. But I know that for production level products, having login/no login/offline/online apps there are some common patterns you should follow. I also know this can fall into taste. Like modularizing the whole app. But I believe there may be a middle ground for a best approach.

I didn't mean to be rude

That's ok, I understand

And I know about the tagging thing but the post I linked already had a comment with no response and I feel this is mildly important topic