How to retrieve datastore value before root component creates childstack

[OsmanMusse]

Hi arkivanov,

I have a quick question and would like advice on how to go about it. Basically I have RootComponent and would like to know how to pass some datastore preference value whenever a location was selected previously, and base the initial configuration of the root components child stack when to show the initial screen based on the datastore preference. But it seems like the childstack of the root component create's the initial configuration before the datastore preference is retrieved. How would you solve this. Here's the code for the root component.

class DefaultRootComponent(
private val componentContext: ComponentContext,
private val mainContext: CoroutineContext,
private val ioContext: CoroutineContext,
private val homeScreenFactory: HomeScreenComponent.Factory,
private val appPreferencesRepo: AppPreferencesRepository
):  RootComponent, ComponentContext by componentContext {


init {
    println("HELLO ROOT COMPONENT CREATED === ")
    retrieveInitialAppPref()
}


private val rootNavigation = StackNavigation<RootConfig>()

private val _rootState = MutableValue(RootModel())
override val rootState: Value<RootModel> = _rootState

override val backDispatcher: BackDispatcher =
    (backHandler as? BackDispatcher) ?: BackDispatcher()


// Internal logic of decompose that Manages the navigation and the navigation stack
override val routerState: Value<ChildStack<*, RootComponent.RootChild>> =
    childStack(
        source = rootNavigation,
        serializer = RootConfig.serializer(),
        initialConfiguration = if(_rootState.value.isDefaultLocationSelected) RootConfig.Main else RootConfig.Landing,
        handleBackButton = true,
        childFactory = ::createChild,
    )



override fun navigateToHomeScreen(selectedLocation: String) {
    // Update Preferences to the default location selection
    coroutineScope(mainContext).launch {
        withContext(ioContext){
            appPreferencesRepo.setDefaultLocation(location = selectedLocation)
        }
    }
    rootNavigation.replaceCurrent(RootConfig.Main)
}
private fun retrieveInitialAppPref(){
    coroutineScope(mainContext).launch {
        println("DATASTORE 1 == ")
        withContext(ioContext){
            val isDefaultLocationSelection = appPreferencesRepo.fetchInitialPreferences().isDefaultLocationSelected
            _rootState.update { it.copy(isDefaultLocationSelected = isDefaultLocationSelection) }
            println("ROOT STATE == ${_rootState.value}")
        }
    }
}

private fun createChild(
    config: RootConfig,
    context: ComponentContext
): RootComponent.RootChild{
    return when(config){
        is RootConfig.Landing -> {
            println("CREATING CHILD 1 === ")
            RootComponent.RootChild.LandingRoot(
                DefaultLandingComponent(context)
            )
        }
        is RootConfig.Main -> {
            println("CREATING CHILD 2 === ")
            RootComponent.RootChild.MainRoot(
                homeScreenFactory.create(componentContext = context, onNavigateTo = {})
            )
        }
    }
}



@Serializable
 private sealed interface RootConfig {
     @Serializable
     data object Landing : RootConfig

     @Serializable
     data object Main : RootConfig
   }  
 }

[arkivanov]

The usual way is to show a loading screen (component) while you retrieve the value and then replace the stack with the actual component depending on the value. Probably, this can be also combined with a splash screen.

[OsmanMusse]

Just a quick follow up to your reply you gave arkivanov. I went with your approach with having a loading screen component to re retrieve the datastore preference values which then allows me to replace thee stack the with the actual component. I also combined this with the Splash screen(LaunchScreen in IOS). The only problem I had with this approach is because I'm using jetpack's DataStore data storage solution(new recommended way of storing data), it's built with the async nature, which would delay the retrieving of the preference, which means for a split second it would show a blank screen after the IOS LaunchScreen is showed.

I was able to just ignore by having this code below inside the DefaultRootComponent

` private val isLocationAssigned = runBlocking {  appPreferencesRepo.fetchInitialPreferences().isDefaultLocationSelected.   }` 

And then set the initial configuration to the root component child stack based on this property

override val routerState: Value<ChildStack<*, RootComponent.RootChild>> =
    childStack(
        source = rootNavigation,
        serializer = RootConfig.serializer(),
        initialConfiguration = if(isLocationAssigned) RootConfig.Main else RootConfig.Landing,
        handleBackButton = true,
        childFactory = ::createChild,
    )`

This was the approach I went with which meant I'm blocking the calling thread as I'm using runBlocking which reads the data from DataStore synchronously. This also means I don't need the landing component as I'm using the IOS built in LaunchScreen as my splashscreen. I know this is more of a jetpack related questions, but regarding the RootComponent do you think this is a bad practise in the decompose, or if problems can occur accessing the datastore in this manner

P.S. oh, by the way, If your wondering I'm using Compose Multiplatform on the UI, so this is more of a iOS related question as android has the SplashScreen api, which allows you to keep the splash screen on the screen for longer periods,If you need to for example load a small amount of data, such as loading in-app settings from a local disk asynchronously. Compose Multiplatform doesn't seem to have this yet unfortunately.

[arkivanov]

Sorry, but it's a bit unclear.

I went with your approach with having a loading screen component to re retrieve the datastore preference values which then allows me to replace thee stack the with the actual component. I also combined this with the Splash screen(LaunchScreen in IOS).

The above looks like the issue was solved.

The only problem I had with this approach is because I'm using jetpack's DataStore data storage solution(new recommended way of storing data), it's built with the async nature, which would delay the retrieving of the preference, which means for a split second it would show a blank screen after the IOS LaunchScreen is showed.

The above is not quite clear. You can init the stack with a Loading screen. Then once you receive the response from DataStore, you can use replaceAll(YourActualScreen).

Also, using runBlocking with DataStore is mentioned in the docs. I wouldn't bother and use it for this case as well. Or maybe just use the old school Shared Preferences, or Multiplatform Settings if KMP is required. They both allow synchronous access without coroutines.

[OsmanMusse]

The above is not quite clear. You can init the stack with a Loading screen. Then once you receive the response from DataStore, you can use replaceAll(YourActualScreen).

wouldn't this require the root component to use a composable for the LoadingComponent(RootChild.LoadingRoot) associated when starting the children stack with the initial configuration, remember I'm doing the splash screen in IOS via LaunchScreen. So when the iOS finishes showing the launch screen(splash screen in android), the rootComponent will be created and since it's been given an initial configuration of LoadingScreen it will show a blank screen(white screen) while the datastore preference value is being fetched normally this is quick but still the 1.0 second wait will show the blank screen before navigating to the LandingScreen

fun App(rootComponent: RootComponent) {

 println("Child Created == 2")

 val childStack = rootComponent.routerState

 Children(
    stack = childStack,
    modifier = Modifier.fillMaxSize(),
    content = { child ->
        println("Child Created == ")
       when(val childCreated = child.instance){

           is RootComponent.RootChild.LoadingRoot -> Unit
           is RootComponent.RootChild.MainRoot -> MainScreen(childCreated.mainComponent)
           is RootComponent.RootChild.LandingRoot -> {
               OnBoardingSelectLocation(
                   onLocationSelect = {  location ->
                       rootComponent.navigateToHomeScreen(selectedLocation = location)
                   }
               )
           }
       }
    }
)

}`

[arkivanov]

Yes, you will need to implement a loading UI, which kind of makes sense.

[aartikov]

In Android, you can use SplashScreen.setKeepOnScreenCondition to keep the splash screen visible while data is loading. There might be a similar feature on iOS, but if not, you may need to create a custom UI that mimics the look of the Launch Screen.

[OsmanMusse]

In Android, you can use SplashScreen.setKeepOnScreenCondition to keep the splash screen visible while data is loading. There might be a similar feature on iOS, but if not, you may need to create a custom UI that mimics the look of the Launch Screen.

Thanks for responding! I'm actually familiar with SplashScreen.setKeepOnScreenCondition in Android, which allows you to keep the splash screen visible while data is loading. My concern is more on the iOS side of things, as I've already searched online (Google and Stack Overflow) about this issue. Here are the three solutions I found:

Solution 1

You can create a view controller that uses the LaunchScreen storyboard, present it (not animated) on applicationDidFinishLaunching or applicationWillFinishLaunching, and dismiss it whenever you want.

Keep in mind this is discouraged by Apple because it gives the impression that your app takes a lot longer to launch, which is bad user experience and might cause some of your users to delete your app.

Solution 2

Arkivanov's solution involves creating a LoadingComponent to display a loading UI, essentially acting as your splash screen. You place the datastore preference fetching code within this LoadingComponent. Once the data is retrieved, you use a callback to notify the RootComponent that the preferences have been successfully fetched. The RootComponent then uses ReplaceAll() to navigate to the appropriate screen.

This appears to be a good solution as you're separating your code into business logic components using a LoadingComponent. However, since you're adopting the approach of displaying a loading UI with a LoadingComponent, you'll need to disable the iOS LaunchScreen (the equivalent of a splash screen in Android). Unfortunately, there isn't a way to completely disable the LaunchScreen in iOS. The best you can do is to leave the LaunchScreen empty, which will result in an initial white screen before transitioning to the RootComponent.

Solution 3

This is a solution I came up with after researching online before consulting Arkivanov. iOS requires every app to include a launch screen, so I'll let iOS handle the LaunchScreen as intended. To retrieve the datastore preference, I'll do so within the RootComponent using a global variable.

private val isLocationAssigned = runBlocking { appPreferencesRepo.fetchInitialPreferences().isDefaultLocationSelected }.       

With this approach, I can set the initialConfiguration (the first component to load) to either the main HomeScreen if a location is already selected, or to the LandingScreen, where the user can select a default location, allowing the HomeScreen to display relevant data.

override val routerState: Value<ChildStack<*, RootComponent.RootChild>> =
    childStack(
        source = rootNavigation,
        serializer = RootConfig.serializer(),
        initialConfiguration = if(isLocationAssigned) RootConfig.Main else RootConfig.Landing,
        handleBackButton = true,
        childFactory = ::createChild,
    )

This approach appears to work as intended, allowing me to eliminate the additional SplashComponent or LandingComponent that Arkivanov suggested. The only downside to this code is that it blocks the main thread. However, this isn't a significant issue since that's the expected behaviour when using the runBlocking coroutine, given its synchronous nature.

Jetpack discusses this in more detail here. In summary, Kotlin coroutines provide the runBlocking coroutine builder to bridge the gap between synchronous and asynchronous code. You can use runBlocking() to read data from DataStore synchronously. Similarly, RxJava offers blocking methods on Flowable.

Sorry for the long explanation, just wanted to make things clear 😊