When the app store opened, I downloaded several Twitter clients. Each was interesting in their own right, but I couldn’t use any of them because of one reason: the scrolling performance. I didn’t get why everyone’s scrolling was not as smooth as any of the built-in iPhone applications. For me, it made the apps frustrating to use, to the point that I just never used them.

[appstorelink]:http://itunes.apple.com/WebObjects/MZStore.woa/wa/viewSoftware?id=294887301&mt=8

A Simple Proof
—

As an experiment, I wanted to prove that I could make something that scrolled as good as the Apple-made stuff. I had already done other samples using the Twitter API as part of Blueprint at Yahoo! as well as in a Widget for Konfabulator I worked on but never finished. So I figured it would be fairly quick to throw something together.

I wrote a simple web fetcher and then did a rudimentary list. Originally, it was completely a navigation based app. You’d get a list of items such as ‘With Friends’, ‘History’, etc. and click those and get the listing of 20 tweets (the default that you get with the API). It was at this point that I started messing with getting the scrolling fast. In the end, it was smooth as silk. But I also didn’t have features such as the current balloon look and clickable links and @names.

The clickable links took me quite a while to get to work. I spent much time working on line breaking and making sure it was as efficient as it could be, using Instruments to find and eliminate bottlenecks.

After that, I had something that could line break beautifully and yet it still scrolled incredibly fast. Implementing the balloon look however, did slow it down a bit, but again I spent a lot of time trying to cache and get things to the point that you see it today.

But even after all that, there was still tons to do. I mean, it was really just something to prove to myself I could do this. But at this point, I realized I was onto something real here and could really build something exciting. But there were plenty of competition out there. Why build another Twitter app? I wasn’t really sure, but I kept going anyway to see where it took me. By the time I got to the end, I knew I had something big on my hands.

Making It Real
—
For the next few weeks I worked pretty much 24/7 getting things to cache properly, push things off onto threads as much as possible, use a real database, etc. and make sure that things just worked correctly. Despite the simplicity of what Twitter is, making an application to really behave properly and ensure that things are always as you expect is pretty darn hard. Even something as ’simple’ as clicking a tweet and then iterating your tweets with the up and down arrows in the upper right was interesting. Not because of the iteration of the items, but because you now have yet another view that needs to be aware of state changes in the application. For example, if you favorite something, I needed to make sure that if it was showing elsewhere in the UI the change was reflected. Good times.

I also rewrote certain sections more than once to get things right. The database for example, was originally just a plist, but the more complicated the UI became, the more necessary SQLite was. And that had to be threaded for even more fun. I had also originally started with MGTwitterEngine, but ended up writing my own engine for two reasons:

1. design-wise, MGTwitterEngine didn’t fit with what I needed to to (it was too centralized, I needed many delegates, not just one).
2. I decided to use JSON instead of XML to try to keep the data smaller and simpler to parse. XML really is a pain to deal with.

And since I didn’t find a JSON parser that seemed to be small enough and simple enough to integrate, I wrote one. Admittedly, it’s been something I’ve wanted to do for a while. I’m sure somewhere out there there’s a JSON parser that would have fit the bill, but I didn’t find it in my cursory search of the interweb tubes.

Details, Details
—
You know all those ’standard’ form controls you see in all the Apple applications? Yeah, they ain’t standard. So a bit of time was put into creating my own version of those constructs and making them look and behave as closely to the Apple stuff as I could.

I also needed to handle image uploads and tweet compositions, loading followers so you can help address messages, doing the first run screen, etc. Lots of little things to make stuff right.

And even after I thought I had everything done, I ended up rewriting the messaging section to what you see today. It originally had inbox and sent like the web site, but one of my beta testers suggested a threaded view. At first I was like “man, that’s going to take forever”, but it only took me a day or two to get right. Most of my time in fact was spent drawing the stupid balloons to try and match the SMS app, only this time in delicious purple!

That was the making of 1.0. Right before I handed it over to Tapulous, I also added:

* Flickr upload support
* Re-tweet functionality
* Ability to quit during writing a tweet and come back to where you left off the next time you launch.

I know there are several other thing that people want. I originally did envision adding things like multiple account support, etc. and I see that people also really want to have it save where you last were and not jump to the top when you load tweets. That one actually came up during development and there seemed to be strong arguments on both sides. So I left it as it was, but perhaps Tapulous can add that as an option.

People also have been asking for the ability to tap the status bar and have it jump to the top, but it already does that (the iPhone frameworks do it for you in fact). Perhaps there’s a bug in there that stops it from working sometimes.

So that’s my story, and I’m sticking to it. The best part for me has been seeing people’s comments on Twitter which echo exactly those attributes I held dear in its inception:

* UI speed. It tries its best to not get ’stuck’. It only now gets stuck when it’s loading the table for the first time. I hope.
* Simplicity. It’s not glossy black. It’s just iPhone.
* Power. You can do almost everything the Twitter API allows: follow friends, drill down in a user’s history or followers, search for your favorite terms, etc.

Thanks
—
I want to thank everyone that helped me test the application and suggested features, etc. This includes Arlo Rose, Rob Marquardt, Karl Adam and Aaron Hurley. These people had much input into the end design. Arlo suggested the use of the Tab Bar over the nav-style interface. Karl caused me to go to threaded messages, Rob and Aaron both suggested many different enhancements to make things more user-friendly and do what you’d expect. You can blame Rob in particular for my adding Flickr upload.

Again, thank you all. It was a great project!

First, it’s been approved for sale! But I haven’t seen it show up and sadly I don’t have a link to it. Read on for why.

The main reason the app was delayed so long coming out is because I had been been trying to figure out exactly what to do with it. I might be in a situation soon that will actually prevent me from being able to maintain the application, so I wanted to see if I could find a good stewart for my baby. I’ve chosen to hand the application over to [Tapulous][tap], maker of Tap Tap Revenge, Twinkle, FriendBook, Fortune and Collage, with whom I have a good working relation.

[tap]:http://www.tapulous.com

I think this is going to be great for Tweetsville, as they have better resources at their disposal to help support and grow the application. I also think they have some technology which can help Tweetsville be even better than it is. At the same time, there’s some stuff I did for my app that I believe will benefit Tapulous.

There is no plan to have Twinkle and Tweetsville merge. They are to be separate applications with separate audiences. Twinkle is about locality and the Tapulous network, and Tweetsville is purely a Twitter application.

One of the advantages here for users is that there will be choice. There will ultimately be two versions of Tweetsville. The first will be a paid version currently slated for $3.99. The second will come a few weeks later and will be a free ad-supported version.

I’m confident this will move is the best thing for the Tweetsville app as well as users in the long run. You’ll get more choices and better support than I would have been able to provide on my own. I feel the app is in good hands, as I have a great working relationship with Tapulous (I’m actually doing a little work on Twinkle 1.3 these days too).

So look for it to appear in the App Store on Monday the 10th of November!

**Update** Actually the date is apparently going to be the 12th.

self.opaque = NO;
self.backgroundColor = nil;
self.clearsContextBeforeDrawing = YES;

But all I really needed to do was:

self.backgroundColor = [UIColor clearColor];

Same transparency, and I’m guessing (hoping?) that it might be a bit more efficient (unless of course, the innards look for clear color and effectively do what I used to).

Hey, even if it’s not more efficient, it’s certainly simpler to type and it seems to have the same effect!

Sadly, this is one thing I didn’t figure out on my own, but rather spied in some other sources, but I wanted to throw it out there for ‘all uh yous’.

[site]:http://www.tweetsville.com
[user]:http://twitter.com/tweetsville

I had three goals in mind, in this order:

* Totally responsive, with [glassy scrolling][glassy].
* Embrace the natural aesthetics of the iPhone user experience.
* Use the full power of the [Twitter API][twitterapi].

[glassy]:http://www.fieryrobot.com/blog/2008/10/01/glassy-scrolling-with-uitableview/
[twitterapi]:http://apiwiki.twitter.com

It’s definitely fast and smooth (though admittedly it could be tweaked a bit more), and it looks like a real honest-to-goodness iPhone application. For whatever reason, I thought it would be ideal to do this app using as many standard (or standard-looking) controls as I could. The less custom stuff the better.

But the real beauty is the fact that I cache as much of your Twitter stream as I can get from the API, coupled with the depth of what you can do with this application. You can see your timeline, do direct messaging, see your favorites, history, and replies. You can also see the latest trends and do searches, including advanced searches. It is without a doubt the most powerful Twitter iPhone application I’ve seen to date. Of course, I’ve had my head in the sand for the past 8 weeks!

Will this application change the world? Hell, no. But I think it will definitely make a dent in the Twitter space. And it was fun, which was really my whole main point of writing it. It’s been a long while since coding was fun.

Even with all it does, there is still other things I’d like to do to it to improve the functionality and ease of use beyond what’s there, but there are only so many hours in the day, and I’m burnt out from coding so much. I need a vacation from my vacation!

The real question is: should I even charge for it? I’m currently thinking no, but man, it might really take off, and then I’ll be missing out. If I don’t charge for it, I will likely make the source publicly available. I’ve already got a subversion repository set up and ready for some sources if I do. Or there’s always code.google.com.

I’m hoping this will get submitted very very soon. My last build seems to be pretty stable, and I’m too paranoid to make any real changes now.

Wow, this would be the first thing I’ve ever written and released like this since… Aaron (if anyone remembers that). Again, wow.

Well yesterday, after having to do that two or three times, I finally figured out a bit of a clue. I was having trouble making xcode see the profile. Turns out, you need to have the current target configuration set to the config you are modifying in the info panel or else it just won’t show up. Made all the difference in the world.

And of course I always restart xcode after installing any profiles. Install, restart xcode, then ensure your target is set to the right config, then edit the config. Booyah!

[first]:http://www.fieryrobot.com/blog/2008/10/01/glassy-scrolling-with-uitableview/

It starts much the same, use a single view for your cell and do all your own drawing. The ultimate solution presented here though is to cache the whole damned view contents. Revolutionary? No. Extreme? Yes. But it’s the smoothest I’ve been able to get it for my situation. I’m not yet 100% sure I’ll ship with this thing turned on, but I think it’s a valid approach for you to explore for your own project.

In my case I’m slowed down a bit by database fetches, text layout, and rounded images with shadows. By only following the techniques in my last blog post on this topic it’s actually not too bad. But with this addition it’s a lot better.

It should be noted this should really only be used as a last resort due to the increase in memory required.

In order to use this method, you need to be able to uniquely identify a cell by some sort of ID (in my case it’s an NSNumber).

– (void)drawRect:(CGRect)rect
{
if ( !_item )
return;

UIImage* cached = [sImageCache objectForKey:_item.identifier];
if ( cached == nil )
{
CGRect bounds = self.bounds;

UIGraphicsBeginImageContext(
CGSizeMake( bounds.size.width, bounds.size.height ) );

// DRAW CONTENT HERE

cached = UIGraphicsGetImageFromCurrentImageContext();
UIGraphicsEndImageContext();

if ( sImageCache == nil )
sImageCache = [[NSMutableDictionary alloc]
initWithCapacity:1];

[sImageCache setObject:cached forKey:_item.identifier];
}

[cached drawAtPoint:CGPointMake(0,0)];
}

This is actually more expensive to draw in two ways:

1. It means you are drawing and then blitting, instead of just drawing.
2. The table view caches the contents of cells itself, so technically we’re buffering yet again.

But the advantage is that we have the caches around for more than just the visible cells (which is all UITableView cares about). So when things scroll back into view, they’re absolutely smooth as silk.

This does mean that as views first load in they will be less smooth than the next time they roll into view. If the user typically only scrolls in one direction, you might not see a lot of benefit. So you could decide instead to pre-cache items ahead of where the user is. So perhaps you precache the first 20 items and after that let it cache as they are encountered.

When To Dump the Cache
—

Obviously, memory-wise this is not cheap. How much should you save? When should you flush it?

There are many ways to deal with this:

1. Let the system tell you when to flush. If you get a `didReceiveMemoryWarning` call, just flush the image cache completely.
2. Cap the cache at some number of items and flush it when it gets to that size.
3. Cap the cache at some number of items and drop the oldest item when a new item needs to be added (Least Recently Used).

I’m actually trying out #1 believe it or not. I also flush the cache when the view has its `viewWillDisappear` method called. Why keep it around if you’re not actively flushing.

Another trick is to use a timed cache. Wait for the table view to stop scrolling (possibly by listening for the `scrollViewDidEndScrollingAnimation` delegate method to be called. When called, start a 10 second timer. If the view starts scrolling again, clear the timer. This way, after 10 seconds of real non-interaction, you’ll get the chance to flush the cache. No point holding them around.

A timed cache was what we used in Mac OS X for menus. One of the old stand-bys for measuring ‘performance’ was how fast the menus dropped down as you dragged back and forth in the menu bar. So we used the same basic method: on first appearance, cache the image, and from then on use the cache. And then we’d set a 20 second timer to flush the buffers so we didn’t waste memory. Since then I’ve used this technique a number of times.

Here’s a quick boilerplate for how you could use a timer:

– (void)scrollViewWillBeginDragging:(UIScrollView *)scrollView
{
// the user is scrolling/dragging, we WANT the cache, don’t clear it!
[self.timer invalidate];
self.timer = nil;
}

– (void)scrollViewDidEndDragging:(UIScrollView *)scrollView
willDecelerate:(BOOL)decelerate;
{
// if decelerating, wait until it stops first, else start the timer now.
if ( !decelerate )
{
self.timer = [NSTimer scheduledTimerWithTimeInterval:10.0
target:self
selector:@selector(flushCaches:)
userInfo:nil
repeats:NO];
}
}

– (void)scrollViewDidEndDecelerating:(UIScrollView*)scrollView
{
// We know for sure we’re done, start the timer.
self.timer = [NSTimer scheduledTimerWithTimeInterval:10.0
target:self
selector:@selector(flushCaches:)
userInfo:nil repeats:NO];
}

– (void)flushCaches:(NSTimer*)timer
{
// FINALLY. Flush it.
[MyFancyCellView flushCaches];
self.timer = nil;
}

Anyway, there you have it. Probably the most extreme method to get ultra-smooth scrolling while still using UITableView. Use it wisely.

Is My View Still There?
—

Basically, there’s a comment in the template code that says something like:

// Releases the view if it doesn’t have a superview

This is on the line to `[super didReceiveMemoryWarning];`. Well, this news about your view being released is good, because it means that you can undo what you might have set up in `viewDidLoad`, your go-to place to know your view is there and ready for use. In fact, I always try to do the minimum in any `init` method and save it all for `viewDidLoad`.

The problem is that you don’t really know if it threw the view out. You can’t just test `self.view` as this will recreate the view! So I’ve been using a little trick to help me out:

– (void)didReceiveMemoryWarning
{
UIView* superview = self.view.superview;

// Releases the view if it doesn’t have a superview
[super didReceiveMemoryWarning];

if ( superview == nil )
{
// OK. NOW we can assume view is gone.
}

// Destroy any caches regardless here
}

Essentially I see if the superview was nil before calling the super method. If superview was nil, the view really does go away (unless you have a reference to it of course, in which case things get much more complicated). If the view didn’t go away, you still might want to destroy any caches anyway, as shown above.

When we know the view is gone, I usually unregister any observers I might have installed, since they tend to operate on the view, which will just bring it back into being, which is bad. If the view is hidden, why bring it back into existence if no one can see it? Plus, aren’t we trying to use less memory? It should stay dormant until it’s brought back into the visible world.

Anyway, that’s what I’ve learned to do to ensure that my view is gone and I can tear down virtually everything, as if the controller just got initialized. It sure would be nice if we had a `viewWillUnload` method to catch this for realz instead of what amounts to a best guess.

Other Considerations
—

Even if the approach above worked like a charm, you might have other reasons to keep some data around. I had a situation where I had a view pushed onto a navigation controller that referenced the view underneath. Basically an iterator of the list below it, ala Mail. So I couldn’t throw away all my data structures like I otherwise might have when the view disappeared. So I ended up employing this:

// We can only safely purge the world if we are on top.
BOOL isOnTop = ([self.navigationController topViewController] == self);

And inside the `if (superview == nil)` condition I also checked `isOnTop`. If not, I can’t destroy everything.

Keep in mind that isOnTop can be true even the view was not visible. In a tab bar it might be the top controller on the non-selected tab, for example. In any case, if you’re on top you can safely dispose of all of your data structures, as you know there’s no controllers above you.

So there’s two ways I cope with memory warnings. As mentioned, they probably won’t solve 100% of the needs out there, but it might give you some ideas for you own applications.

[nda]:http://developer.apple.com/iphone/program/

**NOTE:** If you’re not already familiar with how UITableView works, the rest of this might just sound like jibberish. But I think there’s still valid life advice in here, so please read on!

In fact, one of the reasons I even started to write my app was to prove that I could write an app that does super-fast tables. And in my app (which, yes, is still not-to-be-named), I even do my own rich text layout for every cell. And every cell is a different height. Even I was skeptical that I’d be able to pull of fast tables, but it worked out. Phew!

How did I accomplish this? Well, by applying a lot of what I’ve learned over the years. And learning a bit about how UIView performs.

Use Views Sparingly
—

I’m not quite sure what’s going on in UIView. Maybe it’s that all views are backed by Core Animation layers, but drawing using a bunch of views is a sure-fire way to slow yourself down for straight on scrolling performance.

For simple table views (settings, or profiles, etc.) you probably can get away with using views with subviews. But we want smoothness as the user is scrolling through hundreds of items. In these cases, if you need to write a custom cell, you should use one view that draws everything directly.

Use Opaque Views
—

If you have a transparent cell, this can slow you down. If a view is marked opaque, the view system knows it doesn’t have to render the area behind it and blend your view onto it. This seems to make a marked difference at times. I just ran into this myself and switched to filling the view with the background color of the table and it is noticeably smoother now.

Note that this can work against you if you want to use standard cell highlighting, as your item won’t turn blue since the standard highlighting relies on transparency. But it does work great for instances where the items aren’t clickable. In my case, it was a message view modeled after the SMS application.

Be Lazy and Cache Often
—

Quite simply: don’t do anything until you don’t need to do it. And when you do need to do it, try to do it only once.

As I mentioned I render rich text. Sadly, there’s no built-in way to do this at present, so I have to lay the text out myself. This is not really cheap. So I have a layout object that lays itself out and then I keep that object around all pre-calculated. This is very much the way you’d use something like ATSUI or NSLayoutManager. You do the hard work once, then store it off for later. Then when I draw the cell, I just run along the lines of text and render them. I also calculate the rectangles of everything I will draw ahead of time. Then rendering is just a quick operation.

If you are drawing images, try to cache them at the size you’ll render them. If you are resizing them every time you draw them, you’re in for a world of hurt. In my situation, they weren’t too much bigger than my target size and they’re never bigger than a certain size, so I didn’t even bother. But if the images could be any size, it’d be really important to resize and cache them someplace.

Another thing I needed to do was cache the heights of the cells. If you have a table with variable-height cells, the table view will run through every item in the table and ask it how high it is before it renders anything. In my situation, with all the layout I do, that is pretty costly (it can actually take up to 2 seconds on the device). So I cache the heights. As new items come in and go out of my list, I only need to calc the new items, so after the first reload, all subsequent reloads are really fast since I already have the values.

Another cache I use is for the background for my cells for one of my ‘looks’. In this case, I use `[UIImage stretchableImageWithLeftCapWidth:topCapHeight:]` to give me an image I can stretch across the background. BTW, this is one of the most useful image functions in there. It basically takes an image and separates into a piece that acts as an end cap and a stretchable part. There’s effectively a one-pixel band that gets repeated as it stretches. But I digress…

What I ended up doing was taking these images and, because my cells could only be certain heights, as I knew I was using one font size and the cells would be based on the number of lines, there were only a finite number of heights I’d need (I believe 5). So as I encountered the heights, I created a cached version of the stretched image using code like:

UIImage* background = [[self balloonImage] stretchableImageWithLeftCapWidth:0
topCapHeight:35];
UIGraphicsBeginImageContext( CGSizeMake( rect.size.width, rect.size.height ) );

rect.origin.x = rect.origin.y = 0;
[background drawInRect:rect];

image = UIGraphicsGetImageFromCurrentImageContext();

UIGraphicsEndImageContext();

And then I just take that image and store it in the cache. Very simple. I also stored that as the class level so all views can use the cache.

Nothing’s ever free, of course, so keep in mind that if you cache too much, you might find yourself running out of memory. Be prepared to listen to memory warnings via the `didReceiveMemoryWarning` method and dump your cache if needed.

And finally, also keep in mind that the table view only keeps the visible cells around. Every time a cell comes into view, it asks you for a new cell. You can reuse cells, but even that only will get you so much. So don’t assume that once your list has completely been scrolled through that everything is loaded. You cannot rely on such behavior. This piece of information caused me to change my strategy a bit until I arrived at what I am describing here.

How Do You Know What To Cache?
—

Fortunately, I’ve done this for a while, and I know a lot of the gotchas. But no matter how much you know or think you know, the best way to get real answers is to use a tool like Instruments. It is indispensable for finding bottlenecks in your code. For my app, I just kept sampling my application and finding things I should work on. If you aren’t using sampler or something similar, you really should.

Again: indispensable.

What’s Next
—

Next time I might cover performance in general. How to make your applications fast and not impede the user-experience. I’ll also talk about how to handle low-memory. This can be a bit tricky at times.

Until then!

**UPDATE:** Since writing this I’ve sped things up a little bit by going [one step further][update].

[update]:http://www.fieryrobot.com/blog/2008/10/08/more-glassy-scrolling-with-uitableview/