How to handle orientation delegate method in IOS6, IOS7 and IOS 8? - objective-c

I am working on the new iphone app and I have to give orientation support in all IOS version(ios 6 and later). can anybody explain what is the best way to handle orientation for all IOS versions.
I searched and found that few of older version delegate methods have been deprecated in the newer version of IOS.
How should I manage of this?
Please provide idea.
Thanks In advance.

In iOS7 & iOS8 you can use auto layout and size classes when you create a new project a
600x600 resolution ViewController is added you have to add constraints on that ViewController then it will run same on all devices
For auto layout you can follow these tutorials
1-[http://www.raywenderlich.com/83276/beginning-adaptive-layout-tutorial][1]
2-[http://www.appcoda.com/introduction-auto-layout/][2]
3-[http://www.brianjcoleman.com/autolayout-xcode6/][3]
Even it will run on iPads too.
thanks

I think those three methods can meet your requirement.
- (BOOL)shouldAutorotate NS_AVAILABLE_IOS(6_0);
- (NSUInteger)supportedInterfaceOrientations NS_AVAILABLE_IOS(6_0);
- (UIInterfaceOrientation)preferredInterfaceOrientationForPresentation NS_AVAILABLE_IOS(6_0);

Related

iOS8 how to understand interface orientation from UIViewControllerTransitionCoordinator?

I'm debugging a project that was working fine in iOS7.1, but does not lay out it's content properly in iOS 8.0. I've narrowed the issue down to this method:
[self orientRootViewControllerForOrientation:rootViewController.interfaceOrientation];
iOS8 no longer returns correct UIInterfaceOrientation from rootViewController.interfaceOrientation, instead it returns "upside down".
Reading the documentation, I'm confronted with a cryptic message:
Use viewWillTransitionToSize:withTransitionCoordinator: to make
interface-based adjustments.
Reading documentation on UIViewControllerTransitionCoordinator, I don't see it having any properties. How can I modify my method that expects an interface orientation to get it's orientation from UIViewControllerTransitionCoordinator?
Basically you are supposed now to layout your content based on the available size, no more on the rotation. Which results in big pains to support older rotation-based code.
The view controller transition coordinator provides a UIViewControllerTransitionCoordinatorContext that has a rotation factor. This could give you the hint you need ?
This blog post mentions this too.
You also have the usual device ([UIDevice currentDevice].orientation) or status bar orientation.
In case you are working on iOS 6 rotation methods, this post has relevant informations too.

iOS7 Strange behavior of UIPickerView with an UIImage as custom view, any official info?

I was following a tutorial on how to build a custom picker with an UIPickerView in Sams Teach Yourself IOS6 Application Development in 24 hours and I've noticed that simply returning an UIImage in (UIView*)pickerView:(UIPickerView *)pickerView viewForRow:(NSInteger)row forComponent:(NSInteger)component reusingView:(UIView *)view method of the UIPickerViewDelegate does not work properly: the images do not appear correctly (they rotate on the spinning wheel but for example they disappear when they should move over the current selection's row). I've found a solution at this link on Stack Overflow and it effectively works, but I'd like to know if this strange behavior appeared in IOS 7 is due to a new way of using UIPickerView or if it is more a sort of bug.. I did not find anything useful in the official API Reference docs. Is there any official doc that is talking about the change in how we must return an UIImageView to be used in a UIPickerView
It looks like the answer is 'No'. I also looked through the Release Notes for 7.0 & 7.1 and looked at the differences in the references for UIPickerView, UIPickerViewDelegate, and UIView (among others) and couldn't find anything do explain why it behaves this way now and I couldn't find any changes to UIPickerView or anything it inherits from or conforms to that would explain it. (If there is something there that explains it then it was not immediately obvious to me.)
As far as I know, those are the only places that would have any official information on this.
I think the only way to know for sure whether this is deliberate or a bug is to report it.

How to use NSLayoutConstraint in iOS 6?

My app should support both iPhone resolutions (5 and older) using iOS 5 and iOS 6. When I use autolayouts in IB, on iOS 5 app crashes like this: link
So, I am trying to use NSLayoutConstraint in code, but unsuccessfully yet.
Subquestions:
I am adding constraints in viewDidLoad method, but is it correct?
Does updateViewConstraints invoke by framework? I have never seen that it was invoked.
I tried to use examples from apple's docs, but it was without effect to view.
Anybody knows how to do it?
PS: I know it's possible to make it manually by setting frames, but I would like to use NSLayoutConstraints.
UDP: Yes, I know, that's why i use NSLayoutConstraint in code. I can make condition for determining iOS version. The question is about iOS6.
The AutoLayout feature is only compatible with iOS6 and is not supported in iOS5. Thus the crash
If you intend your app to be compatible with iOS5, you can't use AutoLayout in your XIB files.
You can only use older methods, like the AutoResizingMask for example (which is often sufficient for most cases anyway).

How do I use a RootViewController when making an app without a ViewController?

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.

Better way to detect if isIpad?

I have an universal app that changes the screen layout based on what device the user has.
It seems to work pretty good, but I've had one user call in (and send me screen shots) of his iPhone 4 showing him the iPad view instead of the iPhone view. I haven't been able to duplicate it on any of the phones we have around here, but I'm wondering if there there is a better way to do this since iOS 4.3 has come out.
+(BOOL)isIpad{
return ([[UIDevice currentDevice] userInterfaceIdiom] == UIUserInterfaceIdiomPad);
}
Alternately, is there just a way to detect screen size? I mostly use this to determine how wide elements in a table should be, but if Apple comes out with iPad 3 with retina display, it would be nice to have the app just adjust everything accordingly.
Also useful if the app is in portrait or landscape. Make it so that it just anchors to the edges like elements in WPF.
When loading XIBs for a universal app this, or what you're already doing, seems to be the only way:
NSString *xibName = (UI_USER_INTERFACE_IDIOM() == UIUserInterfaceIdiomPad)?#"SomeView~iPad":#"SomeView";
As for screen size this should work:
CGRect screenSize = [[UIScreen mainScreen] bounds];
This is like a bazillion years old, but came across it in google so I figured I'd post a poorly documented but very useful feature. If you add ~ipad to the end of the filename for your iPad specific nib it will automatically load that one instead. Same logic as #2x for loading images. So your iPhone nib would be named myview.xib and your ipad myview~ipad.xib and iOS will correctly load the ipad version wherever needed. Fancy!
UIUserInterfaceIdiomPad is now deprecated. The new way to do it would be using TraitCollections. It can only be called on Views.
-(BOOL) isiPad{
return self.view.traitCollection.horizontalSizeClass == UIUserInterfaceSizeClassRegular && self.view.traitCollection.verticalSizeClass == UIUserInterfaceSizeClassRegular;
}
Refer Apple Documentation here
Probably it has a previous version of the app and conflict with the new!
Try to remove old one and reinstall new! It works! I already encountered this issue.