iPhone Pull to Refresh

There are several ways to implement Pull-toRefresh on iPhones. The best method that I have found so far is Leah Culver's technique. I especially like it because all you have to do is add PullRefreshTableViewController.h and PullRefreshTableViewController.m to your project and subclass them in your UITableViewController. You should also add the the arrow.png image included with the code or replace it with your own image. This technique should be included in Apple's Sample code.

iPhone Pull to Refresh

Ever since Tweetie 2, the pull-to-refresh paradigm has been a hot feature for iPhone applications. The idea is that you can pull down on a list of items to refresh them. This saves you from needing some sort of "refresh" or "reload" button. Nice!

For the upcoming V2 of the Plancast iPhone app we really wanted to replace the current "reload" toolbar item with the pull-to-refresh style. However, the existing open source pull to refresh examples such as Three20's Pull to Reload and EGOTableViewPullRefresh are a little too complicated for my taste. Heck - this should only require one file!

So here it is... a very simple pull-to-refresh:

PullToRefresh

All you need to do is add the .h and .m files to your project and subclass them. I've added a bit of a hack to make pull-to-refresh work with tables that have multiple sections (like Plancast).

There's even a built-in demo so you can try it out right away.

see iPhone Pull to Refresh - Leah Culver's Blog

The Daily done better

Here is how Loren Brichter would do "The Daily", It is faster and more fluid.

He also "created" the fastest way to scroll UITableViews. His solution:

Pre-blend of course… with CoreGraphics into your own view. If you blend your stuff together into a single static view on demand (e.g. when a table view moves a cell onscreen), it’s a little bit more expensive for the first frame, but every frame after that CoreAnimation is just dealing with one big, opaque texture… which it loves. It’s more than just the blending too. If you think about what is happening in terms of overdraw, having one big view per table cell is a big win because CoreAnimation will only touch a single given pixel on the screen once rather than multiple times (potentially, depending on how much overlap your old view hierarchy had).

Fast Scrolling in Tweetie with UITableView

DECEMBER 12, 2008

Scrolling is the primary method of interaction on the iPhone. It has to be fast. Ithas to be fast. More than a few developers have asked me how I do it inTweetie, so I figured I would share a really fast and really clean technique people can adopt in their own apps.

The Solution

Cutting to the chase, here’s the secret: One custom view per table cell, and do your own drawing. Sounds simple? That’s because it is. It’s actually simpler than dealing with a ton of subviews of labels and images, and it’s about a bzillion times faster (according to my informal tests).

Why it’s Fast

Much like on Mac OS X, there are two drawing systems on the iPhone. One is CoreGraphics, the other is LayerKit CoreAnimation. CoreGraphics does drawing on the CPU, CoreAnimation does drawing on whatever it thinks is fastest - most likely the GPU.

The GPU on the iPhone hates blending, that’s why Apple recommends that you keep as many of your views opaque as possible. Sometimes you have no choice - if you have a label over an image you are forced to make the label transparent otherwise you get a big ugly block around your text.

What’s a developer to do? Pre-blend of course… with CoreGraphics into your own view. If you blend your stuff together into a single static view on demand (e.g. when a table view moves a cell onscreen), it’s a little bit more expensive for the first frame, but every frame after that CoreAnimation is just dealing with one big, opaque texture… which it loves. It’s more than just the blending too. If you think about what is happening in terms of overdraw, having one big view per table cell is a big win because CoreAnimation will only touch a single given pixel on the screen once rather than multiple times (potentially, depending on how much overlap your old view hierarchy had).

The Code

I put together a small example project showing off this technique. It’s a simple scrolling list of cells with some text but draws the text using two different fonts, much like the Address Book Contacts list on the iPhone (regular and bold fonts). The technique is extensible to pretty much any style cell you need - I use the same thing in Tweetie and draw the chat bubble, text, and avatar all together into a single view.

There is one handy class that you can use for everything, see:ABTableViewCell.h and ABTableViewCell.m in the full example project here:FastScrolling.zip.

It doesn’t help that Apple doesn’t have any good examples on how to get good scrolling performance. The one table view example I checked (a while ago, it may have been updated) was absolutely horrible in terms of scrolling performance. Horrible.

If you wanted to know why Tweetie is so fast, now you do. It’s an incredibly simple technique and should be very easy to adopt.

Update: It looks like Apple has in fact updated the example code. Check out the fifth example in their TableViewSuite.