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
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:
In my app when home button is pressed and later the app is put back to the foreground, there is always grey box instead of the system keyboard. No matter what UITextField is pressed, this grey box always appear until the app is killed and started again.
Before entering background, [UITextFiled resignFirstResponder] is called for every UITextField.
I have also tried some other solutions like:
- (void)applicationDidEnterBackground:(UIApplication *)application
{
[self.window endEditing:YES];
}
The issue is present even if no resigning is done, simply every entering to background will break the keyboard.
The grey area do not react on touches, all touch events are sent to views below, like there was no grey box at all.
On iOS7, there is no problem. Could it be some iOS system bug?
Thanks for help.
Example screenshot:
http://i.stack.imgur.com/DpVMr.png
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).
The Sharekit's initial UIActionsheet displays the items Email, Twitter and Facebook and Cancel on Iphone
However the same code ported to Ipad now the Cancel option is missing on its UIActionsheet.
why is that.
Are you using the action sheet in a popover? The standard dismiss interaction for a popover is touching outside of it. There is rarely a "cancel" button in a popover action sheet, and Apple's HIG recommends against it.