current community

your communities

more stack exchange communities

company blog
Stack Exchange Inbox Reputation and Badges
tour help
stack overflow careers
Sign up ×
Stack Overflow is a community of 4.7 million programmers, just like you, helping each other. Join them, it only takes a minute:
up vote 4 down vote favorite
1

tl;dr

When deleting a section in a UITableView while the scroll offset is somewhere in the middle of the table the flow of animation goes like this -

  1. The contentOffset is set to (0,0) immediately (no animation, just pops up)
  2. The section fades away nicely

I'd like to make this animation flow a bit better - fade away the section and only afterwards (or simultaneously in a smooth way) scroll the "dead zone" of the table back up.

A bit more explaining

I'm using NSFetchedResultsController as a data source for UITableView to display rows and update the table when changes occur in the NSManagedObjectContext - like this (I removed unrelated code) -

- (void)controller: (NSFetchedResultsController *)controller
   didChangeObject: (id)anObject
       atIndexPath: (NSIndexPath *)indexPath
     forChangeType: (NSFetchedResultsChangeType)type
      newIndexPath: (NSIndexPath *)newIndexPath {

    UITableView *tableView = self.tableController.tableView;
    switch(type) {
         ....
         NSFetchedResultsChangeDelete:[tableView deleteRowsAtIndexPaths:@[indexPath] withRowAnimation:UITableViewRowAnimationFade];
         break;
         ...    
    }        
}

I got all the boilerplate of controllerWillChangeContent and controllerDidChangeContent, the result of this code is that if all the rows in a specific section are removed - the section is also removed.

The problem (as I specified in the tl;dr section) is that the animation doesn't work as expected - If the section removal happen while scrolled half-way into the removed section, the scroll content changed immediately and the section fades away, which looks pretty broken.

Anyone ever stumbled on a situation like this? I'm sure I can narrow it down to a generic problem without using NSFetchedResultsController, that's jus the code I'm currently using.

I'd gladly add more information if needed.

Thanks!

Update 1

So after a bit playing with the contentOffset manually I can get something partly working when doing this flow -

  1. When the NSFetchedResultsController calls controllerWillChangeContent I save the UITableView contentOffset (before beginUpdates)
  2. When the controllerDidChangeContent is called and right after I call endUpdates I save the contentOffset of the table (this is the offset that wasn't animated)
  3. I scroll back to the original contentOffset I saved in part 1 and use [tableView setContentOffset:offsetAfterEndUpdates animated:YES] to scroll to the new offset

This cannot be the best solution / what Apple ment.

share|improve this question
2  
the normal tableView behavior is: The contentOffset remains as it is (if possible), else it is animated to the new (smaller) value. Within the same Animation-Block the Section/Rows are removed with the specified UITableViewRowAnimation. So Either the NSFetchedResultsController is messing up this behavior or some of your code does. – Jonathan Cichon Jun 10 '13 at 9:32
    
That's interesting, I'd take a closer look at the code and see if I mess the default animation somehow – Nimrod Gutman Jun 10 '13 at 9:43

3 Answers 3

up vote 0 down vote

A UITableViewDelegate is also conform to UIScrollViewDelegate protocol so you could delay that section removal action to 

- (void)scrollViewDidEndScrollingAnimation:(UIScrollView *)scrollView
{
    // try to perform your action here, 
    // for instance you could re-attach your NSFetchedResultController delegate here
}
share|improve this answer
    
That seems a bit too hacky for being the right way – Nimrod Gutman Jun 10 '13 at 9:40
up vote 0 down vote

One approach that works (at least in my experience) is to a) delete the section and b) don't delete the individual rows.

For reference, take a look at the TLIndexPathUpdates initializer in TLIndexPathTools. It calculates batch updates and I think it works well for the scenario you've described.

share|improve this answer
up vote 0 down vote

Okay!

So after intensive digging I found that the problem lies in my code (like I was commented right after posting). Was pretty hard to find but somewhere between the beginUpdates and endUpdates I change the UITableView footer view, that messes with the contentOffset animation.

So that's it, my fault, not Apple.

Thanks for the help Jonathan Cichon!

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.