So the rootViewController for this application is a UITabBarController subclass. And we're having a bizarre issue where we cannot get a UITabBarController to -presentModalViewController:animated: if we're passing NO to animated. We've tried a variety of methods: -viewDidLoad, -viewWillAppear, -viewDidAppear and can only get it to work if we do it after a delay, which is hacky.
I decided to break this out into a test and found that if I have a UIViewController that calls -presentModalViewController:animated: in the -viewDidAppear method it works as expected with both YES and NO for the animated parameter. However if this VC is instead a UITabBarController, it works if animated is YES but not if it is NO.
Any ideas? Is this a bug? I've searched online and through documentation and can't find a reason that UITabBarController shouldn't be able to present a view this way.
This definitely sounds like a bug. I'd suggest you file a bugreport with Apple. If it's blocking your project, you could submit it through one of your support incidents with Apple, and if they find it really is a bug they'll refund that support incident (so you don't loose anything). If it isn't a bug, they'll be able to give you a solution.
Related
I am trying to make a simple app from a tutorial that does not have a viewController at all. All the code is in the AppDelegate. I am on xcode 4.2 and I am getting this error:
Applications are expected to have a root view controller at the end of application launch
I'm not sure how to deal with this. There are some blogs out there with fixes but none of them are working for me and I really would like to understand what is going on here. And, how to fix it.
I do have a view that contains some buttons and labels. But I have no "ViewController". The files contained in my project are: AppDelegate.h, AppDelegate.m, and Window.xib only. There is no ViewController.h, ViewController.m
** edit **
I ended up making the app from a 'view based application' instead and just moving all the logic from the app delegate to the view controller. So, I didn't really solve the problem per se. The app works now though. Thanks for the help
It's not possible to have an iOS app that doesn't have a view controller. You can always create a trivial view controller, i.e.,
[[UIWindow alloc] initWithFrame:UIScreen.mainScreen.bounds].rootViewController =
[[[UIViewController alloc] init] autorelease];
It sounds like you're looking at an old tutorial. UIWindow got a rooViewController property in iOS4. I believe it became required in iOS5 to help keep controller hierarchies and view hierarchies in sync with the addition of custom container controllers (and to fix a corner case where replacing the "root controller" of a UIWindow could stop orientation changes from propagating). There was a WWDC presentation in 2011 that explained this in some detail. I think it was Session 102, Implementing UIViewController Containment.
At then end of the day, there's no good reason not to have a root view controller. Apple wants to be able to assume it's there in their APIs going forward. If the tutorial you're looking at doesn't account for that, it's broken.
While I agree that there may be workarounds, another question to address is: why do you want an app without a view? Even if it's designed to run in the background and present no visual interface, at least make a simple view showing the application name and version, a largeish icon and perhaps a status. This kind of idle screen uses very little system resources, especially when the app is backgrounded, but improves the overall experience of the app.
If you set your deployment target to 4.3 and run on the iPhone 4.3 simulator, you won't get the warning.
To install the iOS 4.3 simulator, go to Xcode > Preferences > Downloads.
At a great number of requests from people using older iOS hardware, I'm currently refactoring and optimizing my app so it will work on iOS 3. That being said I've got a glitch with my UITabBar that I can replicate on all of the iPhone 3G units I've tested it on.
The glitch appears to have been fixed in iOS 4, but I was wondering if before that time, anyone else had this glitch as well and had figured out a (relatively elegant) workaround for it.
The problem is what you can see below; when a memory warning occurs and all of the views offscreen are released, when I bring a view controller with a tab bar back on screen, all of the UITabBarItems that are supposed to be in it are gone. As far as I can see, they're not being drawn at all; ie tapping the tab bar has no effect. After setting breakpoints and examining the UITabBar and its items in memory, they're all still there (ie not getting released), just that they're not getting redrawn when the UITabBar is re-created in the controller loadView method.
My app works similar to the official Twitter app in that I implemented my own version of UITabBarController so I could control the integration of it with a parent UINavigationController properly. I set it up as closely as possible to the original UITabBarController class though, with all of the child view controllers handling their own respective UITabBarItems and initializing them inside the class' init methods. Once the child view controllers are passed to my TabController object via an accessor method, the tabBarItems are accessed and added to the UITabBar view.
Has anyone seen this behaviour before and know of a way I can fix it? I'm hoping there's a really simple fix for this since it already works in iOS 4, so I don't want to hack it up too badly.
Thanks a lot!
After a bit of research, I think I found a solution to this. It's not the most elegant solution I was after, but it definitely works.
I'm guessing after a memory warning is triggered, something is happening to the UITabBarItem objects that basically renders them corrupt. I tried a lot of things (flushing out the UITabBar, re-creating the controllers array etc), but nothing worked.
I finally discovered that if you completely destroy the UITabBarItems and allocate new ones in their place, then those ones will work. :)
So my final solution to this was to add an extra condition in the viewDidLoad method of my controller that if the detected system was iOS 3, and there was already an array of UITabBarItems, it would go through each one, copy out all of the properties needed, destroy it, allocate a new one and then copy the old properties over to the new one.
I'm still going to keep an eye out for a better solution (I think there's a bit of overhead in this method), but thankfully at this stage, iOS 3 legacy support is becoming less and less of an issue. :)
I have been trying to make my Mac application enter fullscreen now for a while but can't get it to work. According to the Apple developer center, I should use enterFullScreenMode:withOptions: which gives me, method enterFullScreenMode not found.
Everywhere I google there seems to be people having issues with making their app fullscreen, so what is the way to make it work?
Edit:
Of course enterFullScreenMode is for the NSView and I used it on a NSWindow; it's not the view I want to have fullscreen, but the window. I can't find any function for the NSWindow though.
Lion has some new APIs for full screen.
To do it with NSWindow, do this
[window setCollectionBehavior:
NSWindowCollectionBehaviorFullScreenPrimary];
To do this with NSApplication do this
[[NSApplication sharedApplication]
setPresentationOptions:NSFullScreenWindowMask];
A bit more about it here.
Modern day Mac Os X developers (who use storyboard) need only to click on their main.storyboard, select the NSWindow (not the NSWindowController), Use the right panel to find the attributes panel (the one that to the left of the ruler, it looks like a drag-bar thing) look for "Full Screen" and select "Primary Window" rather than its default value of "Unsupported". You can also set up Auxiliary windows if that's what you want.
Don't fight the change, use storyboard. One of us... one of us...
As mentioned in the link Jonathan provided in the comments, enterFullScreen:withOptions: has a number of drawbacks that can make you want to tear your hair out. The best way to do fullscreen is still the older CGDirectDisplay API. Cocoa Dev Central has an article on fullscreen apps that covers pretty much everything you need to know.
You'll notice the article is pretty ancient and the dev tools have changed a lot since then (Project Builder! Ah, the good old days), but the code itself will still work.
[self.view setFrame:[[NSScreen mainScreen] visibleFrame]];
I am using UIViewController (a subclass of course) with a text field which sends an action when the contents changed (to the contentsChanged: selector of the ViewController). It is done by sending contentsChanged: to file's owner in IB.
But when I test it, it says : "-[NSCFString contentsChanged:] : unrecognised selector sent to instance " and the instance pointer in hex.
I am guessing that for some reason the view controller gets moved to another pointer and a string gets allocated there, but I cannot figure why.
Any ideas ?
Sounds like a classic case. Read up on NSZombieEnabled for how to track this sort of problem down.
I have the exact same problem with a subclass of UIViewController and this piece of innocuous code:
- (void)viewDidLoad
{
NSLog(#"%# %s %#", [self class], _cmd, answerButton);
[self.answerButton addTarget:self
action:#selector(getAnswerToQuestion:)
forControlEvents:UIControlEventTouchUpInside];
}
Yes, answerButton is connected (it's an IBOutlet), yes, - (IBAction)getAnswerToQuestion:(id)sender; is a proper method, but no joy. When I commented out the viewDidLoad and made the connection in IB, it showed in the crash report that the failure happens on [UIControl sendAction:to:forEvent:] resulting in
objc_msgSend() selector name: performSelector:withObject:withObject:
I can't prove it, but I suspect there's a bug somewhere in the UIKit that translates the bindings and addTarget to a call to performSelector. I'm planning to upgrade to iOS 4.01 first to see if that won't solve the problem.
UPDATE:
I'm not sure anymore that my problem really is similar to Alexandre Cassagne's but in the interest of sharing information I will not delete it just yet. I solved my problem, as so often, when I started to make an example project in order to file a bug report. Yes, clicking made answerButton call getAnswerToQuestion: like a good little object and all was fine.
The difference between the subclassed UIViewController of the example project and that of my real project was that the first also functioned as the xib's File's Owner while the second was just one of several view controller. When I moved getAnswerToQuestion: to the File's Owner in my real project, clicking answerButton worked as expected. So, my hunch that the problem lay somewhere in the translation from binding to performSelector wasn't that far off: the problem lies in the Responder Chain. I would think that establishing the Action-Target link either programmatically or in IB would bypass the Responder Chain, but apparently not.
The problem now, of course, is that Alexandre states in his question that his contentsChanged: method already is part of the File's Owner, which makes my answer irrelevant to the question.
without looking at the code, it looks like you are calling contentsChanged: on the text field's text, instead of the UIViewController subclass.
you should consider using the UITextFieldDelegate protocol to get called back when the text of a UITextField changes. I have not looked, but this is the thing I would do off the top of my head.
My iPad app was working fine until I opened up IB and started editing the interface. Now, my application:didFinishLaunchingWithOptions isn't getting called. I understand it's an optional function and it gets skipped if it doesn't exist, but in my case it does. What are some reasons that application:didFinishLaunchingWithOptions method could get skipped?
I should note that I'm building with the iPhone OS 3.2 SDK.
Thanks in advance for your help!
UPDATE: I fixed it, please see my answer below
Are you sure that class has been set as the application delegate of the app?
(source: xanga.com)
And also make sure the "File's Owner"'s delegate has been linked to "App Delegate".
(source: xanga.com)
Well it turns out, for an unknown reason, I had a "view" view object as a child of my RootViewController in IB that didn't serve any purpose except to hold my a TableView view object and a DatePicker view object. I thought it was harmless, but when I removed it in IB and programmatically added the TableView object and and DatePicker object, suddenly this problem went away. If anyone has any ideas why this is, I'd would love to understand it.
Thanks, everyone!