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.
Related
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. :-)
I want the address bar to disappear on the iPhone. So far I have used:
window.scrollTo(0, 1);
This hides the address bar when the page is first loaded.
Then I have
document.body.addEventListener('touchmove', function(e){ e.preventDefault(); });
This prevents the user from scrolling back up to the address bar (or anywhere else) while still allowing buttons to be tapped.
But, the address bar still appears when I tap the top of the page. Not sure if this is because I am touching the top of the webpage or because I am touching the bar with the clock and battery.
I'm guessing that the user himself would need to set this option on his phone, although it would be nice if I could control it via the webpage. Is either way possible?
Why? I want to make a web app for a disabled child who has a hard time controlling his movements. I essentially want to turn off any touch actions that aren't related to the web app itself. Otherwise he will accidentally set off lots of unwanted actions. Not sure if this is possible.
I'm afraid you can't hide the status bar. For example in iOS 6 you can, in landscape mode, go full screen, it hides the status bar, but there is a new button at the bottom right of the screen to leave the full screen mode.
What you are asking is not achievable within Safari. But you can develop a simple application full screen (no adress bar, no buttons, no status bar) with a simple UIWebView. This way there will not be any unwanted action.
Basically my app loads two RSS feeds - a blog feed and a twitter stream. These are in two different views in a tab bar controller. There is also a Home view which is the default view when the application launches.
Ok, so basically when you go from the Home tab to the blog or twitter tab then it takes a while to load. Fair enough, its trying to download everything off the internet.
My question is, while the user is on the home page is there any way of "preloading" the other views so that the viewDidAppear function is already run?
Or, maybe a way of having a "loading" screen, because at the moment it seems like the application has just crashed when you click on a tab, the tab doesn't even highlight until it has loaded the view.
Thanks a lot guys.
IMO it's not a good idea to preload the views themselves. But it might make sense to preload the data from the home screen (at least when you're connected to WiFi). To do that, decouple the loading code from the view, e.g. by moving it to a separate model class.
In general, you should implement all your network connections asynchronously to avoid freezing the UI during these operations.
I have a very specific application design that I'm trying to figure out how to create with iOS 4.
Here's how it works:
The user selects an installed data set, or triggers a data set download.
The user provides a key for decrypting the data set.
A tab bar is shown with different search options for looking at the data. There are more searches than fit on the tab bar, so there's a More item and an Edit button. (Thanks, Apple!)
The searches provide different options, some requiring an additional screen for setup.
Once a search result is tapped, the user sees details. They can usually tap deeper into the result.
The tab bar stays visible as users look at details, letting them start a different kind of search. Tapping a search takes them back to step 3.
If at any time the device goes to sleep, the data must be locked. This is a hard requirement, despite may efforts to remove it. So at the moment, I'm returning to step 2.
I've implemented this in iPhone OS 3.1 with a UINavigationController for steps 1 and 2. The app pushes a UITabBarController with each tab represented by a UINavigationController for step 3, hiding the navigation on the outer controller. The user then operates within this UITabBarController. For a lock, I just pop the tab controller off the navigation controller.
It mostly works in iPhone OS 3.1, but it's fragile and hackish. There was no good way to change the data set, but the user could just close the app. With iOS 4 this workaround is gone! The only option I see is returning to step 2 on a supsend/resume, which is going to be a terrible multitasking experience.
How should I be doing this?
The tabs don't make sense until the data set is opened and unlocked.
I (and my users) really like the single tap (no matter the depth) to start a new search.
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.