Im having an issue with my layout in my story board. When i make a stack view how can i adjust the size of the UIlabel box to fit more text?
Image Example:
Also how can i get rid of the stack view to bring everything back to its original state?
To add more text- simply type more text. The label adjusts itself.
To get rid of the stack view- select the stack view and go to Editor->Unembed
I have given you a brief overview of auto layout. The examples that we have worked on were pretty easy. However, as your app UI becomes more complex, you will find it more difficult to define the layout constraints for all UI objects. Starting from iOS 9, Apple introduced a powerful feature called Stack Views that would make our developers' life a little bit simpler. You no longer need to define auto layout constraints for every UI objects. Stack views will take care of most of that.
In this chapter, we will continue to focus on discussing UI design with Interface Builder. I will teach you how to build a more comprehensive UI, which you may come across in a real-world application. You will learn how to:
Use stack views to lay out user interfaces.
Use image views to display images.
Manage images using the built-in asset catalog.
Adapt stack views using Size Classes.
On top of the above, we will explore more about auto layout. You'll be amazed how much you can get done without writing a line of code.
What is a Stack View
First things first, what is a stack view? The stack view provides a streamlined interface for laying out a collection of views in either a column or a row. In Keynote or Microsoft Powerpoint, you can group multiple objects together so that they can be moved or resized as a single object. Stack views offer a very similar feature. You can embed multiple UI objects into one by using stack views. In most cases, for views embedded in a stack view, you no longer need to define auto layout constraints.
Quick note: For views embedded in a stack view, they are usually known as arranged views.
The stack view manages the layout of its subviews and automatically applies layout constrants for you. That means, the subviews are ready to adapt to different screen sizes. Furthermore, you can embed a stack view in another stack view to build more complex user interfaces. Sounds cool, right?
Don’t get me wrong. It doesn’t mean you do not need to deal with auto layout. You still need to define the layout constrants for the stack views. It just saves you time from creating constraints for every UI element and makes it super easy to add/remove views from the layout.
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.
Using Stack View, I want to get 3 items next to each other, which I achieved:
However, what I am looking to do is if the screen is too small to fit everything nicely in, then to move the block to the next line such as:
Should I not be using Stack View for this?
Github version of sample project:
https://github.com/jzhang172/StackTest
UIStackViews cannot do that kind of automatic layout where it sends overflow to a new row AFAIK. For what you are trying to do there are several other options depending on your purpose.
Embed several stackviews in a large UIScrollView and size it to only show your first row. Later could "grow" that scrollview to expose additional stackviews as needed.
You could dynamically create additional UIStackViews located in the lower position and fill them as needed.
You could consider a UICollectionView instead.
BTW: There is a github project for OS X embedding stack views in a scrollview dynamically. It might help you out: StackViewTest
I've always done my UIs in code but have decided that I should use storyboards and auto layout for a current project. Everything had been going well until I built a complex scene with about 50 views with lots of hierarchy and some grid of views.
The problem is that my auto layout is getting muddled on some devices and orientations. I'm finding it challenging to use IB to try fixing the dozens (hundreds?) of constraints or to track down the problems and resolve them. The situation is such that I'm not getting errors or warnings, just some unpleasant layouts at times. And IB can be a pain with all the clicking and changing settings you need to do to track down constraint information, let alone get a full idea of how they all relate in a scene.
I've just spent a day reading docs and background material on auto layout and constraints and it seems my best solution is to use the visual format to specify constraints in code and create some custom code to help. However, I can't seem to find anything on how to make the transition from IB to code.
Specifically, should I wipe all IB constraints and do them all by hand or is it possible to be selective? I ask because I have some groups of views in containing views where the content views have a perfect layout.
Secondly, where best do I put my code? I want to coexist storyboards and just want to selectively modify some complex scenes. Is a view controller's viewWillAppear: the right place to modify or remove/add constraints for the view it controls?
Connect an IBOutlet for the NSLayoutConstraint you want to be able to modify in the storyboard/xib file to your controller/view class.
Once you have the layout object connected, you can modify the .constant property and animate the view:
[self.containerView layoutIfNeeded]; //make sure all layout operations are done
self.containerViewBottomLayoutConstraint.constant = 200.0; //change the layout
[UIView animateWithDuration:duration animations:^{
[self.containerView layoutIfNeeded]; //animate the changes
}];
updated: you can add your modification code in viewDidLoad, awakeFromNib, viewDidAppear, or event based. It really depends on your intentions.
Sorry to take so so long to get back to this while other projects intruded.
I had to do a lot of refactoring to simplify my scenes so that auto layout could do the right thing, and yet I am not fully satisfied with the results. The problem seems to be that IB is just not easy to use with lots of items, and that auto layout is complicated, by necessity.
With that said, the best results I've seen so far are drawn from this article by Justin Driscoll: http://themainthread.com/blog/2014/02/building-a-universal-app.html
He advocates building custom views to encapsulate reusable UI components. I have taken this approach but have extended the idea to also bundle up related components that are not going to layout very differently as the layout changes. For example, I have a progress bar with button and two labels, so even though I am not reusing them as a group, they need to be adjacent and conceptually are related, so I've made a custom view for them which handles the auto layout as Justin suggests.
I'm now taking the approach that each level of auto layout should only have a handful of elements. If one level gets too complex, I'll bundle up some related items in a custom view and push some auto layout inside that new view. So far it isn't too bad.
Auto layout can be really tricky when using that many views. I have used similarly complex views structures, and I find that it is best to try to keep all of the constraints in code or in IB. Right now we are keeping them in IB. The only time that we move a constraint into code is when we are supporting a different screen size, and we need to modify a single constraint for the view to work right. I have always modified the constraints in viewDidLoad myself.
When something gets messed up I almost always have to nuke all of the constraints on that view and start over. It sucks, but it's often quicker than tracking down the problem. One thing that we do that makes it easier to deal with that sort of thing is to use .xibs along with your storyboard. That way, each view can handle it's own layout, and you can pull that into a view that is sitting in a storyboard.
On iPad, both the native Photos app as well as Reeder use a "expand/collapse stack" technique. Initially there is a stack of items on top of one another, each angled a bit with different corners showing. When you interact with them, the stack expands into a full screen and the items are laid out in a grid. When you collapse them, they collapse back into a stack.
What's the best way to set up my views to do the same thing? Should I just have a bunch of UIviews (one for each item) and manipulate their coordinates/transforms with an animation, or is there something more to it? Any example apps with code?
(Note: I am not asking about the interaction to invoke expand/collapse, I'm only asking what's the most appropriate way to lay out and set up my items.)
These days, use UICollectionView with different layouts and transitioning between layouts.