Hello I am trying to display multiple vertical table views inside of ONE horizontal view on iOS. Is this possible? The table views themselves should be able to scroll vertically like normal but I should also be able to scroll horizontally between multiple tableviews, all in the same viewcontroller (if possible). I have attached an image of what it should look like . As you can see, I should be able to scroll the tableviews vertically independently from the horizontal scrolling that is used to display different tableviews. All while keeping the header visible (Engineering, Scholarships, etc.
What strategy should be done on iOS/Swift, is there a tutorial? I am OK with using a UICollectionView instead or any other type of view. Thanks so much!
I have a simple table view controller. Section 0 will be a single cell with a couple of labels, textfields, and a few buttons. I wanted to use stack views to layout the fields neatly. The moment I add any constraints I get the whole thing off the cell and not visible. The one button that is alway visible isn't even the correct width. The cell height is plenty large enough to hold it. It looks perfect in the interface builder, and has no errors or conflicting constraints. What am I missing?
Then image with the fields all there is without any constraints.
In the Interface builder
ScreenShot
What's the difference between a UIHorizontalStackView and a Collection View(Also Vertical stackview)?
Can't a collectionView be horizontal and vertical? Why would people use both?
What does a UIStackView do that a Collection View can't?
Yes, a collection view using a flow layout or a custom layout can be vertical or horizontal. When using a flow layout it's pretty easy to configure a single column of items which are all set to their intrinsic content size.
The stack view is basically a trim and specialised version of that. It takes away the flexibility of the collection layout and in return gives you a streamlined interface.
Depending on your use case you may not need the complexity of a collection view. There are also some nice little features, like if you had a list of options to display but some aren't appropriate in all cases then you can just hide the ones that aren't and the stack view will deal with it. Hiding items in a collection view requires a good deal more configuration.
Stack views also form a very lightweight option for container views created entirely within interface builder and with no requirement for code. In this way the stack view is replacing a lot of your auto layout constraints by using the intrinsic content sizes of the subviews it manages to flow the layout. You can also very effectively nest stack views to form most tabular type layouts.
Collection views have cells and work with data presentation. Stack views are a way to layout views within a container. Stack views do not have a way to work with the data as collection views do with delegates. Collection view is data centered and stack views are layout focused.
UICollectionView is like a grid, UIStackView is only for 1 dimension: vertical or horizontal.
UICollectionView is like UITableView, but it supports more than single-column layouts.
Collection views provide the same general function as table views
except that a collection view is able to support more than just
single-column layouts. Collection views support customizable layouts
that can be used to implement multi-column grids, tiled layouts,
circular layouts, and many more. You can even change the layout of a
collection view dynamically if you want.
vs
The UIStackView class provides a streamlined interface for laying out
a collection of views in either a column or a row
For me, With StackView, you benefit the "AutoLayout" feature, for example: you put 4 views in the Stack, this component will decide how those views will be presented on the screen, depending on their size.
Collection views are much more complicated UI elements, requiring a DataSource object, and a layout etc.
Stack Views seem to be a replacement for tricks where you had to apply multiple constraints to several elements to do (say) a stack of buttons, or arrange labels and text fields for a form.
Stack Views also don't have a delegate, and have no mechanism for selecting items or anything like that.
If you asking yourself why this 2 options are there, which looks like very similar - sometimes you'll create a custom Cell (tableview or collectionview) and will add a another tableview or a collectionview as a subview - then you will love to know how UIStackView works....
Is it possible to create a fluid UI with interface builder?
For example, say I have a page that has a few fields at the top, some of which are optional. Can I make some of them invisible and have the fields below move up to fill the gap?
Similarly, if I have a tableview in a page followed by a text field, can I have the tableview grow and shrink and still have the text field immediately after it?
The best you can do with interface builder is setting autoresizing masks. So if your view container changes dimensions the iPhone can adjust sizes accordingly.
To answer your questions:
1: You can't accomplish the functionality directly with interface builder, You can setup your interface but then you'll have to write the logic in the controller to achieve that functionality.
2: This you can accomplish in interface builder. You add the textField to the footerView of the tableview, and then the text field will always remain at the bottom of the tableView no matter what is displayed in your table.
I have a UITableView as a subview in a ScrollView with other widgets around like a button. I'd like to put the button always at the end of the ScrollView and I'd like to have the UITableView to show dynamically more section. How and where shall I determine the Table size, correctly set it and visualize it?
From Interface Builder it seems that I can only set static size to the TableView (which of course limits the number of sections visible) and stick the button position to the bottom whether a rotation happens.
If you have only few simple controls after the table then I'd suggest putting them to the table itself and get rid of the unhealthy (in my opinion) combination of table view inside scroll view.
You might add the button you are talking about to the table's footer.
It may be done in the Interface Builder (drag-n-drop the button to the bottom of the table view) or in the code ([tableView setTableFooterView:myButton];).
If your button should be smaller that table's width then put it inside UIView and locate as you need.
You can also add table header in a similar way...