Hey! A few months back I received advice about set...

# compose-android

[Jonathan]

Hey! A few months back I received advice about setting the start destination of my NavHost (navigation-compose) to my “Main” route and having logic in my main route view model to detect if a user is logged in or not and routing to my login flow. Reading login state takes some time and causes a noticeable transition between my main and login route. Other apps do not seem to have this transition an displays login flow seamlessly. Was the advice I received outdated or maybe I’ve implemented it wrong? Btw, I’m reading user state from Datastore.

[Pablichjenkov]

A splash animation or loader maybe 🤷‍♂️ 🤔
Although I would rethink the data layer for this login status check to take no longer than a database read or so. Seems like you're going remote all the time. Perhaps consider a cache for the time your token expires.

[Jonathan]

Reading user state is local. Maybe I don’t understand how would the Splash animation help in this case?

[Pablichjenkov]

If it takes more than a second, shown an animation as soon as your main graph entry point starts. Then read the local status in a background thread. When done navigate to the login graph.
If is less than a second UI wise is better to show a solid color screen for this time. You most be doing really heavy job. Try to reduce this status check to something like isAccessToken != Null. Something quick and you won't need none of the above animations.

[Jonathan]

I’m not doing any heavy loading. I think the issue is immediately navigating too another route. The sudden transition between the two destinations with a blank screen looks out of place.

[Stylianos Gakis]

You can keep the splash screen still showing https://github.com/HedvigInsurance/android/blob/develop/app%2Fapp%2Fsrc%2Fmain%2Fkotlin%2Fcom%2Fhedvig%2Fandroid%2Fapp%2FMainActivity.kt#L90 while you're still evaluating you login status.
Once you know what the status is:
• If logged in: just flip the boolean that keeps the splash showing
• If logged out: Do the navigation and directly afterwards flip the boolean.
And yes, use androidx.core:core-splashscreen for this

[Pablichjenkov]

Didn't know about that property 👌

[Jonathan]

@Stylianos Gakis Are you using a conditional start destination for your NavHost?

[Colton Idle]

oooh. i asked sorta a related question.

[Colton Idle]

https://kotlinlang.slack.com/archives/C04TPPEQKEJ/p1717382057662709

[Colton Idle]

so. basically. i think i basically have two approaches to this. possibly highly debated. but....

think of really exceptional cases where it might not be there yet (like the user is updating 100 apps, and just finished restarting their phone after an OS update, and maybe theres some io contention because of that). What do you want to do in that case?

I can see like 3 choices for what you might want to do
1. keep your splash screen showing
2. show a blank screen (so the user sees you got past the splash, but nothing loaded)
3. a blank screen but with a loading indicator
I think 2/3 are basically one option. just depends how you wanna customize your blank screen.

to implement option 1, it can be accomplished via using runBlocking or androidx.splash apis to keep splash screen around

to implement option 2/3 you can have your mutableState of auth/token/loggedIn or whatever actually be 3 states. true/false/null or "auth token"/"no token"/null. and then if its null it means it just hasn't been read yet,

[Colton Idle]

personally. i like the runblocking route so that my app doesn't "start" without it. this might be contrary to what some people think should happen... but it doesn't make sense to see splash > blank screen (possibly w/loader) > the actual screen you should be on. its too jarring IMO and happens to fast that the flashing is annoying.

keep the user on the splash screen, and you have a smooth transition. but I would make sure to only do that with small local data. like a boolean or a token.

[Colton Idle]

this is something that eats at me though. because i definitely feel like im doing something wrong. lol. when im on my own apps i take approach 1. but when im on some teams that have really pedantic people of like "dont do anything in the critical launch path" then i do option 2/3.

[Colton Idle]

FWIW. the flashing is typically a lot less noticable in release builds. curious if you only tried release/debug builds.

[Jonathan]

I went with holding the splash on screen until user state has been loaded. The splash screen covers up most of the screen transition. I also tweaked the transition time to be 100 MS and got manager approval.

[Colton Idle]

Definitely take a look at the video in the thread I posted above as well if you haven't already. that whole case study on why navigation is done that way is really important to comprehend in my opinion or else you'll just be like "why is it so complicated"

[Colton Idle]

also. i remember Adam Powell hanging around here a while back and he basically said that in the login/logout approach... why even navigate to a different destination. Instead just have an if statement in your current destination. and... that is also a valid approach seemingly. lol

[Jonathan]

I remember consulting the video several months back.
A new “intro” video route has being added to my app and the transition from the home screen (start destination) to the new “intro” screen at startup was considered unfavorable by “the powers that be” (design & PR approvers 😄); they don’t want see the Home Route until the intro video has completed playing.
Tweaking the transition duration and holding the splash screen until app state has been loaded has resulted in a much more acceptable UX.

[Colton Idle]

nice. yeah i was going to say that i wonder if you can just make the transition direct with 0ms of animation time.