If I call my app using a separate activity (not the normal initial route but, for instance, by overriding getInitialRoute() in a secondary FlutterActivity), or maybe even if I have no UI at all but a plugin I call into provides a platform UI of any kind, upon returning to my code, when I want to dismiss the functionality, the root route of my Flutter app is visible for a short moment. As an example, let's consider a printing scenario:
my app receives a share intent
I catch the intent with my Android code, send it to the Dart side
I act upon the intent, which involves displaying the Android printing UI
the user finishes printing or dismisses the UI
control returns to my code
before my Flutter app goes away, its initial route displays temporarily
Item 6 happens even if I call SystemNavigator.pop() in my item 5. The app exits all right, the funcionality is OK, but the momentarily visible root page is a visual nuisance.
So, what I would practically need is a way to clear the back stack when I reach item 5 to make sure I don't return to the root, not even for a moment.
I found something in the meantime that, at least for now, seems to work. It involves several steps:
make sure you use an extra route for this activity -- this ensures that it won't be the root page but this one the navigation returns to temporarily,
make sure the route shows an invisible page, practically an empty Container() -- this ensures the page will not show anything,
start this activity with a transparent background mode (including a transparent launch theme and referencing it in the manifest) -- this ensures the page will not even re-color the background temporarily,
use SystemNavigator.pop([animated: false]) when your code returns from the foreign UI -- this ensures that the extra page will disappear in the end. Animated actually does nothing, as the doc describes (which is unfortunate, actually, it would be nice to be able to suppress it).
These all combined make sure that, although the extra page is technically present for a short period of time, it isn't actually visible and distracting to the user.
I'm still very much open to suggestions that provide a real solution rather than a hacky workaround, if possible. :-)
Related
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?
I have a page from which I navigate to another page and do something there , when I press back button, the current page simply pop and previous page keep as it is. I have to refresh it to make changes.
I want, when I make change to second page, first page should automatically get updated according to it.
You should read a little about managing state in flutter.
There are few very good ideas on how to approach this problem.
You can try with fairly simple Scoped Model.
or little bit more confusing Inherited widgets. If you ever used Theme.of(context) or Navigator.of(context) that is basically inherited widget. Just a little more harder to set up properly.
Check this amazing presentation on managing it from google io 2018
https://youtu.be/RS36gBEp8OI
I tried to develop a shopping cart application.
I am able to process the deal. but when the user click the fresh start after completing the deal the first page starts with the value which I have entered previously.
I am using gwtp, uibinders, I have back, cancel, next functionality in series of screens.
what to do to make sure the screen is blank for every new start of deal.
I don't know which design pattern you use, but usually a "view" keeps its state after it is hidden. When you show your view the second time, you have to reset the values of all fields (textboxes, inputs, etc.), or they will show their state from the previous time.
I have noticed that whenever a phone call comes in while my app is in use (Or I simulate in-call status bar using the simulator), and the phone call ends, I end up with a double status bar in my app. The status bar goes away if I click any other tab and come back to the original tab (my app has a UITTabBar in it).
I have tried so many options that I am losing track now. The most I have read are to set your UIView's size to be flexible in interface builder but nothing seems to work.
Please look at the screenshots. I am pasting a default view of the sizing options in interface builder but believe me I have tried every single configuration option there.
Do you have some heavy compute-bound processing taking place on the main thread? The main thread should be dedicated to UI updates, with non-UI stuff kicked off onto separate threads.
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.