Question

We have a UICollectionView with a custom layout very similar to UITableView (it scrolls vertically). The UICollectionView displays only 3 cells simultaneously, with one of them being the currently active cell:

[ 1 ]
[*2*]
[ 3 ]

(The active cell here is #2.) The cells are roughly 280 points high, so only the active cell is fully visible on the screen. The user doesn’t directly scroll the view to navigate, instead, she swipes the active cell horizontally to advance to the next cell. We then do some fancy animations and scroll the UICollectionView so the next cell is in the “active” position, thus making it the active one, moving the old one away and bringing up the next cell in the queue:

[ 2 ]
[*3*]
[ 4 ]

The problem here is setting the UICollectionView’s offset. We currently set it in a UIView animation block (self.collectionView.contentOffset = targetOffset;) along with three other animating properties, which mostly works great, but causes the first cell (the previously active one, in the latter case, #2) to vanish as soon as the animation starts running, even before the delay interval completes. This is definitely not ideal.

I’ve thought of some solutions, but can’t figure out the best one:

1. Absurdly enlarge the UICollectionView’s frame to fit five cells instead of three, thus forcing it to keep the cells in memory even if they are offscreen. I’ve tried this and it works, but it sounds like an awfully dirty hack.

2. Take a snapshot of the rendered content of the vanishing cell, put it in a UIImageView, add the UIImageView as a subview of the scrollView just before the cell goes away in the exact same position of the old cell, removing it once the animation ends. Sounds less sucky than the previous option (memory-wise, at least), but still kinda hacky. I also don’t know the best way to accomplish this, please point me in the right direction.

3. 1. Switch to UIScrollView’s setContentOffset:animated:. We actually used to have this, and it fixed the disappearing cell issue, but running this in parallel with the other UIView animations apparently competes for the attention of the main thread, thus creating a terribly choppy animation on single-core devices (iPhone 3GS/4). It also doesn’t allow us to change the duration or easing of the animation, so it feels out of sync with the rest. Still an option if we can find a way to make it work in harmony with the UIView block animations.

   2. Switch to UICollectionView’s scrollToItemAtIndexPath:atScrollPosition:animated:. Haven’t tried this, but it has a big downside: it only takes 3 possible constants (that apply to this case, at least) for the target scroll position: UICollectionViewScrollPositionTop, UICollectionViewScrollPositionCenteredVertically and UICollectionViewScrollPositionBottom. The active cell could vary its height, but it always has to be 35 points from the top of the window, and these options don’t provide enough control to accomplish the design. It could also potentially be just as problematic as 3.1. Still an option because there might be a way to go around the scroll position thing that I don’t know of, and it might not have the same issue with the main thread, which seems unlikely.

Any help will be greatly appreciated. Please ask if you need clarification. Thanks a lot!

Answer 1

I went with #2. Here’s the snippet that does the rendering and storing:

UIGraphicsBeginImageContext(theCell.bounds.size);
[theCell.layer renderInContext:UIGraphicsGetCurrentContext()];
UIImage *renderedCellImage = UIGraphicsGetImageFromCurrentImageContext();
UIGraphicsEndImageContext();

The rest of the method was pretty much as I described above, with one caveat: this has to be done before the image is actually used and on a background thread, because rendering can take up to 1 full second on an iPhone 4. Hope this helps somebody.