views:

428

answers:

2

EDIT: I originally asked this question in regards to general view resizing, but I realize now that it's something much more specific to tableViews.

Say that a tableView originally has a frame of (0 0, 320 460), i.e., it fills an entire iPhone screen. In order to resize the tableView's height and animate the resize, I map the following code to a button:

[UIView beginAnimations:@"Animation" context:nil];
[UIView setAnimationDuration:3];

CGRect rect = self.table.bounds;
rect.size = CGSizeMake(320, 200);
self.table.bounds = rect;
self.table.center = CGPointMake(160, 100);

[UIView commitAnimations];

This code will animate the table's height down, BUT...before any animation happens, the table will clip off all of the table cells that won't fit in the new bounds. So, given a tableView that originally fits 10 rows, the animation code above will cause this sequence of events:

  1. The tableView removes the bottom 5 rows immediately. Note that it only removes the rows - the tableView's background still extends to the bottom.
  2. The tableView animates the height change for the rest of the table as expected.

This is not the behavior I am looking for. Instead of clipping the bottom 5 rows immediately, the tableView should keep its rows in place while the bottom edge of the table just animates upwards.

Based on the behavior I'm seeing, it seems that the tableView is getting some sort of message to refresh its rows immediately after it finds out that its bounds is going to change. Can someone shed some light on this behavior and how I could avoid it?

A: 

Did you try changing the bounds and center within the animation block.

I don't know about this specific case but ISTR having to do similar before. The relationship between frame, bounds and center can be frustrating at times.

Phil Nash
Yep, tried that and it has the same effect as just changing the frame (table cuts the bottom half out before it animates). I have a feeling it has to do with the scrollView's contentSize but haven't been able to figure anything out.
iPhoneToucher
+1  A: 

The bounds property of a view defines the internal coordinate space of the view. If you are changing the size and/or position of the view, you should only change the view's frame. Theoretically, the bounds property could define a totally arbitrary coordinate space disconnected from the view's enclosing frame and UIKit is seemingly designed to support that distinction. In practice I don't think I've ever seen it work that way in UIKit (the bounds.size is always the same as frame.size and bounds.origin is always {0,0}), but that's the distinction being made there and it's important to remember - especially if this behavior ever changes in the future.

I'm not certain that simply changing the code to modify the frame instead of the bounds will solve the issue, but I recommend starting there. If that doesn't solve it, then the problem is probably that the tableview is immediately removing the rows which will become invisible with the new frame, so if that's the case, it's possible that the only solution would be to do the animation yourself by setting up a simple NSTimer-driven routine that slowly changes the frames size/position over time thus creating the illusion you want in spite of the tableview's optimizations or interactions with Core Animation.

Sean