Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>You are re-using the same instance of a table view controller for the "Master" table, but you are sending it messages in what appears to be the wrong order. </p> <p>You push the controller like this:</p> <pre><code>if (!self.masterViewController) { self.masterViewController = [[MasterViewController alloc] init]; } self.masterViewController.objects = self.masterObjects[indexPath.row]; [self.masterViewController.tableView reloadData]; [self.navigationController pushViewController:self.masterViewController animated:YES]; </code></pre> <p>If you simply swap around the reloadData and push lines, then your problem disappears.</p> <p>I'm not entirely sure what is happening here, but I <em>think</em> the problem is that, once the master controller is popped, it doesn't have any frame of reference (pun intended!) to calculate the appropriate content size when you reload it, so it probably isn't caching the content size for this new height. </p> <p>Then, when the view is pushed, the scroll view suddenly has a context again, it knows it has recalculated and so uses the cached content size. That is the impression I get (as you did) from the stack trace, anyway. The first table you choose is always fine since there isn't an old size available. If you'd made this with storyboards you would be instantiating a new Master controller each time and you'd never have noticed a problem. </p> <p>As for why autolayout makes any difference, well, again I'm only guessing and hand-waving here, but under autolayout everything happens a lot later on in the view controller lifecycle than it does under explicit layout. If you have autolayout all the way down, then in a view with no superview (and therefore no constraints on its size) autolayout is not able to work out what size things should be. It's probably a bug, but the workaround is trivial enough and as I say, typically when pushing new view controllers onto a navigation stack you'd initialise new ones, and they'd go away when they were popped, so you'd never see this. </p>
    singulars
    1. This table or related slice is empty.
    1. POWhy does auto layout in table view cells cause the table's content size to be incorrectly changed?
      singulars
      1. PTQuestion
    1. PTAnswer
    1. This table or related slice is empty.
    1. USjrturton
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. POWhy does auto layout in table view cells cause the table's content size to be incorrectly changed?
      singulars
      1. PTQuestion
    1. This table or related slice is empty.
    1. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    1. COIt's odd that reloading it after it's pushed would fix some of the issues, as I thought that reloading it *before* pushing into view makes more sense. It's also odd that doing it this way makes Stack Trace Type B never occur, which I had previously assumed would always occur. So maybe Type B was also part of the problem (I do see the word "oldSize" once in it on Line 6). As far as creating a new view controller every time, maybe you're right, and I should do that instead to avoid all this. I just thought that changing its data would be more efficient than initializing a new one every time.
      singulars
      1. PO
      1. USuser2129800
    2. COI'm a bit hesitant about making your answer the accepted one though, since I don't think it has completely resolved the issue. This is because **(1)** If I change animated to "NO" when pushing the table into view, the problem comes back again. **(2)** Even though the content size is now being correctly changed, Stack Trace Type C is still occurring. For example, when I do my Modal test, the content size is still changed 3 times when it appears and disappears. I don't think this should be happening if the issue was truly resolved, even if the changes happen to be setting it to the correct size.
      singulars
      1. PO
      1. USuser2129800
    3. COI know what you mean; I freely admit to most of this being guesswork. But don't concern yourself too much with how often a view lays itself out; that's UIKit's problem, not yours. Put a breakpoint on viewWillLayoutSubviews and you'll see it happen quite often. I think my main point was that there is probably an issue with a scroll view determining the correct content size to use when it doesn't have a superview - scroll views under Autolayout are a bit... interesting.
      singulars
      1. PO
      1. USjrturton
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload