When I am working on flutter navigator, I could not figure out what is the right way to create a screen.
For example, I have a Home screen and a Products screen. When app load, Home created, and then click a button there to go to Products screen, from Products I can go back to Home.
In this case, two screens are in the navigator stack. If I go to a third screen, and click the Products menu on the drawer list, it will create a new Products screen. Now there are two products screen in the stack.
My question is:
It seems it is normal to have multi instance of same screen in the stack, right?
Is it a good idea to always keep only one instance of one screen in the stack, and is it possible?
If we have to have multi instance of same screen in stack, isn't it wise to only load initial data once? for example, in this case, is it a good practice to keep the products list somewhere and don't pull data from server every time a new Products screen created?
Thanks
1, It seems it is normal to have multi instance of same screen in the stack, right?
No, it's not normal to have multi instance of same screen.
2, Is it a good idea to always keep only one instance of one screen in the stack, and is it possible?
Yes and it's possible with push and pop. Push is adding a new instance on the stack, pop will remove the top stack. It is a good practice to use pop when returning to previous page.
3, If we have to have multi instance of same screen in stack, isn't it wise to only load initial data once?
Depends on the data. If it is mutable throughout, then it is not wise to only load it once. If it is persistent throughout the app's lifetime, use Shared preferences plugin to store it. If it is a constant, storing it in a local database would be better.
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 am building an IOS App and I have a flow that enables users to build and share a post. First they start on a home screen, where they select the media, then another screen to write the paragraph and another one to edit the media and so on. At the end they share the post and I want them to come back to the root view and start the whole flow all over again but without the ability to navigate back.
How do I achieve that? I could technically hack it by disabling the back button in the root view but that doesn't feel clean.
Ideally, I would need to delete the current navigation stack and start a new one when they navigate back to home. Is there a way to do that?
If not, what is the standard way of doing it?
I am building a jscript-based Windows 8 Metro app. The main screen of this application is a scrolling "panorama" view with several list views showing various aspects of the app's state. In some cases the user will select something on the page which results in a navigation to another page (using the WinJS.Navigation.navigate method.
When the user hits the back arrow on the other page, it returns to the main screen, and I use "scrollIntoView" on to position the screen to the section that the user was working on before the navigation occurred.
Unfortunately this hardly ever results in correctly positioning the view. It seems random. I suspect that the page isn't finished being built yet and that the scroll values are set based on the state at some snapshot in time.
Now the question:
Is there some what to be notified by WinJS ListView objects that they are completely rendered and layed out? Or is this the job of the page's ready function?
Thanks for any insight!
Putting multiple list views side by side is Not A Good Idea(TM). I would recommend putting one list view, and placing your content in a grouped data source to get the groups. If the items have different templates, then you can use a custom item Template selector to dynamically select a template.
Additionally, to ensure that the list view is scrolled to the right position, you need to use the indexOfFirstVisible to set the items the name suggests.
I'm creating an app and I need some help with design.
Launch Screen - I want to show 6-8 "category" buttons with labels loaded from an array ("normal" buttons from interface builder - not tab bar buttons or menu bar buttons).
Table Screen - When one of the category buttons is pushed on the launch screen, I want to show a table view with all of the items in that category.
Detail Screen - When one of the items on the table screen is selected, go to a new screen with details for the item. There will be an action button on this screen which will remove the item from the list if pressed.
My questions are as follows:
1) I don't want to show navigation buttons on the first screen. Can I still use a Navigation-Based application and hide the navigation controls on the first screen, or would it be better (easier) to create a view-based application and put a navigation controller "inside" one of the views? I'm totally open to any basic design approach suggestions you may have.
2) I've figured out how to create a sqlite3 file, add it to the project, query it, and generate the table view from the results, but I'm not sure about how to store the sqlite file in a way that will persist on the device when the user upgrades the app later. Any pointers on that?
Thanks for any help/links/documentation you can point me to. I've watched a million tutorials but none of the ones I've seen really address basic app design.
Now for Q1, both ways work fine but if you have buttons from the first screen, having a uinavigationcontroller might make it slightly easier if you plan to have back buttons on the screens after the first screen.
For Q2, to make the database persist when the user updates their app at some stage, simply keep the original database and include a new database (with a different name) with additional content, then modify your original database and import any additional content to it.
You can also do variations of that also, ie import content from old database to new database and etc. But the key is to keep the database file names different, ie add database_v1.sqlite, database_v2.sqlite and etc.
BTW don't forget to clean up any databases you won't use in future.
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.