I made a project with MonoTouch 5. After upgrading to MonoTouch 6 my UIViewControllers are not auto-rotating anymore. These are hosted inside a tabviewcontroller. I get this warning:
ShouldAutorotateToInterfaceOrientation(MonoTouch.UIKit.UIInterfaceOrientation)' overrides obsolete member `MonoTouch.UIKit.UIViewController.ShouldAutorotateToInterfaceOrientation(MonoTouch.UIKit.UIInterfaceOrientation)'. Add the Obsolete attribute to ShouldAutorotateToInterfaceOrientation(MonoTouch.UIKit.UIInterfaceOrientation)' (CS0672)
But the method still gets called when I am debugging. The new ShouldAutorotate never gets called. Any ideas? Thanks!
There can be a few reasons. One of them is that you should be (if not already) setting the RootViewController in your AppDelegate (another link here). That was not required before iOS6.
Another one is starting to use the new iOS6 API, without keeping a fallback for earlier iOS versions. That would match your comment, i.e. works on 6.0 but not on 5.1.
Note that since you're still targeting iOS 5.x you can safely ignore the obsolete warnings. iOS 6 introduced new API to handle rotation but it will automagically fallback to the old API to keep compatibility with existing applications.
That also means that if you start using the new (iOS6 only) API then you'll need to handle the old API yourself or rotation won't work with iOS 5.x.
Honestly I think that's a testing nightmare - you're better off letting iOS handle this and keep a single code path to handle rotation. That why I strongly suggest you to keep using the older API until your deployment target minimal version becomes iOS 6.0.
I had the same issue after upgrading and I got the answer to my problem over here. Here is the heart of the problem, quoted from the link:
Application windows are expected to have a root view controller at the end of application launch
So if previously like me you have this in your FinishedLaunching(UIApplication app) method in main.cs:
window.AddSubview(mainVC.View);
Replace it with this:
window.RootViewController = mainVC;
That's it! Happy days! Rotation works again. :) At least it solved the problem for me.
I don't know whether this small thing causing the application to go wrong is Apple's fault or Monotouch/Xamarin's fault, but I think that the Xamarin team should do something about this. Surely this is something that could be detected and corrected at compile time?
Anyway. Hope this information saves other people the hours that this issue has cost me!
Related
We've came onto this strange bug in our project (I hope it's a bug not just our fault). Let's jump straight into the problem.
Our application is Storyboard based, of course it connects to the external API etc. But we've faced this strange thing that regular implementation of prepareForSegue: and things related to segues automagically delegates things to other threads. Just a small example - when I do NSLog(#"Sample log") in viewDidLoad it doesn't get fired when it should but it gets called in the random time that's why I guessed that something might get delegated to the other-than-main thread. Firstly I thought that the networking layer may cause this because of blocks and so but even when I put direc logs into the application they get called in a random time! We've tried to check the thread in debugger and it shows us thet everything happens in the main thread. Strange, right?
Anyway, my colleagues check this against the different versions of Xcode because on my machine there are bothe 6.2 and 6.3 Beta. When we compile this on a computer with only 6.3 installed everything works properly! Is it possible that 6.3 Beta introduces some changes which handles segues differently than previous versions? Or maybe we should start seeking for the troubles some oher place?
All of the questions I can find relating to viewWillRotate and iOS8 (this for an example) explain how the viewWill/DidRotateToInterfaceOrientation methods have been deprecated and should NOT be called on iOS8. However, I'm observing that it IS being called, in an app built using XCode 6.1 and running on the iOS 8.1 simulator. What black magicks are afoot?
In fact, from the call stack it looks like it's being called from viewWillTransitionToSize:withTransitionCoordinator, which is... I mean it's nice of iOS8 to decide that it wants to pander to my out-of-date code, but I'd rather it didn't go deviating from the spec whenever it feels like, thank you very much.
Has anyone seen something like this before, and have any idea why it could be happening?
If a method is deprecated that does not necessarily mean that the method will not be called. A feature can be deprecated because it has been superseded by some other functionality, and that may mean that it still works, just not reliably or in all cases.
I have an old app I maintaining. The app was first compiled on XCode 4.2. If I take the exact same project that works find and compile it on XCode 4.6 I'll get weird bugs such as ViewControllers not refreshing, Back doesn't work as it should etc'. If I'll take the same project and recompile it on xcode 4.2 on my other machine everything will work fine. Before I'm digging into the code, can someone give me an idea why something like this may happen? My main suspect is the Base SDK of each Xcode. Does that make sense?
I couldn't tell you if there will be a difference between 4.2 and 4.6, but historically the iOS frameworks on the device (and, to a lesser degree, the simulator) do adapt slightly depending on what version of the SDK an application was compiled against. You can't rule it out.
A classic (though now ancient) example is backgrounding. Apps built against older SDKs were quit when the Home button was pushed, rather than getting the newer behaviour. More recent (but subtle) examples have included several changes to table views and changes to device rotation.
You should not attempt to build with an older SDK using a newer compiler. Apple doesn't support that kind of configuration. You should always use the latest SDK. And you wouldn't want to pretend these problems don't exist, anyway: The bugs are real, they were just hidden before.
It's unlikely that you won't be able to fix those bugs in such a way that the older versions of iOS continue to function (though you may discover it opens a can of worms that you decide isn't worth fixing for older OSes).
I've been search around how to setup panoramaGL for a whole day and none of these answers my questions. emm, maybe that's because I am new to ios developing and I start with ios5 with all ARC cool features. I did find a pretty comprehensive guide at http://www.codeproject.com/Articles/60635/Panorama-360-iPod-Touch-iPhone but it's a little bit out of date to me. I cannot follow this guide in xcode 4.3 with ios 5.0 sdk.
Emm, so here is the question, assuming panoramaGL and helloPanorama works perfectly fine in whatever xcode version and sdk version it is created in. Is there a way , without any code modification, I can import the library and using the api along with my app developed in ios5? Of course I don't mind some minor modification and I did dive into those code and comment all the retain or release stuff. but wired errors keep popping up. I really need help here.
If it finally turns out to be impossible to reuse it in ios5.0, I will probably need to write the whole thing line by line with my understand of the complicated panorama algorithm...
Thanks so much for the help!
It seems someone is working on another library based on panoramaGL. Works on IOS 5.
See http://code.google.com/p/tk-panorama/
The new version of PanoramaGL 0.1 r2 was released, please check http://code.google.com/p/panoramagl/. This version runs on iOS >= 4.x and supports Hotspots.
Please check HelloPanoramaGL example
Working on a weird setup where my main development machine is running Snow Leopard (and thus, just has iOS 5.0 SDK) and also have a laptop running Lion (and 5.1SDK). Wish I had a simple solution to be able to develop 5.1 on the Snow Leopard machine, but that's a side issue.
I'm learning UISplitViewControllers, and wanted to have a swipe gesture to change what's being shown in the detail view controller. Implemented that, but in 5.1, there's a property called presentsWithGesture that reveals the masterViewController when you swipe that direction.
You can disable it, but my 5.0 machine gives me an error saying (correct for 5.0) that UISplitViewController doesn't have a property named presentedWithGesture.
Sigh... so I thought I'd test for it, but the following:
if (self.splitViewController.presentedViewController) {
self.splitViewController.presentsWithGesture = NO;
}
... still gives me that error. Is there a clever way to get around this? Some voice in the back of my head says "categories," but I'm unsure where to start.
Thanks in advance for your help.
This is the way to check if theUISplitViewController has the presentsWithGestureProperty:
if ([m_splitVC respondsToSelector:#selector(setPresentsWithGesture:)])
[m_splitVC setPresentsWithGesture:NO];
In iOS 5.1 it will set the property and in previous versions it will not enter the if statement.
You should ask the splitViewController if it can receive the message presentsWithGesture.
if ([splitViewController respondsToSelector:#selector(presentsWithGesture:)]) {
//edited away from dot syntax
[splitViewController setPresentsWithGesture:NO];
}
Keep in mind that this is a code block for working with users who may not be using the same version of iOS that you're linking against. The problem you're having is the opposite, in that you're writing code for the same project on two separate devices, each with a different base SDK.
Edit: see here Is it possible to get the iOS 5.1 SDK for Xcode 4.2 on Snow Leopard?