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.
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 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.
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.
I have three different alternatives to design a view, at least three that I could think of / understand from different blog posts and SO questions. The layout is pretty simple, some labels and textfields to provide a login. The thing is that it should adapt to any device screen (iPhones portrait for now to limit scope).
Each one of the three alternatives seem to have pros and cons, but I want to understand which one (if any) is the proper way in which we are supposed to design with adaptative layout, size classes and universal storyboards in mind.
Please, don't hesitate to point me wrong!
1.- Design on Any W | Any H size class, and once I'm happy with the default design move on to specific situations:
The issue here is that there isn't a size class that allows me to specify a constraint only for 3.5inch devices (all cases I tried affect none or several). Therefore, I don't know how to properly define a specific constraint that overrides the default one in this unique case.
2.- Same as before, design on Any W | Any H but using smaller gaps between elements.
It looks as good as it gets in smaller devices, but a whole lot of space is lost in bigger ones as the constraints don't adapt. Maybe constraints should be overridden in this case, which would be the inverse case as the previous point.
3.- Use a subview hierarchy to distribute the elements.
Embedding elements in subviews inside other subviews I managed to have a dynamic layout that adapts to the height of the screen, but it doesn't look right at all in bigger screens. The subviews are expected to take up the same height, but I'm not sure this is quite correct.
i think it really depends what you want, its hard for us to tell you what your app should be like, although i would think the last case is what you would most likely want (in general, for a login page like this i would choose number 2), i think it can be achieved without using subviews though, try setting each textfield to having a vertical center, and set the multiplier to a value that puts it in the right place, then it should stick proportionally where its supposed to be
I have so far developed for Android. There, you can set layoutMargin and padding for almost every UI element (when you describe UI in xml file).
How is this done in code for UIViews in iOS (if there is a common command)?
Tnx
iOS employs a different approach to control placement - there's no layouting engine, you specify absolute coordinates and size for all controls. Kinda like the AbsoluteLayout in Android.
So the concepts of margin and padding don't really apply - the gaps between adjacent controls are completely up to you, they're not computed by the system. Same for sizes.
This makes it more difficult to implement the scenario of "make this control as large as it needs to be for its text". However, you won't run into rogue line wraps.
EDIT: AbsoluteLayout is deprecated these days.
You lay out your UI elements either in code or using Interface Builder (or the .xib editor in Xcode 4). You'll specify actual coordinates for your views, but you can also specify the resizing behavior for each view. So, you can say that a particular view should always keep the same size and remain horizontally centered, or that it should keep it's size and maintain the margin on the left, or that it should stretch to keep both left and right margins, etc. Look for the "autosizing" section in IB, or set the autoresizingMask property of any view in code.
In ios you can use Interface Builder for design. You can still use xml, but no one use this.