7

How to make a UIStackView re-distribute it's sub-UITableViews while the stackView is inside a scrollview?

My layout hierarchy is based on the official documentation from apple about Dynamic content for StackViews

 - UISCrollView
   - UIStackView
     - UIView A
     - UIView B
     - UIView C
     - UITableView X
     - UITableView Y
     - UIView D

The constraints are set as documented. The initial layout of the StackView is correct showing all visible subviews. When forcing the regular views to expand beyond the screen's height, scrolling is working as expected. Also when viewing the layout in the storyboard, everything stacks as expected.
At this point the UITableViews are empty. As soon as I add content to the tableView the problem appears.

The problem
When I dynamically update the TableView's by calling .reloadData() on both of them I see their content appearing. (thanks to this answer about non-scrolling tableViews) but the UIStackView is not stacking the UITableViews.

  • UIView D is stacked below UIView C
  • UITableView X and UITableView Y also stacked below UIView B

My guess is that I need to invalidate the stackview, or somehow get it to redistribute it's subviews. How can I do this?

enter image description here

Community
  • 1
  • 1
Tom Bevelander
  • 1,686
  • 1
  • 22
  • 31

1 Answers1

7

First, a warning:

What you're trying to achieve is not really standard iOS behavior. You should first consider a different approach like creating a single grouped table view with multiple sections. You can implement custom views inside your table view as section headers or footers.


Now if you really wanna go with your original approach...

... for some important reason you should be aware that a table view doesn't have an intrinsic content size by default. Thus, you need to tell the table view how tall it should be because otherwise it will only shrink down to a zero height.

You can achieve this by either subclassing UITableView and overriding its intrinsicContentSize() as Rob suggests in this answer to a similar question.

Or you add a height constraint to each of your table views and set their constants dynamically in code. A quick example:

  1. Add both your table views to a vertical stack view in Interface Builder.
  2. Give both table views a leading and a trailing constraint to pin their left and right edges to the stack view.
  3. Create outlets for your table views in the respective view controller:

    @IBOutlet weak var tableView1: UITableView!
    @IBOutlet weak var tableView2: UITableView!
    
    @IBOutlet weak var tableView1HeightConstraint: NSLayoutConstraint!
    @IBOutlet weak var tableView2HeightConstraint: NSLayoutConstraint! 
    
  4. Override the updateViewConstraints() method of that view controller:

    override func updateViewConstraints() {
        super.updateViewConstraints()
        tableView1HeightConstraint.constant = tableView1.contentSize.height
        tableView2HeightConstraint.constant = tableView2.contentSize.height
    }
    
  5. Now whenever the content of any of your table views changes (e.g. when you add or remove rows or change the cell contents) you need to tell your view controller that it needs to update its constraints. Let's say you have a button that adds a cell to tableView1 each time you tap it. You might implement its action like this:

    @IBAction func buttonTappen(sender: AnyObject) {
        // custom method you implement somewhere else in your view controller
        addRowToTableView1DataSource()
        // reload table view with the updated data source
        tableView1.reloadData()
        // triggers an updateViewConstraints() call
        view.setNeedsUpdateConstraints()
    }
    

tl;dr:

A UITableView isn't intended for use without scrolling enabled and thus you always need to explicitly set its height when its contents change - may it be using constraints or by overriding the table view's intrinsic content size.

Community
  • 1
  • 1
Mischa
  • 15,816
  • 8
  • 59
  • 117
  • Thank you @Mischa. Coming from Android this was a though one! I did start out with a single table view as you suggest. It got so complex that I decided to give the stackview-setup a try. In my case the tables have a limited maximum amount of rows (4 and 14) so performance should be fine. Huge thanks for the elaborate answer! – Tom Bevelander Sep 05 '16 at 00:24
  • I see what you mean: You get a giant `tableView(_:cellForRowAt:)` method with lots of switches or if-statements for the different `indexPaths`. In this case your approach might even be a neater solution. However, your setup still looks manageable with a single table view to me: You could place A, B and C inside a stack view and set that stack view as the first section's header. Return D as the second section's footer. Now all you need to do inside `tableView(_:cellForRowAt:)` is to distinguish between section 1 and section 2 which correspond to the table views 1 and 2 in your current setup. – Mischa Sep 05 '16 at 09:23