The Three20 Framework: Should You Use It?

July 25, 2010 John Blanco iPhone

I was tuned in to the Three20 framework about 4 months ago just before we were to start work on an app for a pretty well-known sports retailing client. I was impressed with all the “goodies” it provided, specifically the photo browser, dashboard, and persistence system so that I could write an app that continued from where it left off when closed. I planned to have all of this in our new app, so I decided we’d base it on Three20.

There’s not a huge amount of material out there on the framework, so before you start wading through the Three20 documentation, separating the outdated material from the newer stuff, I hope to quickly review my experiences with the framework so you can decide if it’s right for you.

The Good

To start with, there’s plenty of GOOD in Three20. Actually, some of the best benefit is just going through some of the code. It’s pretty well-written and really flexes the iPhone SDK. But apart from that, there’s plenty of great stuff to use right out of the box.

URL Navigation

When you write your own iPhone apps, you may tend to have several areas of your code creating a UIViewController and pushing it on to the navigation stack. If you’re smart, you centralize this code so you can create settings pickers or photo albums in one place, even if you can navigate to them from more than one screen.

Three20 allows you to configure navigation maps that let you navigate easily via special URL’s which take care of displaying the appropriate screen. For example, you can set up tt://profile/photos to open and display a MyPhotoBrowser view controller.

It’s real handy. However, there are some complexities that may ding you later, especially in regards to providing arguments and sequencing several in a row. (All doable but have fun finding out how to do it.)

Useful Helper Methods

Three20 includes a large set of preprocessors, inline methods, and categories that really address the core of what you need to do often with the SDK. I wish a lot of these were in the iPhone SDK actually. Even when I decide not to use Three20, I’ve borrowed a lot of these for my own code (and added quite a few more!) My favorites include TTRectInset, calls that allow you to specify hex colors and, well, a ton more! You’ll just have to check em all out. ;-)

Overall, you’ll be inspired and become completely dependent on what’s in Three20. If you don’t use the library, it’s a great lesson to build your own!

Button Styles

Three20 comes equipped with a set of sample projects. One of those is TTCatalog, a great demo of everything in the library. When you go through it, you’ll find it impossible not to be endeared with the button skinning portion that lets you create buttons that look like they were iPhone native, all with variable sizing, arrow buttons, and more. It’s great work done by the team and easily the most useful part of the system.

TTImageView

Internally, Three20 has a module called TTURLRequest which leverages an even lower-level system to cache data that’s been downloaded. The combination of these two allows for the excellent TTImageView control to exist.

In short. TTImageView lets you to add an image to your interface that is loaded from the web. This is the simple kind of thing that almost every one of us needs at some point and it’s devilishly tricky to write correctly. TTImageView allows you to write this:

_logo.urlPath = @"http://www.raptureinvenice.com/images/logo-text-with-tag.png";


Why write your own? This one works and works wonders.

Views, Views, Views!

Three20 provides you with some pre-built screens that many of us require quite a bit:

• A Photo Browser — Very similar to what’s on the iPhone.
• A Photo Album — Displays multiple images in a grid space. Think: Photos app.
• A Dashboard — A re-implemented iPhone Springboard.

The Bad

Despite all the good stuff, there’s some stuff Three20 just didn’t get quite right. It’s not much, but even if you use Three20 you may want to avoid it.

Stylesheets

This is hard for me to put here because it’s supposed to be one of the sweet spots of Three20. Imagine! CSS! On iPhone! Well, I just don’t feel it’s done right.

For one thing, you can’t specify all of your properties in one place. Say you have a UITextField and you want to specify the text color, font, background color and some other properties. In CSS, all of this is included in one stanza, and it’s kept together. It’s easy to update, too. With Three20, though, you have to specify all of these values in separate places. The code gets bulky and it can get lost, especially because you’re not going to want to write 120 different methods that return a Helvetica Font.

I’ll set some standard colors such as the standard nav bar tint color or standard text color, but I find I really don’t use stylesheets otherwise. You’ll also find CSS simply isn’t as valuable on iPhone because there’s very little repetition going on anyway. It’s too bad, it should be one of the big wins in the framework.

Status Bar Color

This drives me crazy. Three20 decided it would be nice to take over how you set the status bar color for the app. Where once before it was simple, Three20 has made it complex. You have to specify it for every screen, and the default always seems to be gray. Ultimately, until you get it perfectly right, you get the joy of seeing your status bar change from gray to black or translucent as you go between screens. Lame.

To top it off, they don’t document what you need to do real well, so beginners will spend a good chunk of time trying to figure out why their UIStatusBarColor property isn’t working. I only accidentally stumbled on the fact that Three20 has hijacked this system and I’m so glad I did or I’d have spent hours tracking down my problems. ERRGGG!

Lack of Good Documentation

And that speaks to Three20’s biggest problem — the documentation is very poor. You will be completely dependent on the sample apps. And when there *is* documentation, you’ll find it’s often out of date. The forums aren’t exactly bustling, etiher.

Bottom line, if you choose to use Three20, be sure to give yourself enough time to pour through some code and search for the docs you need. And, hey, if you can, contribute some documentation back! :-)

The Ugly

Aside from the bad, some stuff is downright ugly and deserves a callout.

New Project Structure

Three20 recently changed their project structure so that instead of a single Three20 XCode project to include with your app, you now get 7. Now, presumably they separated it this way to remove some dependencies and make builds easier. The problem is that you often need to look through the Three20 code to figure out what’s going on and, well, you never quite know where to look. So you have to open project after project looking for what you need. It was so much easier before.

I hate it.

Table View Controllers

Three20 changes how you use tables, too. They’ve adopted a style where you define your rows in advance, and then the table just uses what you gave it. At first, I found this much simpler. However, there are simply WAY TOO MANY things that become more complex or downright annoying when you do it the Three20 way:

• Customizing individual rows – Forget it, it’s a nightmare.
• Caching/Optimization – You lose the optimized way UITableViewDataSource re-uses rows. It’s gone. So, don’t be using this system if you have hundreds of rows to display.
• Creating new row styles – Brutally obnoxious. The table framework has been over architected. You’ll find that you need to change the framework itself to add new types of rows. Really?

After my team finished work on our maiden Three20 app, we all agreed we wouldn’t use Three20’s table framework anymore. And we’ve been much happier since. U-g-l-y.

UI Persistence

It’s probably unfair for me to put this here. UI persistence is one of the great draws to Three20. Imagine, you get built-in persistence so that when a user closes the app, they start right back where they were later.

Unfortunately, it’s not the easiest thing to use in the world. However, put in some elbow grease and you’ll have it licked. No, the problem is that we don’t really need it anymore with iOS 4. Well, that’s not totally true, with Three20 you can always guarantee you will start where the user left off, regardless of how iPhone manages the lifecycle. But, really, it’s not worth injecting this much architecture into the task anymore.

So, use iOS 4 for your UI persistence, and leave Three20 behind.

My Overall Recommendation

Whether you use Three20 or not depends on what kind of app you need to create. Overall, however, I’d say skip it. You get a lot of useful stuff, but it’s so easy to cull a few ideas out of it and go it on your own that it’s not worth the added risk of running into a Three20 behavior that leaves you stuck to find a workaround. On top of this, the table architecture, UI persistence, and stylesheets are too bulky and too unusable to be polluting your code with.

The two pieces of Three20 I’d create for yourself are the preprocessors and the URL navigation. I’ve created my own preprocessors that go far and beyond what Three20 put in, and they are tailored to the things I want the most. So I no longer need Three20 for it. I recommend you do the same. (One day I’ll post mine perhaps.)

The one condition for which I’d recommend using Three20 is if you have a need for the several views they provide. Instead of writing your own springboard, use Three20’s. The photo browsing views are very well done, too. But, if you only have a need for one or two of these screens, or none at all, it’s more worth it to write your own. Taking a couple days to do it (or find another 3rd party version) is going to be worth the extra time you’ll need with Three20 later.

Conclusion

I hope this review has been helpful to you. If you haven’t used Three20, I recommend you at least check it out for a day or two. Every developer has their own preference. Mine certainly was with Three20 initially, but it just quickly fell out of favor.

And if I’ve misrepresented the framework here, please comment and let me know.

framework, iPhone, review, three20

10 Things Apple Could Do to Make iPhone Development Perfect Is Good Code Impossible?