In viewDidDisappear: of a modally presented controller I added a callback to inform who ever is interested about the view being gone (after the animation has finished) without requiring subclassing.
One of my controllers that registered for the callback is firing up a UIAlertView in there. However, once the alert is shown, its buttons don't react.
Another one is adding a subview to itself and again: the buttons of the view don't react.
The resposible handlers of the buttons are not triggered.
I assume it has to do with the fact that viewDidDisappear: is not really finished yet when it call my callback. But even if I used subclassing instead, it would be the same situation.
One explanation could be that there is still some other view covering my buttons because the clicks just don't come through.
So: Can somebody confirm that it is NOT a good idea to do what I am doing (showing an alert, adding a subview in viewDidDisappear), because then I will have to change the flow. If it should be okay, I have to figure out what else is causing this effect.
I'd put the callback into viewWillDisappear: instead. At least then the original UIView reference is still around.
Better solution would be to dismiss the modal view through the parent controller by adding the caller as a delegate. The delegate would implement a protocol to dismiss the modal controller. Call the delegate protocol from the modal view, when you are ready to dismiss.
To avoid changing the flow, you could schedule a timer to show the alert, this will give a chance to the view controller code to complete
Related
I am trying to understand modal vs push segue and read few Q & A like this and this. One point I am confused from these answers is "The presenter should take care of dismissing the VC it presented."
For example, the example I am writing shows UIPageViewController something like the example available here, with a button at bottom of the page with name "Skip".
In story board I have created a segue (of type Modal) from "Skip" button to another "View Controller" (let us say LoginViewController), but where do I need to dismiss the UIPageViewContoller (if at all required) and how?
EDIT:
After little bit more reading, it seems UIPageViewController (Which has Skip button) should take care of dismissing LoginViewController (because UIPageViewController is the presenter).
In my case, after Login complete, I would like to navigate to "Menu" page, then how can I ask UIPageViewController to dismiss the "LoginViewController" and move to MenuController? I couldn't find any example on how this works.Any help would be appreciated!
As per the tutorial link you have given in question.
There is a APPViewController which is root for the UIPageViewController and also in AppDelegate, so on top of that view, require a Skip button which is above all the subViews in AppViewController. So its IBAction event will be in AppViewController only.
Now first change your AppDelegate self.window.rootViewController to LoginViewController.
In LoginViewController viewDidLoad event, presentModal UIPageViewController.
Now in its action event of skip button, you can write like this:
[self dismissViewControllerAnimated:YES completion:nil];
So it will automatically dismiss all your AppChildViewControllers, and will display LoginViewController, which is already behind.
This is just a base logic to achieve your goal, you might require to change code as per your project implementation.
Hope this helps.
First dismiss the UIPageViewController and then using delegate or block methods (whatever suitable) to get notified when you press the skip button in the parent controller and then calling LoginViewController.
I have an iPad app that uses a UIPopover from within a UIVIew; I need to show an alert-type message when a certain condition has been met.
The problem is using a UIAlertView from within the UIPopover, when the user taps on a button in the UIAlertView, it also dismisses the UIPopover, which defeats the purpose of the alert.
I tried using UIActionSheets, but they don't display at all, probably because they are not being called from a controller-type view.
Is there a way to circumvent this behavior?
No, and you shouldn't do that. Popovers are supposed to go away as soon as you touch anything else.
You could enlarge the popover slightly and make room for a status message. When the user creates an appointment that overlaps, you could display a message in the status area.
Or, you could dismiss the popover and display an alert with "ok"/"cancel" buttons. The OK button would create the overlapping appointment, and the cancel button would discard it.
You will need some place to save the info from the popover while you are waiting for the user to decide what to do with the alert. Perhaps have the popover pass a message back to the view controller it comes from, and then have the source view controller create the alert, set itself as delegate, and handle the responses from the user.
According to Apple's Human Interface Guidelines, it is OK to display a UIAlertView on top of a popover:
https://developer.apple.com/library/ios/documentation/userexperience/conceptual/MobileHIG/Alerts.html
To quote specifically:
On iPad, don’t display a modal view on top of a popover. With the
possible exception of an alert, nothing should display on top of a
popover.
Displaying a UIAlertView from a popover does not automatically dismiss the popover. There is likely some of your own code being executed which is causing it to dismiss. For example, in a similar situation I had, I found that displaying a UIAlertView was invoking "shouldAutorotate" in my split view controller, and (due to earlier iOS bugs) I had placed code there to dismiss the popover. For iOS7+ this was no longer necessary, so I was able to move this code into willRotateToInterfaceOrientation, where it no longer causes dismissal of the popover upon display of UIAlertView, because in this case, even though "autoRotate" gets called "willRotateToInterfaceOrientation" does not.
I'm trying to determine when a UIBackButton is pressed in a sublayer of a navigation app. Would HitTest be used for that? I've seen reference to HitTest, but not exactly sure what it is and how to code for it. Any help is muchly appreciated. Thanks!!
No. Hit testing is the (recursive) process by which UIKit determines which view receives touch events. You shouldn't need to participate in it or invoke it.
If you're using a UINavigationController, it will do the right thing to transition between view controllers when the back button is pressed. If an individual view controller needs to know when it is transitioning off-screen, it should override the -viewWillDisappear: and -viewDidDisappear:. See the documentation for those methods for more information.
Must I always resignFirstResponder for a UITextView? Or, will this happen automatically when its view controller disappears?
I'm asking because I'm having an issue similar to iPhone Objective-C: Keyboard won't hide with resignFirstResponder, sometimes, where the keyboard stays up even when the nav controller pushes and pops other view controllers. The keyboard works, and when I hit done, it unfocuses the UITextView (i.e., the cursor disappears), but the keyboard stays up.
I never found out why this is happening, but maybe it's due to not doing resignFirstResponder before pushing another view controller, but I thought it was optional?
At a total guess, the UITextView has a reference to the view controller (as its delegate) but does not retain it. When you go to the next screen, the controller is dealloced and then the UITextView (which has perhaps been retained by something else) tries to call back to the dealloced controller and crashes. When you call resignFirstResponder, you reverse the order this happens, and therefore no crash.
The way round this to add a textView.delegate = nil call in your view controller's dealloc method - obviously put it before you release the text view.
The contract between a UITextView and it's delegate says that the delegate will send -resignFirstResponder when the text view is done editing. This informs the framework that the view is done editing, fires the events relating to that (willEndEditing and didEndEditing), and allows other parts of the responder hierarchy to react accordingly. Failing to do so might work, but it's not following the contract (that's all a protocol is) it agreed to.
I don't think you have to because the Xcode Sample UICatalog UITextField doesn't call resignFirstResponder before the TextViewController is popped.
The reason the keyboard got stuck for me is that I was having the same view controller present two view controllers modally at the same time, one after the other. UIKit didn't like that.
Calling resignFirstResponder makes sure that the text property contains the actual text shown in the control.
Depending on the state this is not always necessary, but if your controls have resigned first responder, you know that you're working with valid data.
I am trying to detect touches, but the touchesBegan method is not being called.
In my ViewController, I have added the touchesBegan method. My Nib files owner is set to the correct V.C. The Nib itself consists of the view, with a scroll view and a tab bar. Nested in the scroll view is an image view, which has user interaction enabled. What is precluding touches from being registered, or preventing my implementation of touchesBegan from being called?
I've scoured the Internet and Apple docs, and I can't see what I am doing wrong. Also, I'm not really sure what code I can post here to help with my query. Thanks.
Okay, after a lot more reading, I've now got a scrollview and a imageview, both of which are created programatically. The imageview is a sub view of the scrollview, and scrollview has been subclassed so that the touches ended method can decide whether it was a single touch, in which case call the touches ended method from the view controller, otherwise call its supers method. This works just fine, however, why is it that this cannot be done without subclassing scrollview? Is it my lack of understanding of how scrollview works, or is it just a limitation of it?