[docs]: Having hard times when implementing navigation to view after user taps on notification

[MirzaCickusic]

Describe the missing piece of documentation

Here is how my app navigation is set:

StartupView (check is user is signed in) -> HomeView which looks like this:

class HomeView extends StackedView<HomeViewModel> {
  final int startingIndex;

  const HomeView({Key? key, required this.startingIndex}) : super(key: key);

  @override
  Widget builder(
    BuildContext context,
    HomeViewModel viewModel,
    Widget? child,
  ) {
    return flavorBanner(
      child: ScreenTypeLayout.builder(
        mobile: (_) => AppNavigationBar(initialIndex: startingIndex),
        tablet: (_) => AppNavigationBar(initialIndex: startingIndex),
        desktop: (_) => const AppNavigationRail(),
      ),
      show: kDebugMode,
    );
  }

  @override
  HomeViewModel viewModelBuilder(
    BuildContext context,
  ) =>
      HomeViewModel();

  @override
  void onViewModelReady(HomeViewModel viewModel) => SchedulerBinding.instance
      .addPostFrameCallback((timeStamp) => viewModel.runStartupLogic());
}

and AppNavigationBarViewModel would use the startingIndex, provided by HomeView and pass it to the AppNavigationBarView to display the right screen I want. This works without issues, when using _navigationService.replaceWithHomeView(startingIndex: 2); from StartupView for example, it navigates to the right screen.

The issue arises when I try doing the same when the user clicks on the notification, although it is explained here, that this should work https://www.youtube.com/watch?v=Lq9-DPKWtIc&t=3s, I still can't seem to find a workaround for my scenario.

What happens when the user clicks on a notification, here are logs for example:

Navigating to ThirdScreenView
I/flutter (26686): replaceWithHomeView: 2
I/flutter (26686): Current route: null
I/flutter (26686): Returned result: null
E/OpenGLRenderer(26686): Unable to match the desired swap behavior.

Which is printed from app.route.dart:

Future<dynamic> replaceWithHomeView({
    _i12.Key? key,
    required int startingIndex,
    int? routerId,
    bool preventDuplicates = true,
    Map<String, String>? parameters,
    Widget Function(BuildContext, Animation<double>, Animation<double>, Widget)?
        transition,
  }) async {
    print('replaceWithHomeView: $startingIndex');
    print('Current route: ${routerId}');

    return replaceWith<dynamic>(Routes.homeView,
        arguments: HomeViewArguments(key: key, startingIndex: startingIndex),
        id: routerId,
        preventDuplicates: preventDuplicates,
        parameters: parameters,
        transition: transition);
        ```

**Note: If I use ` await _navigationService.replaceWith(Routes.thirdScreenView);` from when notification is tapped, this would navigate to the route without issues, but it wont have the app navigation bar rendered since that needs to go via HomeView route to be shown.**

My feeling is that when using `_navigationService.replaceWithHomeView(startingIndex: 2);`, the things are not getting initialized again, or in time for the logic of handling the staring index to do its thing. 

If we would have some proper documentation on this subject, or some kind of more complex example, implementing this functionality could be much easier.

Thanks in advance!

[FilledStacks]

Is this for a mobile app installed to device or a PWA or a web app?

[MirzaCickusic]

This is for mobile app.

In meantime, I got the workaround for this, by calling _navigationService.replaceWithStartupView(startingIndex: 2); when user clicked on notification while app is background. So this way I'm passing starting index value from StartupView -> HomeView -> AppNavigationBar.

Maybe not ideal solution, but it works for now...

Also had to edit initial route in MaterialApp:

 return MaterialApp(
          initialRoute: Routes.startupView,
          onGenerateInitialRoutes: (String initialRouteName) {
            return [
              StackedRouter().onGenerateRoute(
                RouteSettings(
                  name: Routes.startupView,
                  arguments: StartupViewArguments(startingIndex: 0),
                ),
              )!,
            ];
          },

[FilledStacks]

I don't think it's not ideal.

If stacked provides a way to get it done then it's been placed in there intentionally. Even if I now can't remember when we added that lol

[MirzaCickusic]

Yup, fell free to close this