I want to minimize the amount of code I have to write, and use storyboards in xcode to specify the way the view should appear when in both portrait and landscape views.
What is the best/recommended way to do this that minimizes code? I've done some research, but am having trouble finding a simple solution..is it necessary to do some conditional segues, and re-hook up everything in my landscape view, or is there a simpler solution? Thanks!
Generally you define the autoResizingMask (or go to the size inspector in Interface Builder, as shown below) so that the controls will move or resize as the screen size changes. If you do that, you'll generally have pretty decent support for both landscape and portrait. You'll only have to do programmatic changes to the controls' frames if you do some fairly significant changes on orientation changes (e.g. you want to shuffle the various controls around so that they are in very different positions with respect to each other when you change orientation or you want to load very different UIImages). But 90% of the time, autoresizing settings can handle simple moving/resizing/recentering of controls for you:
Related
The Maps app has a "custom" behaviour and doesn't resize the bottom menu when in landscape orientation.
What's the best way to achieve the same effect, short of resizing the view manually on every orientation change?
See attached images to get a better understanding.
This is done using size classes.
The easiest way to do it is to use the size classes right from your storyboard.
Right next to constraints and size related options from the size inspector you have this little + sign.
Hit it to define a different behavior for each size class.
See here for more, including how to use size classes from your code.
I have a UIViewController that overlays controls on a view presenting what the camera sees. I have a couple of scenarios I would like to allow.
For the iPad, I want to keep the controls on the right most edge of the device, by your right thumb, no matter what the device's rotation. The controls should rotate their content so that their top is always upwards (away from the ground). I don't want the camera view to rotate at all, because that would just be silly – its position & size should stay the same and its contents shouldn't rotate either.
For the iPhones, I want to keep the controls at the bottom of the device's screen, by to the home button, wherever the home button actually is. The controls should rotate their content so that up is always pointing upwards. Again, I don't want the camera view's frame or content to take part in any view rotation animation at all.
I'm using auto-layout.
I'm wondering if there is any way to describe some or all of this in a storyboard. In particular, it'd be great to be able to describe that some view positions need to autorotate (ie, the controls, on iPad), but that other views don't (the camera view).
A question from 2011 indicates this wasn't possible at the time, but perhaps things have moved on since then? If it's not directly supported, can you suggest an approach and are there some sensible places to be hooking in to autorotation to achieve this?
Ok, this isn't quite a complete answer, but I tried a few things which look promising.
First, you can create a separate set of constraints for portrait vs. landscape using the size specifiers: landscape is w Regular, h Any; portrait is w Any, h Regular (I think -- double-check these) This is accessible via the pop-up control in the bottom-center of the storyboard view. By installing different constraints for portrait and landscape, it should be possible to scale the width and height of your controls' container view so it appears to be in a constant position w.r.t. device orientation; in other words, the container doesn't actually counter-rotate -- it scales so it effectively looks like it has counter-rotated.
I got this close to working. It looks like it's doing the correct thing in the storyboard view, but when I actually run it, I get debug messages about conflicting constraints. Not sure how to fix this, but maybe play with the constraint priorities? That sometimes helps.
A second thing I (partially) tried was creating a custom container view class which counter-rotates itself to the correct position based on the device orientation (in the UIDevice class). You implement this by overriding layoutSubviews. For each orientation, you define a transform which puts it in the correct position, and set the view's transform property.
Another possible solution is to override updateConstraints in your view controller and add/remove constraints to position/scale your container to the correct place for each orientation.
For all of these, the idea is that you "force" the container to be in the correct place, but leave the subviews (the actual controls) alone. The controls should do the right thing if their constraints are independent of the specific orientation of the container view.
So, those are some ideas anyway... if they lead you to an actual solution, could you post it? I anticipate having a need for this myself.
I have been debating with my boss which of the following is a better way of accounting for an iPad device orientation changes:
Rotating / resizing all views as necessary / making sure their autoresizingmasks are set correctly
In IB, having 2 views pre-made: 1 as the portrait view, and 1 as the landscape view, and, for each orientation change, saying self.view = _ (based on which direction we land on).
Not sure which is better. I just feel like option (1) uses less memory than (2), but can be slightly more tedious?
Any ideas / other pros or cons for either approach? Thank you all in advance.
Actually you should use both:
Use autoresizingmasks when the content of the view is the same and all you need to do is make sure that the content is properly re sized and properly positioned, for this definitely you can use autoresizemasks or springs and struts in xib files
Use 2 different xib files when your content is not the same(extra/less views and the view positioning is really different) for landscape and portrait.
So I have a long form with 11 UITextViews. It's just long enough exceed the iPhone older 3.2" screen so I had to throw it all in a UIScrollView. Now when I rotate to horizontal the UITextViews won't resize to fit the newly available space to the left.
Any ideas about how I can get around this?
First, do you mean UITextFields? (instead of TextViews)
There are many different ways to go about this.
First of, did you use Interface Builder to build the view?
If the view is simple, you can try the elastic positioning provided by Interface Builder, you might have to fiddle with different options.
Another way is to use Autolayout system, available in iOS 6.0+
Or, if you're comfortable with handling frames yourself with codes, you can have different frame sizes set for when the view has rotated.
Or, you can create a separate xib file just for the landscape view and have the program load that xib when the phone rotated.
All of the above are widely used methods for handling rotations, you should choose what fits best in your situation.
I am working on an iPad app and want to support both portait and landscape orientation.
Currently, I am seeing three ways to handle orientation:
1) Apple recommends using two view controllers (http://developer.apple.com/library/ios/#featuredarticles/ViewControllerPGforiPhoneOS/RespondingtoDeviceOrientationChanges/RespondingtoDeviceOrientationChanges.html)
2) The Beginning iPhone Dev book I have uses a single xib file with multiple UIView (one for portrait, one for landscape), swapping the view in the willAnimateRotationToInterfaceOrientation() method.
3) Others have said the "proper" way to do it was using layoutSubviews and autosizing mask.
Before, when I build an app, I would write my entire app purely in code, including interface setup and layout. The result was I ended up with a massive and very painful to tweak interface code.
Now after writing a number of apps in purely code, I kind of appreciate why there is Interface Builder - to help manage the interface and more so, a view controller should ideally only be for managing data and sending it to the views, not managing how the views should look.
Using Interface Builder, it makes sense to have two separate custom UIViews, one for portrait and one for landscape but I've been told otherwise that layoutSubview is the better option.
But if I were to use layoutSubview, that would mean I have to go back to writing and managing my interface using code, which doesn't seem right to me.
Is using layoutSubviews() really the way to go ?
I really don't see any benefit it has over other method. Some say layoutSubviews allow you to animate the transition to the other orientation.
My two interface isn't a simple resize button or text width when the device rotates. I have adjacent sliders next to text fields that should be stacked vertically when rotating to landscape and other sliders that needs to be moved to the other side of the screen etc.
edit
might be a duplicate questions of:
Handle iPhone orientation Landscape/Portrait
iPad/iPhone multiple orientations best practice?
Moderators can close if need to.