StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
text
Body
copied!<p>Short, pragmatic answer: Changing <code>UITableViewRowAnimationAutomatic</code> to <code>UITableViewRowAnimationTop</code> solves the issue. No more disappearing rows! (tested on iOS 5.1)</p> <p>Another short, pragmatic answer, since <code>UITableViewRowAnimationTop</code> is said to cause its own issues: Create a new cell view instead of modifying the existing one's frame. In a real app the data displayed in the cell view is supposed to be in the Model part of the app anyway, so if properly designed it shouldn't be a problem to create another cell view which displays the same data only in a different manner (frame in our case).</p> <p>Some more thoughts regarding animating the reload of the same cell:</p> <p><code>UITableViewRowAnimationAutomatic</code> seems to resolve to <code>UITableViewRowAnimationFade</code> in some cases, which is when you see the cells fading away and disappearing. The new cell is supposed to fade in while the old one fades out. But here the old cell and the new one are one and the same - So, could this even work? In the Core Animation level, Is it possible to fade out a view AND fade it in at the same time? Sounds dubious. So the result is that you just see the fade out. This could be considered an Apple bug, since an expected behavior could be that if the same view has changed, the alpha property wouldn't be animated (since it can't animate both to 0 and to 1 at the same time), but instead just the frame, color etc. would be animated.</p> <p>Note the problem is just in the animation's display - if you scroll away and back, everything will appear correctly.</p> <p>In iOS 4.3 the <code>Automatic</code> mode might have been resolved to something other than <code>Fade</code> which is why things work there (as you write they do) - I didn't dig into that.</p> <p>I don't know why iOS chooses the <code>Fade</code> mode when it does. But one of the cases it <em>does</em> is when your code asks reloads a previously tapped cell, which is collapsed, and is different than the current tapped cell. Note the previously tapped cell is always reloaded, this line in your code is <strong>always</strong> called:</p> <pre><code>[indicesToReload addObject:[previousIndexPath_ copy]]; </code></pre> <p>This explains the magic disappearing cells scenario you have described.</p> <p>By the way, the beginUpdates/endUpdates seem like a hack to me. This pair of calls is just supposed to contain animations, and there aren't any animations you are adding in addition to the rows you already asked to reload. All it did in this case is magically cause the <code>Automatic</code> mode to not choose <code>Fade</code> in some cases - But this just obscured the problem.</p> <p>A final note: I played around with the <code>Top</code> mode and found it can also cause problems. For example plugging the following code makes cells disappear funkily:</p> <pre><code>- (void)tableView:(UITableView *)tableView didSelectRowAtIndexPath:(NSIndexPath *)indexPath { [tableView reloadRowsAtIndexPaths:[NSArray arrayWithObject:indexPath] withRowAnimation:UITableViewRowAnimationTop]; } </code></pre> <p>Not sure if there is a real issue here (similar to the one with fading a view in and out at the same time), or maybe an Apple bug.</p>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

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