Fixing Backstack Issues After State Restore In Compose

Hey everyone! Let's dive into a tricky situation with NavController in Compose Gears' Tiamat library. Specifically, we're looking at how the backstack behaves after the NavController is restored from a saved state, like when your screen rotates. This can lead to a problem where destinations in the backstack are UnresolvedDestination, which is less than ideal. We'll break down the issue, explore a potential solution, and discuss why this matters. So, let's get started!

The Problem: Unresolved Destinations After Restore

So, here's the scoop: Imagine you're building a navigation setup in Compose with Tiamat. You've got your NavController, handling all the navigation magic, and a NavigationScene to manage your UI transitions. The backstack keeps track of where you've been, allowing you to go back and forth. Now, when your app's state is saved and then restored (think screen rotations), the NavController also restores its state. This means that when you call restoreFromSavedState, the backstack is reconstructed. However, after this restoration, the destinations in the backstack are all of the type UnresolvedDestination.

In a nutshell, UnresolvedDestination means that the NavController doesn't immediately know all the details about these destinations. This can be a real pain because you might need to work with the destinations and their associated extensions right after the state is restored. But, you can't do that if they're UnresolvedDestination. This design prevents you from accessing certain properties or performing actions related to the destinations until you navigate to them again. For instance, if you depend on some parameters or metadata of the destinations on the backstack, you won't be able to get the information right away. This design choice can create problems and is the heart of the issue we're discussing. The original author's issue is a real-world problem, especially if you're building an app with a complex navigation structure. Having the destinations immediately resolved after state restoration would make things a lot smoother.

Code Example: Seeing the Problem

To give you a clearer picture, let's look at a simplified example of how this situation can pop up:

NavigationScene(
    navController = navController,
    handleSystemBackEvent = handleSystemBackEvent,
    destinations = graph.destinations(),
) {
    val current by navController.currentNavEntryAsState()
    // backstack will only contain UnresolvedDestination after state restoration (no extension available, etc.)
    val backstack by navController.currentBackStackFlow.collectAsState()
    val state by navController.currentTransitionFlow.collectAsState()

    AnimatedContent(
        targetState = current,
        contentKey = { it?.contentKey() },
        modifier = modifier,
        transitionSpec = {
            contentTransformProvider(state?.isForward ?: true)
        },
    ) {
        CompositionLocalProvider(
            LocalNavAnimatedVisibilityScope provides this,
        ) {
            EntryContent(it)
        }
    }
}

In this code, we're setting up a NavigationScene that uses a NavController. We're also using currentNavEntryAsState() and currentBackStackFlow to observe the current navigation entry and the backstack. After state restoration, the backstack will contain UnresolvedDestination. The core issue appears within the backstack variable, where after the restoration of the state, all destinations are of the UnresolvedDestination type. If you try to access any property or perform any action on these destinations at this point, it won't work until you navigate to them again. This behavior can be really limiting, especially if you need to perform certain operations based on the destinations immediately after the state is restored.

The Question: Resolving Destinations Sooner?

The big question is: Can we resolve these destinations immediately after NavController::restoreFromSavedState? Instead of waiting until you navigate to them, why not have the NavController resolve the destinations right away during the restore process? The core idea behind the proposed solution is to perform the resolution of the destinations right at the end of the restoreFromSavedState method. The existing implementation of restoreFromSavedState can be extended to include the resolution step immediately after the state is restored. This would involve ensuring that the necessary information is available to resolve the destinations correctly. In essence, the goal is to update the NavController so that the destinations in the backstack are fully resolved and ready to be used immediately after the state is restored. Implementing this change could significantly improve the developer experience, allowing developers to work with the destinations immediately after state restoration, without the need for additional workarounds or delays. This simple change could remove this problem and help a lot of developers in the future.

Benefits of Immediate Resolution

So, why is resolving destinations immediately after restoreFromSavedState a good idea? Here's why:

• Improved Developer Experience: Developers can immediately access and work with the destinations after state restoration, which makes the development process smoother.
• Reduced Complexity: It avoids the need for workarounds or additional logic to handle UnresolvedDestination. Developers can focus on the core functionality of their app instead of dealing with the limitations imposed by UnresolvedDestination.
• Enhanced Functionality: This approach enables features that rely on destination information being available immediately after restoration. Imagine wanting to update the UI based on the destinations in the backstack, display specific content, or pre-load resources. With resolved destinations, these actions can be performed without extra steps.
• More Reliable Application State: It ensures that the application state is consistent and up-to-date immediately after restoration. This can prevent unexpected behavior or errors that may occur when destinations are not immediately available.

Potential Implementation Considerations

Implementing immediate resolution of destinations after restoreFromSavedState involves a few key steps, and it is important to think about these things. First, you need to ensure that all the necessary information for resolving the destinations is available during the restore process. This may include the registered destinations, any associated parameters, and other metadata needed for each destination. Secondly, you'll need to modify the restoreFromSavedState method within the NavController to resolve the destinations after the state is restored. This could involve iterating through the backstack entries and resolving each UnresolvedDestination using the available information. You'll want to add some checks to the process. For example, what happens if a destination is no longer registered, or if the information needed for resolution is missing? Implementing this change correctly would involve making sure these scenarios are handled gracefully to prevent unexpected errors. It's essential to test the implementation thoroughly to ensure it works correctly in various scenarios, including different navigation flows and state restoration situations. Thorough testing will confirm that the destinations are resolved correctly and that the app functions as expected after state restoration. These ideas are critical when dealing with navigation in a complex app. By following these considerations, developers can provide a more seamless user experience and make app development easier.

Conclusion

Dealing with UnresolvedDestination after state restoration can be a headache. By resolving the destinations immediately after NavController::restoreFromSavedState, we can create a smoother developer experience, and a more robust application. While this change might require some careful implementation, the benefits are definitely worth it. It simplifies development, enhances functionality, and ensures your app is always in a consistent state. It would be great to see this feature in the Tiamat library! Hope this helps you understand the problem and think about possible solutions! Happy coding, guys!