I have a page-curl modal working. But I need to be able to track when the user hits the page curl to close the page so I can see some vars. Is there an event I can listen for or some delegate where I will get a call to tell me of this event?
Many Thanks
-Code
You'll see a lot of advice around here advocating the use of performSelector:withObject:afterDelay: with a small delay to take action after the dismissal of modal views, but I think there may be a better approach.
Generate the notification yourself. If you control the view that's being presented modally, use the viewDidDisappear: method in its controller to generate an "I was dismissed" notification which you then subscribe to in your main view controller (or somewhere else). viewDidDisappear: is called after the page uncurl animation completes upon dismissal of the modal view.
In the worst case, where the view may be presented modally or otherwise, you can keep state on the presenting view controller to ensure that the notification actually corresponds to a modal view dismissal.
For completeness' sake, viewWillDisappear: is generated when the page decurl transition starts.
Related
New to iOS, kindly bare if the question is very basic? When I press the tab button multiple times, it is not invoking viewWillAppear function? If I am wrong, then which function gets invoked, each time a tab button is pressed being on the same tabview?
You are correct, viewWillAppear is a little special, it is usually called automatically but in some cases including when you are adding a view controllers view manually (view addSubview:), and also when adding this as a view controller to a UITabViewController it doesn't get messaged.
This however is only for the root view, as you navigate (maybe with a navigation controller) back and forth, that root view's viewWillAppear will get triggered as some point.
In short, if you need to implement something in viewWillAppear in these cases, you should message it yourself when you know it's going to be presented. You can handle this case in your view controller, check out the following article about the matter:
http://www.touchthatfruit.com/viewwillappear-and-viewdidappear-not-being-ca
Good luck.
I've implemented workflow that uses a table view and a detail view with a navigation bar. I have been using the viewWillDisappear: message on the detail view to save the user's work, which I like because it makes sense intuitively, but it also gives the chance to set a cancel flag if the user wants to discard their work.
However, when I add the ability to take a picture to the workflow, it means that the viewWillDisappear: now is called both when the user goes back to the table and when going to the camera view. Is there a technique or method I can implement to make it so that the user's work is saved when going back to the table, but half finished work isn't saved when going into subviews?
You can check if a the detail view is being popped in the viewWillDisappear: method. The solution would be something similar to the answer to this question:
viewWillDisappear: Determine whether view controller is being popped or is showing a sub-view controller
I am experimenting with the splitViewController, introduced for iPads and am stuck at a point. I have a button on my detail view of the splitViewController, clicking on which a modal view opens. Now I want to change the positoning of UI controls on the detail view when the modal view gets dissmissed.
A pretty obvious way of doing this would be to catch the view transition in the ViewWillAppear method of the detailView. But it's not being called in this case. I remember facing the same problem in tabBarController where [tabBarController viewWillAppear:animated] was needed to be set before viewWillAppear of views in each tab item got called. I tried doing this with the splitViewController as well, but this doesn't seem to to work.
Any Ideas??
If the positioning is required due to an action that occurred in the modal view, you should use an explicit delegate callback. That will allow you to clearly specify the control flow and resulting behaviour of your app.
You should then define a protocol that has specific methods that carry pertinent information about the action taken. When the action occurs in the modal, perform the protocol method on the delegate, and it can react to that event (for you it seems to be a re-layout of button positioning).
To get an idea of the methods that are abstract enough to handle generic modal behaviour, look at UIAlertViewDelegate protocol. Here the delegate will get an alertViewCancel: message when the user decides to take no action, or alertView:didDismissWithButtonIndex: when they selected one of the options presented to them.
That is a good start for how to define the protocol.
If you need a many view controllers to react to the action taken in the modal, say a Sign In modal, then a better mechanism is notifications.
I'm starting to go a little crazy with this one.
I have an iphone application with a somewhat complex view structure it is a tabbed application with either a view controller or a navigation controller on each tab.
The main controller for one tab uses the viewDidAppear callback to reload any data that has been modified since the last time it was displayed and this behaves fine in most cases. The issue I have run into is that when I navigate in subviews(within the same tab) using the standard navigation controller push/pop mechanism the viewWillAppear and viewDidAppear on the main view always fire when I navigate back to it.
However if I load a modal view controller and then dismiss it, the viewWillAppear continues to fire but the viewDidAppear stops firing.
I am almost certain that this is tied to the need to manually call these callbacks on the modal controller but I cannot find the reference info on how to do this correctly. (I only see this viewDidAppear bug on the hardware, in the simulator it works as I'd expect)
If you need further clarification let me know and thanks for any input.
Yes, this is how it works. You are better off switching to using viewWillAppear.
This has the added advantage of updating the data before the screen is redrawn.
viewDidLoad should be used for one-time setup operations:
Setting titles
Instantiating subviews, content arrays
Anything else related to the infrastructure of the view in question
After that, use viewWillAppear: to do anything related to refreshing data. You shouldn't have to call any of the viewDid/viewWill methods manually – that's handled by the innards of UIView. viewDidLoad won't fire after you dismiss a modal view controller because, more than likely, the view never unloaded. viewDidLoad fires fine when you're navigating the a view controller stack since the new views need memory, requiring other views to unload, then be reloaded when they reappear.
I have View A, when the user clicks a button I pop up View B. When the user dismisses View B, and we return to View A I would like to refresh a label on View A, but is there an event that I can use to detect that we have returned to View B? I know that ViewDidLoad doesn't fire again.
I'm confused about the views in your question, but you might look into the NSNotificationCenter.
In this case, you would post an NSNotification event when the user dismisses View B.
Views A and B can register with the notification center to listen for this dismissal notification, calling a selector (method) when this notification is heard.
In this method, you might update a label's state or do anything else that involves updating the application state.
Likewise, you might post a notification when View B is popped-up, and have other classes register for that notification type.
More information about NSNotificationCenter is located on Apple's documentation site.
It sounds like you may be referring to UIViewControllers, rather than UIViews, correct? In that case, you can use -viewWillDisappear: (BOOL) animated and -viewDidDisappear: (BOOL) animated to determine when your viewController is-about-to-be/was-just-dismissed. These should be implemented on View B in your example. If you want to find out when View A is visible again, you can use -viewWillAppear: and -viewDidAppear.