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.
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:
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:
I develop an iOS Keyboard extension, and I'm using scroll gestures on keyboard. Sometimes when using the keyboard I scroll up the control center and my keyboard stops working fine. Is there any way to detect if control center become visible, or invisible?
You can't do it directly. The most you can know is that your app was deactivated and then activated again. It could be because of the control center, it could be because of the notification center, it could be because a phone call came in, it could be because the user went into the app switcher and came back again...
Here is the possible work around you can try:
It is the UIWindow subclass to enable behavior like adaptive round-corners & detecting when Control Center is opened. This UIWindow subclass does probably the thing you want. You simply subscribe to an NSNotification and can react to the user opening Control Center. Detailed instructions and setup on Github
https://github.com/aaronabentheuer/AAWindow
[AAWindow: The way this is accomplished is by using a combination of NSTimer and overwriting sendEvent in UIWindow to receive all touches without blocking them. So you basically receive all touches check if they are near the lower edge of the screen, if yes set a timer for a half a second and if during this timer is running applicationWillResignActive is called you can be almost certain that ControlCenter is opened. The time has to vary if there's no statusbar, because then the app is in fullscreen and it can take the user up to 3 seconds to launch Control Center.]
Hope it would help you figure out the exact solution to your problem.
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 using simple MPMoviePlayerController. In portrait mode it is emmbedded into my layout. When I rotate my device I want it to go full screen. In full screen mode there is a done button but only thing it does is pausing the video. I want to dismiss modal view controller when the done button is tapped. How can I do this?
I've tried:
Putting a [UIColor clearColor] on a background of a button and place a button over Done button thus intercept touch event into my own selector. It failed because my custom button isn't displayed when MPMoviePlayerController is in fullscreen mode.
Going to notification center and trying to catch "willExitFullscreen" but it won't occur (pressing done button when in landscape fullscreen mode isn't goint out from the fullscreen mode).
Finding done button in the MPMoviePlayerController... but I was unable to find it.
Using MPMoviePlayerViewController isn't an option as I want to be able to use embedded player in my controller when i Portrait mode, and be able to rotate movie without loading it from scratch (so pushing new controller when user changes device orientation isn't right solution for me).
I've read a few topics on this issue and question can be the same or similar but anserws require either things I've checked (i.e. notifications) or things I can't use (MPMoviePlayerViewController).
ANSWER (as I am unable to post it in 7h)
Heh ok..
The culprit of this whole mess was this line of code
[self.mpPlayer setControlStyle:MPMovieControlStyleFullscreen];
So it seems that setting Fullscreen control style when going into fullscreen mode will break done button....
Makes no sense to me. But when I commented out this line I am able to recive willExitFullscreen notification and I can work with that.
The culprit of this whole mess was this line of code
[self.mpPlayer setControlStyle:MPMovieControlStyleFullscreen];
So it seems that setting Fullscreen control style when going into fullscreen mode will break done button....
Makes no sense to me. But when I commented out this line I am able to recive willExitFullscreen notification and I can work with that.