I have a scenario where I present a modal view controller from the main window's rootViewController. While it is loading the contents of this modal, I am switching to another loading window which I make key and visible.
This window acts as a loading indicator and does not allow the user to interact with the app. When it is done loading, I switch back to the main window by making it key and visible. When I do this, the modal is force closed and the app is no longer able to present modals.
Interestingly enough, if I execute [UIWindow makeKeyWindow] when switching back to the main window, there are no issues. [UIWindow makeKeyAndVisible] is what's causing the issue. Is [UIWindow makeKeyWindow] an acceptable alternative?
This is iOS 5 only. No issues in iOS 6. I am not supporting iOS 4. Does anyone know what might be happening here?
I got the same behaviour, and as documentation states that makeKeyAndVisible method is a convenience method it seems to me legit to substitute makeKeyAndVisible call with working code:
[window makeKeyWindow];
window.hidden = NO;
Have no idea what's wrong, but it looks like a bug.
It is definetly bug in iOS 5 UIWindow implemetation. I faced this strange behaviour and Aleksey's answer is the way to go.
Related
I'm working along with the book Beginning iPhone 3 Development, and am running into some issues on the "Pickers" app. I'm using Xcode 4.2, and I set it up exactly like they have it set up in their source code. All the code is the same, and all the outlet connections are the same. But, when I run my version, it launches a black screen, and the debugger says "Applications are expected to have a root view controller at the end of application launch."
There version in the source code runs just fine, and mine looks identical to it, but for some reason mine just won't run. I've Googled this issue and people have a bunch of workarounds, but I feel like there is something really simple in IB that I'm not seeing.
Any help would be great, thanks.
The iPhone 3 book is probably having you add the view of your view controller as a subview of the window, correct? Well, since iOS 4, UIWindow now has a rootViewController property and setting this property to your initial view controller is now the preferred way to get your first view controller on screen.
Basically replace something like this in -application:didFinishLaunchingWithOptions: in your application delegate...
[self.window addSubview:viewController.view];
with this...
self.window.rootViewController = viewController;
Quite a bit has changed since iPhone OS 3; beware as you proceed through the book.
Do you have the RootViewControllers XIB-file? And is it connected to the RootViewController Class (in designer)
I have a nice little app on the app store that does pretty well for itself. Life was great until iOS 5 came to town. Now, I have a number of issues with my app that I have no way of fixing because I have no clue what is going on, because I feel that they are iOS 5 issues, not mine.
Was there an iOS 5 conversion manual I missed? Or did they just change everything for fun, and want us to figure out where all the easter eggs were?
Here is another issue I am experiencing (that I have wasted so much time trying to fix), that DON'T EXIST AT ALL when I simply say that I want to run the app in good ol' 4.2:
Modal view
My app is a simple reader app. I have a book reading view that displays text with a UIWebView. One of the features I have been working on involves the ability to take notes as you read. This is achieved by hitting a button, and presenting a modal view. Yes, a modal view. The most simple pre- iOS 5 thing you could possibly do. Now, when I dismiss my modal view, just by hitting cancel, and simply dismiss the view, when I get back to my reader view, the navigation bar at the top is pushed up half way off the screen! This doesn't happen in 4.2, but there it is in iOS 5!
What can I do to get this issue resolved?
Thanks for your help.
Ok, I was just able to figure out what in the blazes was going on. I had the shouldAutorotateToInterfaceOrientation value set to a BOOL variable, so that when the modalView was coming back, it didn't know the state/size of the status bar. Fixed that, and the problem disappeared.
I have the feeling it has something to do with the way you present and dismissing the modalview. Apple introduced a new method to present views. May you try using theses instead of the old ones and see if it fixes your problem.
So here is what you do:
change this method:
presentModalViewController:animated:
into the new preferred method introduced with iOS 5:
presentViewController:animated:completion:
Depending if you are using dismissModalViewControllerAnimated:to dismiss your view, change it into dismissViewControllerAnimated:completion.
This methods also have completion handler which is very useful to do some extra work after the view has been presented/dismissed. Maybe that also helps with your other issue. Let me know if that might helped.
A major change in iOS 5 is that the navigationController property of UIViewController is no longer set for modal views. Instead, there is a new (not present in iOS 4) parentViewController property. So where you're using navigationController in a modal view you need to change the logic to something like:
UIViewController* parent;
if ([self respondsToSelector:#selector(parentViewController)]) {
parent = self.parentViewController;
}
else {
parent = self.navigationController;
}
(That's from memory, so I can't guarantee that every t is dotted and every i crossed.)
I was seeing this same clipping problem.
I found out that the reason for my issue was that I set the content size within the modal dialog (something I did for my iPad layout), so removing these two lines seemed to fix the issue:
CGSize size = CGSizeMake(320, 480);
self.contentSizeForViewInPopover = size;
I thought the problem was fixed but it wasn't. After reviewing the code some more, cleaning the build, and retesting it turned out to be a shouldAutorotateToInterfaceOrientation which would return NO for all orientations, for a brief amount of time (flag == NO) while the app is loading (root controller). You want to at least return YES to one orientation like so:
- (BOOL) shouldAutorotateToInterfaceOrientation:(UIInterfaceOrientation)toInterfaceOrientation
{
return !self.flag ? UIInterfaceOrientationPortrait == toInterfaceOrientation : YES;
}
I have some code that works fine on my iPod Touch running some 4.0-series iOS as well as the simulator that comes with the iOS SDK 4.1. But when I call [UIViewController dismissModalViewController:] on an iPhone 2 running iOS 3.1.2 it get an infinite recursion, eventually crashing.
I have a view controller that opens a table view where the user selects a document to open. Upon selecting a document my table view controller's delegate calls the parent view controllers dismissModalViewController method. I think it is because I'm closing the view controller whose code is running that causes this.
dismissModalViewController is documented to be available in iOS 2.0 and later.
How can I close the UIViewController that's open from its own code?
I figured my problem might be heap corruption from some previous code. A way to debug that is to comment off snippets of previous code to see whether the bug would go away or come back. Almost immediately I found that I was calling dismissModalViewControllerAnimated: on the current view controller's parent controller. Why that works in iOS 4.x I have no idea. The problem I face is that I have two modal dialogs that I need to close simultaneously, which I cannot get working, but that is a different question.
I'm doing the following:
[self.parentViewController dismissModalViewControllerAnimated:YES]
This code fails using the Simulator but works with no issues on the phone itself. The Simulator's console shows no erros. I used NSLog statements to pinpoint this line of code as the culprit. When running on the phone, however, the console(window>organizer) shows that the above code is executed and the application proceeds forward with no problem.
When running the code in debugger, the following statement appears at the bottom of the Xcode debug window:
GDB: Data Formatters temporarily unavailable, will re-try after a 'continue'. (Not safe to call dlopen at this time.)
Then a window dispalys stating: Loading 43672 stack frames. (that sounds bad)
In the debug window the following line appears numerous times:
[UIView(Hierarchy) _makeSubtreePerformSelector:withObject:withObject:copySublayers:]
Without getting too deep into my code, does anyone know about or have experience with this type of condition?
Thanks
Why you don't just call [self dismissModalViewControllerAnimated:YES]. It is quite enough to close you modal view controller.
I know, it isn't answer for your question, but maybe it helps to avoid your issue.
I think where you are calling this from is key but you don't say where this code is.
I suspect that dismissing your parentVC is causing this code to get executed again, which tries to dismiss the parent again... basically an infinite loop.
Thanks for the responses.
Aleksejs - I've tried your suggestion with no success. Thanks for making sure I've done the obvious first.
progrmr - I think you are probably correct - when and where I dismiss the modal view is the key and I'll look into how I'm doing this. I may need to re-architect how I'm handling my views.
This is frustrating because the issue does not happen on the iphone itself, only in the Simulator. And, I just confirmed that with the same MacBook Pro the error does not present itself in the Simulator when I'm working from home - the problem only occurs at my office. Strange, eh?
I'll keep digging and report my findings.
Thanks again.
Update - I didn't solve the problem but instead avoided it by re-structuring things. Before, in applicationDidFinishLaunching:, I presented a Login view controller as a modal view. I then need to display a EULA view controller so the user can agree to some legal stuff. I think my problem was that I was presenting the EULA view as a modal from the Login view (which is also modal). The order in which the modals were being presented/dismissed, I think, was the problem (as progrmr had suspected).
How I avoided the issue? I took the time to learn about the delegation pattern. Now, each modal view (Login and EULA) are presented within the app delegate class and I use delegates to callback when certain actions are taken on the modal views.
You shouldn't use self dismissModalViewControllerAnimated if self doesn't actually have a modalViewController. Just create a protocol that delegates the dismiss from the modal view controller back to the parent. when you push the modal view controller, assign the delegate, then when you want to dismiss it call [self.delegate dismissMe] which in turn calls [self dismissModalViewControllerAnimated:...] on the delegate (the parent).
[[Picker presentingViewController] dismissViewControllerAnimated:YES completion:nil];
Instead of
[[Picker parentViewControl] dismissModalViewControllerAnimated:YES];
and
[self presentViewController:picker animated:YES completion:nil];
Instead of
[self presentModalViewController:picker animated:YES];
I have a window within an iPhone application, which is displayed modally to allow the user to enter their settings for a web service upon 'first run'.
The text fields have helper text set, and when you tap them the keyboard shows and allows you to enter text.
Unfortunately the text fields do not clear the helper text, show the edit caret or show the text being entered (as in the screenshot below).
Any suggestions?
The window is being displayed with [self presentModalViewController:<controller_name> animated:YES];, which may or may not be the cause of this issue - when I run the UI via the Interface Builder 'test' application the text boxes respond like normal.
Clear when editing begins has been set for both fields.
Thanks in advance!
Edited: More information
After the info Bart Gottschalk provided I thought I should add some more information. First, the application is a Navigation Based Application.
Secondly, the test app Bart recommended worked fine, so that takes the modal window and the view out of the equation.
Third, I was presenting the modal view when the -(void)viewWillAppear... delegate method was being called - which may very well be the wrong place... however I'm not 100% sure if I should be presenting the modal view from within the didFinishLaunchingWithOptions of the App Delegate...
(this is happening on Simulator and iPhone 3.1.3)
In Interface Builder did you check the box for "Clear When Editing Begins"? With that checked the text field should clear any value once the use taps to edit which is the behavior I think you're looking for.
You can also set the same property programatically using clearsOnBeginEditing if that is convenient in your code.
My guess is that you've done this and it's not behaving as you expect. Just checking on this as a first step in helping you debug.
Also, does this happen in both the Simulator and on a testing device?
Bart
Edited Below...
This seems strange. Let's strip away everything but the basics of presenting a modal view when the application starts and see what happens.
I've recreated the most basic app (that I know of) to test presenting a modal view controller at launch and verify that field editing works fine. What happens for you when you do the same/similar in a new project?
Here is what I'm doing:
1) Create a new view-based app in Xcode called "ModalViewTest"
2) Create a new UIViewController with xib called ModalViewController
3) In ModalViewController.h add a method
-(IBAction)closeModalView;
4) In ModalViewController.m add the method implementation as
-(IBAction)closeModalView {
[self dismissModalViewControllerAnimated:YES];
}
5) In the ModalViewController.xib create two text fields and set the placeholder text for each to abcd1234 and confirm that "Clear When Editing Begins" is checked.
6) In the ModalViewController.xib add a button "Close" and set Touch Up Inside to fire "closeModalView"
7) In the application delegate (ModalViewTestAppDelegate) add the following import
#import "ModalViewController.h"
8) In the application delegate (ModalViewTestAppDelegate) applicationDidFinishLaunching add the following after the line containing [window makeKeyAndVisible];
ModalViewController *modalViewController = [[ModalViewController alloc] initWithNibName:#"ModalViewController" bundle:nil];
[viewController presentModalViewController:modalViewController animated:YES];
9) Save everything
10) Build and Run this new app
Does editing of the text fields work as expected? If yes, what is different about how you are building and presenting your modalView? If no, then we'll need to dig further to determine what is going on in your environment.
Second Edit Below...
When creating a navigation-based application I did the following to present the modal view at application start. Does this work for you in both your test app as well as your real app?
- (void)applicationDidFinishLaunching:(UIApplication *)application {
// Override point for customization after app launch
[window addSubview:[navigationController view]];
[window makeKeyAndVisible];
ModalViewController *modalViewController = [[ModalViewController alloc] initWithNibName:#"ModalViewController" bundle:nil];
[navigationController presentModalViewController:modalViewController animated:YES];
}
Well, I just figured it out, but honestly without the persistence and awesome help from Bart it would have taken much longer and been much more frustrating.
It turns out the problem was that I was using a Window instead of a View in the XIB file. This was why when showing the modal view within the Navigation controller it wouldn't display properly (i.e. only a white screen) and why the UITextField would not work properly when showing the view from the RootViewController.
So, to recap - modal views should have UIView, not UIWindow in the XIB/NIB File.
Thanks for your help Bart!
I have the same problem but in iOS7 only. I solved it by changing the tint color of textField to blue in the Storyboard