Is it possible that iOS have a little bug caused by the system keyboard?
I'll explain myself:
Navigation between views is fast as long as you don't load hard stuff in viewDidLoad/viewWillAppear, even in old devices.
BUT, there are two conditions where I'm getting an annoying delay:
When I show a keyboard in viewDidLoad/viewDidAppear (becomeFirstResponder)
When keyboard is in screen, and I pop the view.
It seems that while keyboard is showing/hiding, the navigation is frozen, because the delay is about the time of the keyboard's hide/show animation.
I tried endEditing(force: true), and resignFirstResponder in viewWillDisappear (when I pop a view), but didn't work.
I have an iPhone 6s, and I noticed that Whatsapp and Twitter have the same problem.
Thank you.
EDIT:
The App Store has the same problem...
Notice the delay when the back button is pressed with keyboard on screen...
Without keyboard:
With keyboard:
Related
I have an iOS 9+ app with a textView that, when clicked in, opens the keyboard and slides up with it. It slides back down when the keyboard is dismissed. So far, so good.
When the app is sent to the background while the keyboard is open with the textView on top of it, then when the app resumes the textView is sent back to the bottom behind the keyboard (after a split second), but the keyboard remains open. The scenario is explained in this other SO question.
Thanks to that question I have a watcher and can run this:
#objc func willEnterForeground(_ notification: NSNotification!) {
view.endEditing(true)
}
...and that works to hide the keyboard "almost" seamlessly.
But I really want the textView and keyboard to be exactly as they were when the app was sent to the background. What might cause the textView to go back to its baseline position? I'm running through the view controller with breakpoints and, so far, have had no luck finding anything.
EDIT: You don't actually have to send the app all the way to the background. Just starting the touch gesture to send the app to the background (dragging the virtual home bar up) and letting go will remove the textView (also removes an inputAccessoryView if there is one).
EDIT: Here is the slow motion screen recording demonstrating the issue:
I have an unreasonable delay (3 seconds) in my iOS application between the time a user taps a control and when the keyboard is shown.
To reproduce this, I give textfield #1 focus then quickly resign the keyboard with the keyboard resign button and tap textfield #2.
If I tap between the two fields without manually resigning the keyboard I don't see this delay.
I've tried debugging the app to see the program flow but I'm not good enough with the debugger to actually trace anything, I always end up in assembler.
I know that the delay happens after textFieldShouldBeginEditing returns and after inputAccessoryView returns, but before a kUIKeyboardWillShowNotification is fired. My question is, what happens between these steps? What does the program flow look like between the call of inputAccessoryView and the notification for UIKeyboardWillShowNotification?
I believe that if I could just figure out what IOS is executing in this delay I could come up with a work-around.
I honestly believe this was an IOS 8 problem. After changing the target to 9.3 this issue seems to have all but disappeared.
I created an iOS 7 passcode replica and I have this problem I can't seem to solve. I need the lock screen view to be on top of everything else, so the app is covered in iOS' multitasking view, so I add it directly to the keyWindow. Everything fine so far.
The problem arises if there's an alertView or actionSheet (will only mention alertViews in this post, to keep it simple) open when I have to display the lock screen. It has been answered several times that there are no references to alertViews in iOS 7, which is true, and the window in which they are displayed is _UIModalItemHostingWindow, which has 2 UIViews, indeed with no reference to the alertView.
This _UIModalItemHostingWindow also becomes the new keyWindow, so it's on top of everything else, but it can not be found in [UIApplication sharedApplication].windows meaning if I add the lock screen to my former keyWindow (the default keyWindow, if you will), it will be beneath the alertView and its dimmed background, so the user can't interact with the lock screen before dismissing the alertView. The other option is detailed a bit further below.
The lock screen works like this: on applicationDidEnterBackground it checks if the passcode is enabled; if it is enabled and the passcode duration is 0 (user selected to lock the app immediately), it adds the lock screen now, so it covers the app in the multitasking view. Now, the option I mentioned above is to add the alertView to this _UIModalItemHostingWindow window, but when returning to the app, the lock screen view is displayed with a 1+ second delay (even though I added it before I went to background!) and the app isn't covered by anything in the multitasking view. (Currently it's displayed in the wrong position too, if you go ahead and download it, that is fixed, but I didn't pushed the commit yet).
I tried hiding and removeFromSuperview this _UIModalItemHostingWindow, but when coming back to the app, the alertView animation still runs as if it was just fired. I suspect the delay mentioned above also happens due to how Apple handles alertViews when coming back to foreground.
I also tried creating a new window and to make that the new keyWindow, but same thing happens.
Here's a small discussion about this, covering all the stuff I tried, maybe I missed something in this post.
https://github.com/rolandleth/LTHPasscodeViewController/issues/16
Any ideas? Except creating manual references to every alertView and actionSheet inside my app, because I'm trying to find a fix for the passcode library, not my own apps; I can find dirty workarounds for that, no problem :)
Update: The window is _UIAlertOverlayWindow if an actionSheet is used instead of an alertView, but it behaves the same as far as I can tell.
The simplest solution is to have a lockscreen window instead of a lockscreen view.
Create a new UIWindow, set its frame to UIScreen bounds, put a simple rootViewController there that should handle rotation and display your "lock screen" views and set the windowLevel to UIWindowLevelAlert + 1.
Then set window's hidden to YES. Whenewer you want to show the lockscreen, just set hidden to NO.
I guess that adding a view to keyWindow also doesn't work when a popover/action sheet is displayed and also when a keyboard is displayed (keyboard has its own window on top of the key window).
I'm implementing drag-keyboard dismissal (like in the iPhone Messages app) manually because UIScrollViewKeyboardDismissModeInteractive doesn't seem to work with a text view inside a toolbar above the keyboard.
It works in portraint mode, but in landscape orientation, sometimes when I animate the toolbar (which is actually just a UIView) & keyboard, they freeze. But, they did animate because I checked using breakpoints that the animation code ran and when I tap on the screen where they're supposed to be, I get the correct reactions (like keyboard keys pop up, etc.).
I'm using the old style of animations beginAnimations:context: because this is how to mimic the keyboard animation in iOS 7.
This seems like an iOS SDK bug. How do I fix this?
I was sometimes (when the pan velocity was large) using UIViewAnimationCurveLinear instead of the curve from the keyboard notification's userInfo. I took that condition out so that I always use the curve from the keyboard notification's userInfo and things seem to be working fine now.
The default behavior for the UIActionSheet used to be that touching the background did not dismiss it, and in fact did nothing. But with iOS 7 touching the background is equivalent to pressing the cancelButton.
I'm modifying some software that needs to be kept to the iOS 6 behavior. How can I keep touches of the background from dismissing the action sheet?
You can achieve this by not using a cancel button.
Check this SO post:
UIActionSheet in iOS7 dismissing when user taps ANYWHERE on the screen on iPhone