I've been having such a hard time trying to figure out how this thing works. It's so random and I have no idea what else to try. I've looked up multiple articles on this issue and everyone just says change the scale. Changed the scale does not help, it's got nothing to do with what's happening here. I'm not sure if this is related to the bottom of Xcode where you can change the dimensions (Any vs Any / Any vs Regular Height, etc...) I've asked my mobile development teacher at school as well and he couldn't figure it out either. Any help would be greatly appreciated!!
Picture below:
http://tinypic.com/r/281fw5w/8
Your problem is not scaling. What you need to look at is auto layout and constraints.
You can use the icons in the lower right edge of the interface builder to get at them or control drag from a view controller (like a button, label, etc.) to the containing view (or any other view controller for that matter.) Usually, the main view window itself. When you release you can now add constraints to "attach" the element to that other element relatively. For instance, you could attach the things on the left to the left side and the things on the right to the right side. Now, regardless of the dimension of the actual device screen, those elements will appear in those locations relative to the device screen.
The problem is that the position of elements from your perspective is right for the canvas you see in the Interface builder, but once the app is run, the real canvas has different dimensions.
To manage the position, size and other attributes of UI elements, there is a system called AutoLayout.
It is quite ingenious because it is similar to natural language.
For example "I want this element to be in the middle of the screen."
or
"I want this element to be 20 pixels from the left corner and 57 pixels from the element that is above this element."
By combining these rules you basically create a set of layout constraints, that are applied in runtime to the view hierarchy and view are laid out properly.
Autolayout allows for very sophisticated layouts.
Another aspect you need to take into account that you might want your app to look well in all form factors from 3.5 inch iPhone up to iPad air.
Since these devices differ considerably in size, Apple introduced an abstraction called Size Class.
Size Class is an abstraction on top of concrete size. Concrete iOS devices have vey concrete dimensions. But in natural language you often say it's big ,or small ,or normal. And this the level of abstraction size classes use.
For each size class you can have a particular set of auto layout constraints.
So by combining AutoLayout and SizeClasses, Apple solved the problem oh how to have one application but one that can still accommodate specific form factors and can adjust its layout to them.
In Xcode6, all storyboards/xib files have autolayout & sizeclasses enabled by default. Interface builder provides you with a comfortable environment where you can set up your layout by creating constraints for each size class combination.
Related
In order to get an iPhone layout to display at 'correct' dimensions on iPad, I'm putting everything (rose) into a view (blue) within the ViewController (gold)
Click / tap to see Schematic View
The iPad is shown as the larger frame with the grey status bar.
So to cater for 7plus size iPhones downwards, I'd have to set up constraints for the 7+ within an iPad frame with different priorities
in different directions. Once the blue view is set, i should happily be able to add my Sub Views in I.B.
Since the whole lot has to appear in the very centre of Ipads, step (1) is to set alignment centre-line constraints of the blue View with priority of 1000.
Next would be to fix the size for iPad displays larger then 7+. Acheived with setting size constraints as a maximum to shrink from. I've only shown the ≤680, so that height or less as in step (2) but a lesser priority, say 750.
Then for it to reduce down in size toward SE size i want to hold that say 20 points away from the viewController (gold). So the constraint for that should be ≥20. as shown at (3), I've assigned 740
The principal works nicely in the horizontal direction, but not the vertical. I've tried endlessly to adjust different priority assignments, including the 'Content Hugging' and 'Content Compression Resistance'properties and I never seem to get the desired results once I put the actual entities I want to see (rose) within the Blue view.
I've read Apple's Autolayout Design Guides closely enough to almost say I've written them, and after 35+years of CAD and 3D animation modelling, I think I could describe objects in text parameters before the iPhone existed.
But I've been bested here. Am I taking the long way 'round to just get an ** iPhone only ** layout to display correctly? My little bald spot thanks you for your answer.
If it were me, I'd use trait variations instead of trying to handle layout for every size class in one set of constraints. I think if you take that approach, you can accomplish what you're after with a lot less work and in a way that's independent of devices that may appear in the future.
Also, keep in mind that if your app supports iPad multitasking, you may have sizes on an iPad that you're not expecting (like iPhone portrait width in device landscape orientation).
With autolayout, try not to think in terms of device type or orientation. Think in terms of the appearance you want for a particular size class, wherever it appears, in whatever device orientation. That gives you the opportunity to create a the best user experience for a given display area, and will make your life easier during initial development as well as when new features are added or new user devices are in the mix.
I need to create an app with adaptive UI. for that I use auto layout and size class. but i can't get the expected result. it displays different UIs for different screen sizes. kindly guide me to create the adaptive UI(for all screen sizes). Thanks in advance.
This is indeed problem with constraints as mentioned in comments to your question. Using size classes only allows you to set constraints for all iphones at lowest level (that's why screen size for size class Compact x Regular is same for all iphones in xcode).
It is difficult to help you, without knowing all of your constraints. My advice is, use Preview assistant, where you can see all of your devices and generated UI. By opening this Preview assistant, tap on bottom "+" symbol and add device you wish to inspect.
As you can see on this screenshot, in my storyboard, there are margins around the middle view, however on iPhone 4, where width is smaller, these margins are lower (they have lower priority as constraint), while view retains it's width/height.
I have looked at umpteen tutorials, google posts and questions on SO but am still struggling with best way to layout a page for an iPhone app.
Part of the problem is many of the tutorials and questions are old and discuss ways that may have been optimal at some time in past.
Now, in May 2015, what is best-simplest way to have things like textfields and images layout so they display properly in common iPhones i.e. iPhone 4, 5, 6 and 6Plus?
Is it necessary to use constraints? I've gone down this road but found it very labor intensive?
Can you use blue lines as recommend in Stanford 193P tutorial? Or is there any rule of thumb way to layout a picture or a text box so that it looks good in multiple formats i.e. some number of points or using blue lines.
Storyboard in Xcode 6.0 is now 600x600 from what I can tell so a lot of times what you lay out looks horrible in the simulator. But the simulator is not an actual iPhone.
Thanks for any suggestions on right way to do this.
My answer is AutoLayout,in other words Create constraints
You can change storyboard to device as you like by click here.
You can use blue line as reference then let XCode auto create. But in this way,you are not always get right layout
Also,you can create layout by here
And you can create layout by Control + drag
By create layout,it is easy to place you views
You essentially have two choices; constraints or frame math. Both have their benefits and detriments.
The benefit of layout constraints is that you can figure out universal relationships between subviews and their superview. (e.g. It's always 20 points from leading and trailing edges or it's always dead center x and y) Once you do that, you only need to write layout code once and it will work across all device screen sizes. Also, if you ever plan to support iPad or rotation on iPhone, the work it will take to support that functionality is minimal. Another huge benefit is that if a view's frame changes, it will take care of resizing and laying out all of its subviews for you so you can modify the size of a container for example and not have to reset all of it's children's frames manually.
Constraints are "more modern" than frame math and definitely Apple's preferred method.
The issue with constraints is that the code is more verbose. Views also depend on their superviews to lay themselves out. If everything is done correctly it works great. But if you make a mistake adding constraints to one view it has the potential to trash everything else that depends on it. Once you get everything figured out it does exactly what it advertises. But getting to that point can be, in my opinion, more complicated than setting frames explicitly since there are more moving parts.
Frame math still has it's place sometimes. It has the benefit of being fast and relatively concise. Back when iPhones all had the same sized displays it worked great and if you are laying out in a view with a guaranteed rect there's no reason to need to avoid setting frames.
The problem with frames is that you are expected to support all the devices that run iOS 8. If you are laying out with frames that means you could have to write 5 different sets of layout code to support 4s, 5, 6, 6+, and iPad and 5 more sets if you want them all to rotate. This isn't always tenable.
In the end it comes down whether or not your containing view has a guaranteed height and width. If the answer is yes (like laying out inside of a collection view cell with a static width and height for example), I would have no problem leaning towards frames. If not, auto layout is the way to go.
Im starting to experiment with storyboard. As you can see I have chosen the storyboard size to be height=regular and width=compact, which says “For all iPhones in portrait”.
The simulator I am using is iPhone6 however when I run everything is slightly off to the right.
Can someone explain what is happening or what I am missing?
The problem is that (as described in the comments) you are positioning the views without AutoLayout. When you just drag and drop the views, it's actually setting the frame's positions and sizes. The main problem with this approach is that it doesn't set the position and size in a proportional and related manner, taking in consideration the container. This is why you're getting the view at the current position. If you run in another simulator, maybe you can get the correct position, or maybe not. What you can do to change this is apply auto layout constraints to those views. There's a special constraint to center views horizontally. With autoLayout you can go further, specifying relation between one or more views, and those views not necessarily need have the same container view.
One quick example:
Notes:
I'm using universal storyboard to take those screenshots. It's more flexible and with AL you don't necessarily have to concern yourself with the size, as views adjust themselves depending on the constraints applied to.
EDIT:
https://developer.apple.com/library/ios/documentation/UserExperience/Conceptual/AutolayoutPG/Introduction/Introduction.html
This is a link to auto layout guide provided by apple, a great tutorial on how to get your hands dirty in this little world.
So I've been making an app for iOS lately, and I've come across a dilemma. I'm making a mini synth, and I started making the GUI. I started making the keyboard (2 octaves for now) and measured the approximate length of the white keys. It all worked great, until I ran the thing on a 4 inch iPhone.. The keys were too small, they didn't cover the full screen etc... So I thought I could put the individual key images into a container which will stretch depending on the resolution of the iPhone, thus the images inside (the keys themselves) will stretch in percentage according to the size of the container.
Thing is I have no idea whatsoever of how I should go about it. What element should I use to contain the images/keys?
Generally what you want to do with new apps is make use of auto layout. This lets you set up the relationships between various UI elements in a way that is independent of screen size.
If you're creating views directly on the storyboard, you can add the constraints there.
On the other hand, if you create the views in code, you'll need to use the NSLayoutConstraint class to create them (more information is available in the documentation, especially for the Visual Format Language).
In this example, it sounds like what you're after is a constraint on the container which pins it to its superview, eg:
#H:|[container]|
#V:|[container]|
along with proportional constraints on the keys (setting their width to, for example, a given fraction of the parent container's width).
Note that this approach (using auto layout, but with the same base layout) may not be appropriate in all circumstances.
In particular, it may actually make sense to display a completely different layout on a tablet, where you have a lot more space for the keyboard.