Situation: my app needs to present a full screen modal view whenever it becomes active (from background) to ask the user for a PIN. All fine.
Unless: if the user previews a file using QLPreviewController, leaves the app and comes back, the PIN input controller will be presented modally from the QLPreviewController which I'm keeping a reference to. The PIN input is shown but when it dismisses, I see a checkerboard-styled background which is even scrollable. Seems to be some leftover of the PreviewController but the actual preview data is no longer shown. Any idea what could cause that?
Do I have to reload the contents of the preview somehow?
I had similar issue and I've managed to pin down the problem to either viewWillDisappear or viewDidDisappear methods. My solution was to subclass QLPreviewController and overwrite those methods with empty implementation i.e. skipping the call to super. I don't know if it's very safe, though I haven't encountered issues and it solved my problem.
Related
Background
I have a custom UIWindow implementation that posts a notification in the sendEvent method. Then I have a custom view that, once added to the window hierarchy, removes itself from superview as soon as the mentioned notification is posted (i.e. tapping anywhere, in this view or not, removes the view). Finally, I have a button that causes this custom view to be added to the view hierarchy. Now the problem is that when I tap this button, the view gets added to the view hierarchy, BUT, the event that was caused by this tap reaches my custom UIWindow sendEvent method AFTER the custom view is added, thus resulting in the custom view being removed immediately after it has been added.
Question
I want to somehow access whatever UIEvent is currently active. Is this possible to do, and if yes, then how?
I solved this by listening for the notification in order to track the most recent UIEvent (I provided the UIEvent in the userInfo). Then, when receiving the notification again, I made sure that it is not the same event as the one that occured just before the custom view appeared (if it is, I skip the removal of the custom view).
While this is an answer to my question, the solution to the underlaying problem that #matt proposed in an answer to the following SO question turned out to be much better: How can I know when any of the objects on screen were tapped?
With iOS8, I noticed that a view controller was no longer receiving a UIKeyboardWillSHowNotification, when it previously was with iOS7.
Here's the scenario:
1.) View Controller A is displaying a keyboard, and pushes View Controller B without resigning first responder
2.) View Controller B has a control that becomes first responder during its viewDidLoad call, while it's being created by VCA, before it's pushed onto the nav controller
3.) If VC A is NOT displaying a keyboard when pushing B, the notifications work fine. However, if A is still editing when pushing B, then B does not get a keyboard will show notification.
Without the keyboard notification, VC B is not resizing / repositioning and does not look right.
The workaround I'm using until I find a solution is to do the following from any view controllers that might be editing when pushing another view controller that might be editing:
i.e., before pushing another view controller, be sure to call:
[self.view endEditing:YES];
While it works, it doesn't seem good that the view controller (B) can be 'broken' by the state of the app prior to displaying it.
Question: Am I doing something wrong here?
As far as I can tell, one of 3 things are possible:
A.) I should be getting the notifications, but I'm not b/c I'm doing something wrong
B.) I should be getting the notifications, but I'm not b/c of a bug
C.) I can't rely on always getting the notifications...But if I don't get the notifications in VC B when it appears, I need to be able to get the keyboard dimensions of the displayed keyboard without relying on the keyboard notification info. All the apple docs say to use the notifications though (as far as I can find).... which points back to options A.) or B.).
I can create and upload sample code later tonight / early tomorrow to try and isolate / for you all to test/reproduce to see what I'm doing.
I can see the same issue with iOS8 / xCode6 (works with iOS7 and xCode5). In my case, I'm observing a systemStatus property on the model in my AppDelegate so as to log the user out and bring the user back to the login screen when the user logs out from anywhere in the app. I'm doing that by setting the window.rootViewController to the loginViewController in my App Delegate observeValueForKeyPath: method.
This works fine on iOS7 / xCode5 but on iOS8 / xCode6, I loose the keyboard in the way. Looks like my loginViewController might be registering for keyboard notifications (in its ViewWillAppear method) before the window's rootViewController switch is complete (in iOS8) thus registering to the old window's notification center...
I moved the registration for keyboard notifications to the ViewDidAppear: method instead and that seems to fix it but somehow this seems to be called twice for some reason.
After upgrading my project to iOS 6, I realized that auto layout is only effective in viewDidAppear and most of my code expects the view's frame to be available in viewDidLoad. This limitation renders the really nice auto layout feature almost useless for me. Is there any suggestions to help me use auto layout?
For example, sometimes the developer needs to adjust information about a subview based on where auto layout chooses to place that particular subview. The subview's final location cannot be ascertained by the developer until AFTER the user has already seen it. The user should not see these information adjustments but be presented the final results all at once.
More specifically: What if I want to change an image in a view based on where auto-layout places that view? I cannot query that location and then change the image without the user seeing that happen.
As a general rule, the views frame/bounds should never be relied on in viewDidLoad.
The viewDidLoad method only gets called once the view has been created either programmatically or via a .nib/.xib file. At this point, the view has not been setup, only loaded into memory.
You should always do your view layout in either viewWillAppear or viewDidAppear as these methods are called once the view has been prepared for presentation.
As a test, if you simply NSLog(#"frame: %#", NSStringFromCGRect(self.view.frame)); in both your viewDidLoad and viewWillAppear methods, you will see that only the latter method returns the actual view size in relation to any other elements wrapped around your view (such as UINavigationBar and UITabBar).
As told by #charshep in a comment, calling view.layoutIfNeeded() in viewWillAppear can do the trick.
Quote of his original comment
I had trouble getting a table view to appear at the correct scroll position when pushing it [...] because layout wasn't occurring until after viewWillAppear. That meant the scroll calculation was occurring before the correct size was set so the result was off. What worked for me was calling layoutIfNeeded followed by the code to set the scroll position in viewWillAppear.
Essentially I have a view controller where the user picks from three choices. Once the user chooses something, the view segues away to another view controller that displays some information regarding their choice for about 5 seconds and then segues back to original view controller automatically where the User must make more choices... (its basically a loop until something is accomplished).
The problem I am having is when the User touches their option, it seems to just segue back to itself without ever displaying the intermediary screen. I added a sleep(5); to the viewDidLoad but all that causes it to do is pause on the original choice screen for 5 seconds before segueing to itself. I also put in an NSLog in just to make sure it was actually using the new controller, which it is indeed.
I didn't include code since its so trivial. viewDidLoad on the new controller, has sleep(5) and the call to segue back to the original view controller.
I solved the problem by moving the code to viewDidAppear. Should have done that from the beginning honestly, just didn't think it through enough I guess.
I'm dealing with a weird problem: I've got a UIViewController to handle a list of items to download via inapp purchase.
When a user choses the product to buy, all the purchase flow begins. At this particular moment, I push a UILabel and a progress bar to display the current state of the download.
If, before that, a user choses to go in another part of the application (i.e. by tapping an item form the tab bar menu ), the application continues the purchasing process from there (that is reduced down to saying yes to a couple of dialog boxes and inputing the itunes store account credentials).
The process (that is attached to a background thread) runs smoothly till the end of it, but if the user comes back to the store view the UILabel and the progress bar are not show, I mean, they are initialized and running but they're not visible.
Is there a right way to behave in that circumstance?
Do I have to force the refresh of the view, or do I have to remove'em from the superView and push'em back again?
thank in advance,
hope I'd be clear enough, otherwise don't be afraid to ask, I'll be glad to
explain myself in a more deep and clear way.
-k-
Without a code it is difficult to give you the exact solution.
A possibility is that when you moved out from the original UIViewController the system did unload the view on that controller. It is possible that with this unload the progress bar and label were not destroyed (because over-retained by your view controller or not nil-ed in the viewDidUnload method) but when you entered in the view controller again the view was reloaded from scratch (typically from the nib) with new progress and labels.
So it is correct that you retained the progress bar and label (even if there are better ways to achieve the same result) but you must add them to the view controller view in the viewDidLoad method. A typical way to do this is to store a "active" progress bar in a dictionary and when the view is reloaded from the nib it must be added to it. As soon as the download finish you can remove the progress from both the dictionary and the view. There are other ways to accomplish the same result, so my suggestion is just to give you an idea.
So in order to see if my answer is correct, you must check the viewDidUnload method, add a breakpoint on it and see, once it has been triggered and when you come back to your original view, if the progress bar has disappeared or not.
Hello Holographix u havnt posted any code so it would be difficult to tell
well it seems like the object of Uilabel and progress bar are getting released the time u comes back to the view.