Closed. This question needs debugging details. It is not currently accepting answers.
Edit the question to include desired behavior, a specific problem or error, and the shortest code necessary to reproduce the problem. This will help others answer the question.
Closed 4 years ago.
Improve this question
Goal is a vertical layout matching the top/bottom of the screen view as in the sample image ...
I have NSConstraints between each item in the UIScrollView
However on a small device screen such as the 5S it is not showing the bottom buttons
(i.e. when the screen height is less than content height)
Is there a solution with fixed height of each UI element, or do I perhaps need to calculate every height dynamically so that without the UIScrollView it will fit in to smaller heights?
In short,
use a UIStackView
for this problem.
"or do I perhaps need to calculate every height dynamically so that..."
In fact that is precisely the purpose of a UIStackView
Learning to be an expert with autolayout and constraints is not easy. It is a delicate and artistic process.
For the challenge at hand, I would begin with one large stack view which fills the screen. The stack view itself will space everything nicely.
your stack view parameters would likely be:
(start with zero spacing)
and as you probably know use these to indeed test each device size:
Note that furthermore, in extreme situations, you will have to indeed also let certain of the elements shrink (it's your choice) when you run out of gaps to shrink. Unfortunately you must master all these techniques to make modern reactive apps.
Note, one key on this layout is that you have to let the spaces collapse as it gets smaller. Indeed the stack view will do precisely that for you with the correct settings.
That is a huge field of expertise, you would need to ask another question about it once you have
eliminated the scroll view
got the stack view working in a basic way
Indeed you will already find many QA about the issue on here.
Note that aBilal exactly described the situation in a comment:
"It is very simple, open your storyboard, select "iPhone SE" screen from View as at the bottom, rearrange all the screen accordingly using constrains. Now check your app will work on all screens including iPhone X as well. "
Indeed. it's much like saying:
"So you want to be Joe Walsh. It is very simple, purchase a guitar. Put one hand on each end. Now play. A lot.
:) It's a bit like that.
Adding scroll view for your screen doesn't seem to best solution according to me as it doesn't have so much elements on screen.
Best practice according to me is to always design the UI on smallest screen device your application is going to support and set your constraints accordingly. And I would suggest you to do the same into this situation as well. Hope this will be helpful.
Related
I have a view on a nib in Interface Builder. It's got a several UIStackViews within the nib, which I used because it's a easy to align UI elements. A colleague suggested I not use UIStackViews because they're "expensive" from a computational standpoint. The alternative is setting constraints for individual elements manually.
What Xcode tool can I use to validate my colleague's assertion and how would I use it? The best thing I've found is this, but I was hoping for something a little more granular. The nib in question is a UITableViewCell.
they're "expensive" from a computational standpoint
Okay, I will now attempt to demonstrate that that's utterly bogus.
A stack view is not magic. A stack view does not perform any special run-time adjustments. A stack view is just a constraint-maker, no more, no less. So are you. Everything a stack view does, you could do. And the stack view's resulting constraints are exactly the same constraints you would have created yourself (assuming you even know how). Therefore, the constraints themselves are not more expensive just because the stack view made them.
So let's talk about the initial generation of the constraints. Well, the stack view generates its constraints by rote. It's just a simple formulaic approach based on the parameters already given by such things as the stack view's settings and (in some cases) the intrinsic content sizes of the arranged subviews. So it takes effectively no time at all for the stack view to spit out the constraints that it generates, and it only has to do it once.
So if the generation of the constraints is not expensive, and if the constraints themselves are not expensive, where is the expense? It's nowhere.
Someone might argue that for a particular desired outcome using a stack view is unnecessarily complicated, or lazy, so it would have been "better" to make the constraints yourself; but "expensive" doesn't seem to me to be a genuine charge that can be laid against stack views.
In digging around, I found a repo called LayoutFrameworkBenchmark. I ran the benchmarks in iOS 12 on an iPhone 7+ simulator. I gathered the data and dumped it in a Google Sheet. It does indeed show UIStackView is pokey versus other layout methods.
I now see why there seem to be people in both camps, however in the real world, the human eye is unlikely to notice much of a difference unless it's a huge collection.
For my game, I want to have this element for movement:
It's actually one image with 4 buttons on it:
Now how do I go about making them adaptive as in a stack view?
Since stack view doesn't really allow me to make elements overlap, I don't see an easy way here. Or I could make different stack views and make these overlap, but would that really be a good approach?
Is there another way to group elements in iOS, which allows more than horizontal and vertical stacking?
Apple suggests to use UIStackView rather than NSLayoutConstraints for designing the view but, it is not necessary to use UIStackView always.
According to mentioned situation in question, it is better if you use constraints rather than UIStackView here.
But you wish to stack here, then take the 2 images in stack at a time and then align them in center of container view.
I am working on auto layout and making those UIIMages as Button.
I would like to make those button to be clicked and switch the images
as well as showing some words in the label.
In this case what should I do?
In addition, as it is shown, the auto layout ratio is different only from the iPhone SE. In. this case What should I consider?
Many thanks,
The first thing you need to learn is auto layout. Start with basic Always go with Apple's doc first
This one I likes he is good and you will also find how to use buttons as image view, using card game example, check other tutorials also very helpfull.
Stanford university autolayout by Michel Deiman
As far, your question just gives your label Horizontal in the container constraints(open storyboard in the right bottom third from last (allin) click on it popUp will open), and 20 bottom to the buttons and it will be in the centre. Every elements need x,y height and width so it knows exactly where to place, so you also need to give constraints to the buttons, Learn stackView to understand how to place your button without giving many constraints to each button and stack view will handle it for you, try hide and show to one of the button and magically stack view will adjust all adjustment. I suggest before staring Do read apple's doc first.
And Your question is too broad to answer, so read and try adding different constraints based on your need and ask a specific question(after trying by yourself) like why this label getting cut what constraints should i add so people know exactly what you want to achieve, people are always ready to help, just ask the right question.
happyCoding
I tried to solve this at my own, but I just really can not understand auto layout. I also searched here for a solution, but I could not find anyone with this similar problem (although I see a lot of people struggling with auto-layout). I want to make an app in landscape mode what is supported by every iPhone 5 and higher. I set up some constrains, with this as result:
How it should be
Above is the correct image on how it should be on every device. Can I set it relative to a screen size? I tried changing values with the multiplier, but that did not worked out well.
How it is on bigger screens
Here you can see how it is now. Because the values are absolute and not relative, I think it not changes... By the way, I am using " compact height" for building my landscape apps for iPhone, is that correct? Or is this the cause of this big trouble?
Here's a quick run through that might be more applicable to your needs than the general tutorials...
Create your elements on the storyboard and lay them out in roughly the right place:
Select items 1-4 and hit the stack view button, then select items 5-8 and do the same, Xcode is very good at guessing what you want so you'll get two vertical stack views, like this:
Select them both, hit the stack view button again and you'll get a horizontal stack view that contains your two vertical stack views:
Then select this stack view and the header and press the stack view button one last time to put them in another vertical stack view:
How you just need to adda few constraints to the outer stack view and then tweak the settings of each stack view. In this case, I've pinned the outer stack view 20 from the view edges, set the outer stack view to fill proportionally and everything else to fill equally, plus I've set the vertical stack views to centre alignment. You can play with all of these settings to get a result that you find pleasing:
This will now scale perfectly for any size screen:
I've just used labels for speed, but the same rules apply for images or whatever.
Hope that helps, stick with the tutorials and keep practicing until you figure it out, it will save you lots of time in the long run.
how to give sizes for view(height or width) for a iPhone and iPad separately using auto layout via interface builder ?
This question is a bit old, but for everyone coming here, the answer is: You don't. If the reason wasn't very clear back in 2014 when this question was asked, it is very clear since iOS 9 and the introduction of Split View and Slide Over.
To be a bit more concrete:
Don't rely on separate storyboards or UIDevice.current.userInterfaceIdiom. This tells you if you are on an iPhone or iPad, but since an app can now be in split view, it doesn't give you ANY information about available screen real estate
Don't rely on UIScreen.main.bounds - if an app is in split view, the screen bounds might not equal your app's size, so this information is useless for layout decisions
Don't blindly rely on self.view.bounds in your view controller. If the user moves the app into split view, the size of your view might change at any time. You CAN use this if you're monitoring the bounds (e.g. by overriding bounds and using didSet), but I would argue there is almost always a better way, and this doesn't help you if you are not in a view controller.
Apple recommends using size classes. While this does seem a bit limiting at first and takes some getting used to, almost all layout decisions these days can be solved using size classes and proper auto layout. The great thing about size classes is that, if the size class changes, for example because an app moves into split view, the system will automatically take care of removing the auto layout constraints of old size class and adding the appropriate ones for the new size class.