I have a catalog (main page) that displays ads thumbnail, by taping on it, user is pushed a detail view from which it can tap on a message button which pushes the message screen. This message screen requires on some circonstances to be signed in: therefore it might display a button that pushes the sign in screen.
Overall here is the hierarchy:
catalogue -> ad detail view -> message screen -> sign in screen.
My use case is that when the user successfully signs in, I need to update the message screen.
I can propagate a 'onUpdate' callback down the tree but I am questioning that method.
Does Flutter offer a generic or better way to propagate state changes from the bottom up?
You can try
Using Global Variables for the State of the Button or
Using Provider
Personally for small Apps I use global Variables but as soon as it gets more complicated you should consider Provider.
Related
I have the following situation:
I have an onboarding user flow that consists of lets say 5 screens where the user provides some personal details on each screen, the details are persisted into the database after each screen and then the user is taken into the home screen.
Desired behaviour:
When the user provides detalis until e.g. screen 3/5 and then exits the application, the flow should resume from screen 3/5, with the posibility to return back to screens 1 or 2 to change the already provided details.
I couldn’t find anything in the navigator documentation that would help me, and if you could provide at least a documentation lead for this edge case it would be amazing.
Basically I need to restore the stack of screens “in the background” when the user re enters the app and “show” the stack from the screen i/n (where i is the first screen where the user did not provide details in the last session) with the possibility to navigate back in the stack to the screens before i even if those screens were not shown to the user in the current session.
Or even more simply put, I need to restore a stack of screens in a new app session and show the user a screen from any position of the navigator stack based on data persisted on a db.
Thanks!
You can use PageView widget from flutter for your onboarding process, that way you can save on which page user was by the database entries, and you can directly jump on the specific page you want by the index. That way you don't have to worry about navigating through the screens.
Here's the link for PageView Widget implementation: https://www.geeksforgeeks.org/pageview-widget-in-flutter/
Well I think first you need to store the data the user already entered and the screen number he was on. You can use something simple as shared_preferences.
Then you have to use routes to navigate to a specific screen.
I know there are some duplicate/similar questions, I read them all but I can't get the right answer.
I'm using Getx to navigate between screens(Get.toNamed()) and I was just wondering if there's any way to remove a certain route from the navigation stack. Let's say I have the following routing for my sample social networking app:
main screen -> post screen -> profile screen -> (another) post screen
I want to remove the first post screen and add a new post screen after the profile screen but able to go back to the profile screen when I press the back button from the second post screen(another back button goes to the main screen and if I go to profile screen(again) from the second post screen, the first profile screen will also be removed). The reason I want to do this is because I want the screens to have only one instance.
I tried saving the Get.rawRoute of post screen and called Get.removeRoute(route) when opening the second post screen from the profile screen but I get "'route._navigator == this': is not true." assertion.
Is it impossible because it's a stack? but.... I just don't think this is impossible, there must be a way...
Help me Flutter Masters!
Just kidding, saving the Get.rawRoute of the post screen and calling Get.removeRoute(route) before opening another post screen works just fine, I made a mistake. HAHAHAHAHAHAHA
In my flutter app, I'm implementing a full page view using -
SystemChrome.setEnabledSystemUIMode(SystemUiMode.immersiveSticky);
Now, It works just fine until I reach a page in the app that uses PinCodeTextField. In that page, a user can input the received OTP.
Now, the issue is that as soon as the page is opened, "Auto-fill code from Messages" appears and it brings back the notification bar as well as the bottom menu bar.
I have not implemented this feature and looks like somehow It has come on its own. Though, it is a nice feature to have, I really don't want it to mess up my app's full page view. Not until I restart the app, it goes back to full page view but again whenever I reach to a page with PinCodeTextField, that popup appears and messes things up.
Now, how do I force my app to go back to full page view ? If that is not possible, how do I stop Auto-fill code to keep coming on my screen on such pages ?? Kindly help.
I can't really share code for this as it's for my entire ~large~ application, but is it normal for a flutter application's lower navigation stack to be updated when the current page is?
For example, in this page I have a standard form with a few TextFormFields:
Whenever I click on one to start typing the page sets state as expected, but by adding print("Update"); inside the build function of the bottom page of the navigation stack, I can see that page is being updated too. It happens on all pages I put on top of the first route page. I've also been experiencing that the home page gets slower as the app has been open for longer, could this be a cause for that problem too?
When a user shuts down my app, I'd like to send them back to where they left off. The app starts on a tableview, the user drills down to another tableview and then clicks a row for a detail view. When they startup the app again, I have two choices:
1.) Display options (alertview) for returning to the previous location or cancelling and remaining on the start view.
2.) Immediately jet them over to the detail view.
I don't like either option. (1) gets to be nagging if you must go through it on every startup. (2) could be confusing and I'm not sure technically how that works.
Any suggestions on the above or something different?
But 2) is the preferred way according to Apple's HIG:
Even though your application does not run in the background when the user switches to
another application, you are encouraged to make it appear as if that is the case. When your
application quits, you should save out information about your application’s current state in
addition to any unsaved data. At launch time, you should look for this state information and
use it to restore your application to the state it was in when it was last used. Doing so
provides a more consistent user experience by putting the user right back where they were
when they last used your application. Saving the user’s place in this way also saves time by
potentially eliminating the need to navigate back through multiple screens’ worth of
information each time an application is launched.
As far as the technical implementation, it's exactly the same: push your subviews onto the navigation controller. The only thing I'd do differently is not animate the 'drilling down.'
When your app starts up, it has an initial 'look', screen, view, whatever.
When it starts back up and has a previous context, add a link or button naming the previous context that allows returning there.