Nick Farina

Feeds

Thu, 23 Feb 2012 14:06:00 -0800

Here’s an app I whipped up with the help of designer Eric Grossnickle. It has one purpose: to live in your Mac menubar and notify you when things happen on your favorite sites. That’s pretty much it.

You also get a little menubar app with your notification history, read/unread status, and popover content previews (Lion only).

It currently supports Dribbble, Basecamp, Highrise, Github, Beanstalk, Trello, and UserVoice.

If you would like us to support a particular service, cast a vote in our UserVoice forum!

Why Indoor Navigation is so Hard

Wed, 12 Oct 2011 12:13:00 -0700

I wrote a piece for Radar about our company’s approach to indoor navigation with mobile apps.

Remember the days before you could pull your smartphone out of your pocket and get instant directions from your current location to anywhere in the world? It’s kind of foggy for me, too.

Git Is Simpler Than You Think

Wed, 07 Sep 2011 09:23:00 -0700

It was about one year ago that we switched to Git. Previously, we used Subversion, through the Mac app Versions, which (rightly) holds an Apple Design Award.

I made the executive decision to leave our comfy world of Versions because it seemed clear that Git was winning the Internet. There was much grumbling from my teammates, who were busy enough doing actual work thank you very much.

But I pressed forward. We signed up for accounts on Github. We learned how to type 'git push' and 'git pull'. We became more confident. Git is just like any other source control system! But it wasn’t long before one of our devs called me over to look at a…situation.

It might as well have printed PC LOAD LETTER. “Falling back to patching base and 3-way merge?” That does not sound good at all. Or maybe it’s completely normal? I type 'git status'.

“Not currently on any branch?!” Now I’ve done it. We’re going to lose all the work he did today. Sweat is beading up on my forehead. Everyone is watching me to see if I can figure this out. After all, I got us into this mess.

Maintenance Required

Git is not a Prius. Git is a Model T. Its plumbing and wiring sticks out all over the place. You have to be a mechanic to operate it successfully or you’ll be stuck on the side of the road when it breaks down. And it will break down.

By now we all know how to drive Git. We learned it by typing “git tutorial” into Google. We studied guides, how-tos, cheat sheets.

Did you know the top result for “git tutorial” is this manpage on kernel.org? I will give you a gold star if you can read the whole thing without falling asleep.

So instead let’s pull over, open the hood up, and poke around.

The Basics

We’ll run through some basic commands to make a repository for our examples:

~$ mkdir mysite
~$ cd mysite
~/mysite$ echo "<title>All About Cats</title>" > index.html
~/mysite$ git init
~/mysite$ git add index.html
~/mysite$ git commit -m "First commit, added a title."

Now we have a git repository with one file and one commit, that is to say, one “version”. Let’s make a change and commit a second “version”:

~/mysite$ echo "<center>Cats are cute.</center>" >> index.html
~/mysite$ git commit -a -m "Added some text."
~/mysite$ open index.html

With me so far? Good.

The Repository

In Git there is no “client” and “server”. A repository is a repository, no matter if it’s on my machine, your machine, or Github.com.

Each repository lives in a single hidden folder called .git. This is in stark contrast to Subversion which infects your source tree with little .svn folders everywhere.

The .git “repository” is more than just metadata and bookkeeping. It’s everything. All of your source, all your changes, all your branches, all your commit notes with swear words and in-jokes.

Go ahead, delete your index.html. As long as your .git folder is intact, you can reconstruct it:

~/mysite$ rm index.html
~/mysite$ git checkout -- .
~/mysite$ ls
index.html

That would work even if you’d deleted a bunch of subfolders and huge files and whatever. Poof, it’s all back.

This explains why, when you “checkout” (clone) the Ruby on Rails repository from Github, it takes a surprisingly long time. You’re downloading onto your machine, into your new rails/.git folder, the entire history of Ruby on Rails. Every tiny change from David’s initial commit in 2004, it’s all sitting there on your disk.

This troubled me greatly at first. It’s so inefficient! My precious disk space!

And I can only say that disk space turned out to be a non-issue. But it took me some time. Maybe go take a walk outside, look at some trees, and come back later when you’ve accepted it.

User Interface

Now if you’re a curious person, you’ll likely say “Wait. Go back. Where did you get the line ‘git checkout -- .’ from? What does that even mean?”

To which I’ll respond, “I don’t know. I Googled it.”

And this brings us to Git’s greatest shortcoming, which is that Git’s terminology and syntax is fracking inscrutable.

Git’s overloaded, confusing language is absolutely the only part of it that sucks. They meant well. They chose words that sound familiar, like branch, checkout, tag, merge. But they often mean different things. Then you get the feeling that, as features were added and rethought, they just picked new unused words as they went along. Stage, fetch, rebase, remotes.

And because of Git’s explosive popularity, it’s a total Emperor-Has-No-Clothes situation. If you’re anything like me, you probably wondered why you were the only stupid person on the planet who didn’t intuitively get Git already. Even the beloved Github, though unaffiliated with Git, is much the same: as overwhelming as it is awesome.

Ultimately, when you look at Git, you don’t see a product that was “designed” holistically. It’s more like a collection of command-line utilities.

A Collection of Command-Line Utilities

This is a much better way to think about Git, and in fact this is what Git originally was. Git started life as a week-long project of Linus Torvalds to replace the old version control system they were using at the time to manage contributions to the Linux kernel.

You can’t design and build a fully-featured distributed version control system in a week. But you can design your data model. And it had better be really, really simple.

So what’s Git’s data model? To answer that, we need to dig into that mysterious .git folder.

The So-Called “Object Database”

In mysite/.git, there is a subfolder called objects. It should contain these folders and files (edited for clarity):

~/mysite $ find .
./index.html
./.git
./.git/objects
./.git/objects/0d/0321f29f04f734e8d9873e34d9409fe115b496
./.git/objects/23/581023e9850ab48ec5ea6c4c9dcbeb82e76461
./.git/objects/2d/48a74575acab21d702f17f4ecce126b7e34ab0
./.git/objects/5b/853962ae2f41f608428968f8fffbf72f6cec2b
./.git/objects/87/48d7719d7321fad3739fce87ff84b6ded47e8b
./.git/objects/b1/a701e38645a3e60bc17a786cdd9062a15b5a21

These files with mangled-looking names are the “objects” in our database for mysite. An object can be either a commit, a tree, a blob, or a tag. They’re compressed with zlib, but you can extract and examine them easily.

If we were to extract the object 23/5810…, we would see:

<title>All About Cats</title>

…which is the old version of index.html! So that’s a blob, that is, a particular version of one file. If we extract the object 0d/0321…, we get:

commit 227tree 5b853962ae2f41f608428968f8fffbf72f6cec2b
parent b1a701e38645a3e60bc17a786cdd9062a15b5a21
author Nick Farina <n...@gmail.com> 1315106589 -0700
committer Nick Farina <n...@gmail.com> 1315106589 -0700

Added some text.

…which is a commit object (our last commit).

If you’re following along, you’ll notice that you don’t have an object 0d/0321. Your commit will have a different mangled name because your author name and email won’t match mine. You see, the “mangled names” of these files are SHA1 Hashes of their contents. If we computed the hash of the blob <title>All About Cats</title>, we’d get:

23581023e9850ab48ec5ea6c4c9dcbeb82e76461

Recognize that hash from the 23/5810… filename above? Git chops off the first 2 characters of the hash and uses that as a directory name, so we don’t end up with too many of these little files in one place.

Git calls this “content-addressable” to sound fancy, but really it’s just a naming scheme. See, these “objects” have to be called something, so they might as well be named according to their contents.

Content-Addressable

Now if you’re reasonably paranoid, you may ask: “What if two different objects compute the same SHA1 hash code? Won’t this happen someday?”

It turns out you’ll never generate two of the same SHA1 hashes. The chances are miniscule. There’s room for all kinds of flowery comparisons like: You’d have to generate more hash codes than the number of stars in the universe before you’d get two of the same!

But my favorite is from Pro Git: “A higher probability exists that every member of your programming team will be attacked and killed by wolves in unrelated incidents on the same night.”

Commits

A commit represents a complete version of your code. Look again at the object file representing our last commit:

commit 227tree 5b853962ae2f41f608428968f8fffbf72f6cec2b
parent b1a701e38645a3e60bc17a786cdd9062a15b5a21
author Nick Farina <n...@gmail.com> 1315106589 -0700
committer Nick Farina <n...@gmail.com> 1315106589 -0700

Added some text.

This chunk of text contains enough hints to reconstruct the entire contents and history of our repository as it existed in this version.

The hash 5b8539… is the object containing the state of our tree. A tree object is basically a manifest of files and folders (simplified here):

blob 2d48a74575acab21d702f17f4ecce126b7e34ab0  index.html
blob b8ca7d5cba87d5123182375871234a76d6f78ff2  someotherfile.html  <- example 2nd blob
tree 3182375871234a76d6f78ff2b8ca7d5cba87d512  Documentation       <- example subfolder

This represents the filesystem structure at this point in time. Cleverly, subfolders are represented by pointers to other tree objects. Recursion! The “blob objects” then contain the actual file data like <title>All About Cats</title>.

To get the previous version of our repository, look at the “parent” hash beginning with b1a701 (again, different for you). This is the object containing the previous commit.

So just by starting with our last commit object, we’ve explored the entire contents of our repository.

Branches

If we had a thousand objects in our database, it would be pretty hard to guess the hash of our last commit. So we’d better write it down somewhere.

~/mysite$ cat .git/refs/heads/master
0d0321f29f04f734e8d9873e34d9409fe115b496

This is what a branch is: it’s simply the hash of the last commit scribbled down in a file. It’s a clue, a starting point, sometimes called a tip because this represents the tip of the iceberg that is the entire history of the master branch.

And since you can have multiple branches in a repository, we should also remember which one we’re working on right now.

~/mysite$ cat .git/HEAD
ref: refs/heads/master

It’s forehead-slapping simple. Whenever you execute a Git command, it first looks at .git/HEAD to see what our working copy is supposed to be. And that contains a reference to either a branch name or a commit object (that case is a detached HEAD). If it’s a branch name, look at the branch file to see what commit object it is. Then open up the commit object to find all the trees and blobs and parents and it’s turtles all the way down.

Uniqueness

One last thing to ponder. Our objects folder contains 6 files. Three for the first version’s commit object, tree, and blob. And three again for the last version’s commit object, tree, and blob.

If you zipped up your entire mysite folder right now and emailed it to me, I could unzip it and make another change to index.html and commit that change to my local copy on disk. Let’s say I changed the line to say <center>Cats are TERRIBLY cute.</center>.

Now I have 9 files in my objects folder. Three more for the commit I just made, its tree and blob.

I want to share my changes with you. So I zip up the 3 object files you don’t have and email them to you.

Are you ready for this? You take my three object files and just dump them into your objects folder. You don’t have to worry at all about overwriting anything, about losing data, about screwing up your repository, because we’ve already established that these file names are completely unique. Wolves in the night, remember?

You’ve just manually performed a git fetch, which is the safest operation ever because it’s just collecting someone else’s unique commit files and tossing them into to your database.

In my email, I’ll say “My latest commit is 3bd54c.” So you type “git checkout 3bd54c” and boom you’re looking at my latest changes.

If we emailed back and forth a lot, I might want to add you as a remote so that Git does the moving of files around for me. And I might scribble down the latest commit hash that I got from you in a file called origin/master or something. Sound familiar?

Mastery

Octobi Wan Catnobi by

For me, understanding the structure of the object database was my Eureka moment for Git. After that, I could start to understand not just how Git worked, but why.

The best way to get yourself out of a Git disaster scenario is to understand what Git is trying to do for you.

And when you understand how Git works, your Google Power will increase tenfold. How did I know to type “git checkout -- .”? Well I just looked online until I found a command that sounded like it did what I would do myself if I had to write some code to poke around the object database.

There’s a lot more to grok about Git from here. Merging, rebasing, and staging come to mind. But it’s not so hard now; it’s all just a bunch of fancy shell scripts anyway.

An iOS Developer Takes on Android

Mon, 01 Aug 2011 07:42:00 -0700

Recently, we released the Android version of Meridian, our platform for building location-based apps.

We didn’t use one of these “Cross Platform!” tools like Titanium. We wrote it, from scratch, in Java, like you do in Android.

We decided it was important to keep the native stuff native, and to respect each platform’s conventions as much as possible. Some conventions are easy to follow, like putting our tabs on the top. Other conventions go deep into the Android Way, like handling Intents, closing old Activities, implementing Search Providers, and being strict about references to help the garbage collector.

Now, our platform leverages HTML5 (buzzword, sorry) in many places for branding and content display, so we got a fair amount of UI for free. But there was much platform code written in Objective-C that needed translation into Java, such as map navigation, directions, and location switching.

So, we rolled up our sleeves, downloaded the Android SDK, and got to work.

Development Environment

Apple has made it pretty easy to start writing iOS apps. Of course, Step One is “Buy a Mac.” Easy! Then just download the free Xcode Installer from the Mac App Store, and start writing code when it’s done.

Android is a bit more involved. You can download the SDK easily, but to actually start writing code, you’ll want to setup Eclipse and install Google’s ADT Plugin.

If you want to waste a week or so playing around and not getting work done, you could explore the many tempting alternatives to writing Java in Eclipse. You could download Netbeans, or write in Scala, or finally start learning VIM.

But let’s assume you are on a deadline and want to do things the way that Google endorses. The first thing you’ll need to do is accept the reality of Eclipse.

You’re going to just hate Eclipse. You’re going to hate it with the heat of a thousand suns. It’s going to feel slow and bloated and it won’t taste like real food.

Eclipse is a world unto itself. It’s the IDE to end IDEs. Consequently, it has many abstract-sounding concepts you’ll have to learn. There are Workspaces, and Perspectives, and Run Configurations. And Eclipse itself is just an empty shell of sorts; all non-trivial functionality is provided via a complex network of interdependent Plugins, similar to Linux distributions. Come to think of it…

Of course, IDE weirdness isn’t unique to Eclipse; Xcode was pretty damn weird at first too, and it’s getting more meta with each release (Schemes, anyone?).

The upside is, after acclimating to Eclipse, you’ll enjoy some seriously amazing, productivity-boosting code completion, refactoring, and automatic fixing. It’ll basically write your code for you.

A great way to get comfortable with Eclipse is to spend a couple hours, and I’m being dead serious, tweaking the hundreds of options and checkboxes and fiddly things in the Preferences section.

Again, being serious here, I felt a lot more comfortable and familiar and happy with Eclipse after getting to know it this way. Does this mean that other programs should expose every conceivable preference imaginable? Jesus, no. Are you crazy?

The Java Language

Java is a high level programming language. It’s unproductive to have an opinion about it. Instead, consider how Android uses Java.

This is how you do something on a background thread. This is how you listen for events (it’s actually just like a delegate in ObjC). This explains the lifecycle of Activities, which are exactly like UIViewControllers in Cocoa.

Overall, the Android frameworks are very well designed and consistent, and the API works harmoniously with the Java language. It’s actually similar enough in the fundamentals that our app has almost the exact same class structure on Android as on iOS.

And the code ended up looking strikingly similar as well. Here’s a snippet of ObjC from our app that draws an arrowhead. Hover your mouse over it to see the Java version.

Freaky, right? A lot of our source is like that.

Debugging

Now that you’ve written some code, you’ll want to try running it. In Apple’s world, we have the iOS “Simulator.”

It’s called a Simulator because it’s phony (ha!). It’s not the real iPhone OS. When you run your app “in the simulator,” Xcode compiles your app into a desktop application, and runs it natively on your Mac. If you look in Activity Monitor, you’ll see your app right there, running alongside Mail and iCal and iTunes.

The downside to the Simulator is that it doesn’t exactly replicate the iOS environment. And your code isn’t the same either; it must be compiled for x86/64 instead of ARM, so there’s no guarantee things will work the same on an iOS device.

The upside to the Simulator is that it’s not an “Emulator.” What’s an Emulator?

Behold, the Android Emulator. Its goal is noble: to run your app on the complete unaltered Android OS inside a virtual machine that executes ARM instructions.

What is the primary quality of the Android Emulator?

I thought the iPhone Simulator was a terrible idea when I first heard of it, until I remembered that we built the exact same thing for Windows Mobile back in the day, because the Windows Mobile Emulator was so goddamn slow.

It takes the Android Emulator ~2 minutes to boot up on my perfectly-modern machine. But what really hurts is the edit/debug cycle. Every time I change a bit of Java and need to rerun the app, it takes about 30 seconds to redeploy and start up in the Emulator. Compare that to 5 seconds on the iOS Simulator. It may not sound like much but remember you’ll be doing this hundreds of times throughout your day.

Fortunately, it turns out to be much quicker to deploy and boot up your app on a physical device over USB. So trust me, just go out and buy an Android phone. Better: buy a few of them to test against fragmentation.

Not that fragmentation is unique to Android; it’s just exaggerated a lot in the media. We need quite a few iOS devices in our lab too. One tiny unexpected OS or device difference can bring your app crashing down, on any platform.

UI Design Tools

For laying out widgets on iOS, we have Interface Builder.

Your experience with Interface Builder may differ from mine, but I’ve learned to use it very sparingly. It’s great when you want to create static layouts with precision. But for dynamic content, especially UITableViews, it tends to make things more complex than they would be in code. Especially when you come back after a while and forget all the little dependencies between your Controller and your XIB.

On Android, you can create UI layouts in XML.

It’s a bit like HTML, except it’s not HTML. It has a basic styling system that’s kind of like CSS, except it’s not CSS.

Lots of well-meaning developers in positions of power have tried to reinvent HTML and CSS over the years. Mozilla created XUL for cross-platform UI in Firefox. Adobe created MXML for Flash. Microsoft created XAML for Windows.

I myself am guilty of creating my own XML-based layout system for Flash called Bent, back when I had too much free time. So I can tell you that inventing these systems is the most fun you will ever have as a developer. It feels like you are creating the One True Framework, and once it’s complete everyone will embrace it and get excited about it and learn it and build on it, and hold you up and sing epic poems about your genius!

But the reality is, it’s not HTML and CSS and so it’s another thick layer of stuff that you have to learn and understand and fight with when things don’t work like you expect.

On the plus side, you can preview your XML at design-time in a nice visual editor, much like Interface Builder:

Which is pretty grand.

Now, technically you could write everything in Java, just like on iOS you can eschew Interface Builder entirely and write only Objective-C. But you’ll find that when you scour the Internet for how to do a thing on Android, you’ll end up needing to understand all these XML formats anyway just to understand code samples on the web.

But it’s not really that bad, because you also get…

A Real Box Model

Here’s a list item on iOS that represents a search result.

And here’s just a snippet of the ObjC that renders that item:

Talk about a bag of hurt. You could create the initial layout in Interface Builder of course, but then you’d have to kiss that silky smooth scrolling goodbye. Maybe in the future when iOS devices are blazing fast.

As humans, we don’t typically think “The title should be positioned at 30 pixels by 40 pixels, with a maximum height of 35 pixels.” Instead, we think “The title should be above the subtitle, and to the right of the thumbnail image, and have at most 2 lines.”

Android has a system of layout containers (similar to HTML) that let you describe where content should be, relative to everything else. Here’s a similar snippet from the same search result in Android:

Now, you’ll have to study up on all these layout containers like FrameLayout, LinearLayout, RelativeLayout, and learn all their quirks, but in the end you’ll get a very natural, flexible UI layout system.

The best part is that it’s zero-effort-easy to make layouts that automatically resize for portrait/landscape device orientations and varying screen sizes. This is in stark contrast to the absolutely primitive springs and struts system in Cocoa/iOS.

But here’s the thing about the simplistic layout system in iOS that I just mocked, it turns out to be a reasonable compromise when you consider…

Animation

The thing to realize about Android is that it used to look like this:

It was conceived and designed during the pre-iPhone days of Blackberry and Windows Mobile, and the influence of those platforms goes very deep into the Android OS.

For instance. The rendering system, that is, the method by which UI widgets like menus and buttons and such get painted on the screen, is primarily software-based.

What does that mean? Let’s take the screenshot above as an example. If you pressed the Down key, you would expect the “Homepage” entry to be selected instead of “Go to.” So you press the Down key. This causes an “invalidate,” meaning, “please repaint the screen.” So the screen is cleared, then:

The OS redraws the status bar at the top
The WebView redraws the Google.com website
The Menu draws its translucent black background and border
All the menu text is drawn
The blue gradient highlight is drawn over “Homepage.”

This all happens very quickly, and you only ever see the final result, so it looks like just a few pixels have changed, but in fact the whole screen must be reconsidered and redrawn.

If this sounds familiar, it’s because this is the basic method used in GDI, the rendering system introduced with Microsoft Windows 1.0. That sounds damning, but really most GUIs operated this way.

Until the iPhone came along…

When you’re using an iPhone, you’re playing a hardware-accelerated 3D game. You know, the kind of 3D where everything is made out of hundreds of little triangles.

When you flick through your list of friends in the Contacts app, you’re causing those triangles to move around. And there’s a “camera,” just like a 3D shooter, but the camera is fixed above the Contacts app’s virtual surface and so it appears 2D.

Which is a long way of saying that everything on iOS is drawn using OpenGL. This is why animation on iOS is so hopelessly fast. You may have noticed that -drawRect is not called for each frame of an animation. It’s called once, then you draw your lines and circles and text onto an OpenGL surface (which you didn’t even realize), then Core Animation moves these surfaces around like pulling on the strings of a marionette. All the final compositing for each frame is done in hardware by the GPU.

Android seems to have made the decision early on that they wouldn’t force their manufacturing partners to include a GPU. This decision made total sense back in the pre-iPhone days, but now it’s causing pain, as even the new hardware acceleration in Android 3.0 is limited by the original software-based compositing system.

So here’s the catch with the wonderful flexible layout system in Android: You must be very careful. If you animate certain kinds of properties, you can easily force the CPU to do all that fancy, expensive layout on each animation frame. And the CPU is very busy right now parsing some JSON from a web API or something, OK?

Meridian For Android

All in all, it took us about 4 months of development time to build and release Meridian for Android.

When we first released Meridian, our number one piece of feedback was “Will you make an Android version please?” Except often without the “please.”

And it turns out Android is the third platform for Meridian. The first was Windows Mobile, if you can believe that.

We started building what we now call “Meridian,” back before the iPhone existed. At the time, Windows Mobile was the only mobile platform capable of delivering the experience we wanted.

So you could say I’ve got a rather long view of things now. There will always be new platforms and new paradigms to learn. The best we can do is to understand where each one came from, and to embrace the positives and overcome the negatives as quickly as possible so we can ship some awesome features before everything changes again.

A lightweight HTTP request class for iOS [2/2]

Mon, 28 Mar 2011 20:43:00 -0700

Part 1 | Part 2

Check out SMWebRequest on Github.

In Part 1, we introduced SMWebRequest for making HTTP requests with little code. For instance, here’s how your view controller could download an RSS feed and parse it with SMXMLDocument:

Looks simple, but there’s a catch. See how we’re taking our NSData response from the server and turning it into XML? Well that’s happening on the main thread, and guess what, parsing XML or JSON or whatever takes time. Maybe it takes a few milliseconds, or maybe it takes 10 whole seconds like when we parsed a gnarly RSS feed on the original iPhone.

And your poor user, well she’s probably scrolling through a table view or web view or something and just having a great time and then screech everything grinds to a halt while you parse your giant 8MB SOAP response.

The proper thing to do here is parse your data on a background thread. Which is relatively simple to do in Cocoa:

OK, so not terrible, but we’re starting to have a lot of code and callbacks in our controller, and now we have to start worrying: What if the user leaves this page while we’re in the middle of doing this work? We can easily cancel the SMWebRequest in -dealloc since it doesn’t retain us as a target. But we can’t kill the background thread if it’s running and the system will -retain us anyway so we have to wait until it completes and then detect somehow that we’re no longer wanted so we don’t kick off new operations. And what if the user presses “Refresh” or picks a different RSS feed or something while we’re working in the background? Now we have to detach new background threads and detect old ones finishing and it gets really hairy.

“Who wants a stylus?! You have to get ‘em, and put ‘em away, and you lose ‘em. Yeeech. Nobody wants a stylus.”

—Steve Jobs

So let’s not use a stylus. Basically, we don’t want our controller class to have to worry about any of this stuff. The process should be abstracted away as “Ask for RSS feed, receive RSS items later.”

And that’s exactly what SMWebRequest is designed for. In addition to the target/action callbacks, SMWebRequest supports the delegate pattern for processing data separately:

There are a couple great things happening here. First, we implement the delegate’s -webRequest:resultObjectForData:context: which is a totally isolated method. Its only job is to turn NSData into objects. In this example, it’s a Class method which is great for background threads because it can’t accidentally touch our instance variables even if it wanted to.

Second, the controller’s “complete” method automatically receives the NSArray we care about, rather than the whole NSData. Ask for RSS feed, receive RSS items. And the whole operation is automatically cancelable just like any SMWebRequest because it manages the threading for you.

We can make our controller even cleaner by moving the parsing out into a model class:

And this is how we write all our apps.

The github project demonstrates all this nicely by building basically an entire Hacker News RSS reader using very little code, whipped up by Benjamin van der Veen, the original author of SMWebRequest.

I actually installed it on my iPhone and use it now to waste even more time than I already waste reading stuff on the internet.

A lightweight HTTP request class for iOS [1/2]

Sat, 26 Mar 2011 19:57:00 -0700

Part 1 | Part 2

Check out SMWebRequest on Github.

Let’s say you’re writing an app, either on iOS or the desktop, and you want to download some JSON data from a web service.

With JavaScript and jQuery, this is a one-liner:

Sigh, if only.

Well, technically you could do this in one line:

But if you do that, you’ll block the main thread until it completes, after which I will come over to your house and stab you in the face.

To perform asynchronous, cancellable HTTP requests in Cocoa, we have NSURLConnection. Now, this is a pretty nice class. It gives you a great degree of control over the lifetime of the request and for managing the incoming response data. It also handles caching and system proxy settings and global request pooling and other useful things. So we want to use it.

Unfortunately, using it properly is a bit tedious:

So that’s all fine if we’re only downloading like, one thing in our app. And, maybe for Apple, downloading something from the Internet is a Big Deal.

But if you’re anything like us, your app is pretty much constantly talking to servers. Authenticating, downloading, syncing, sharing, logging, refreshing…there’s easily dozens of places in each of our apps where we need to speak to some web server.

So after a while, we thought “maybe this can suck less!” and wrote a utility class called SMLoadedResource that used NSURLConnection behind the scenes to easily download and process data. Then we threw it away and Benjamin van der Veen wrote it for real and called it SMWebRequest.

SMWebRequest implements the target/action mechanism for its callbacks, just like UIControl. That means you can write callback methods with sensible names like trendsComplete, instead of handling everything in a generic webRequest:didComplete: method with a ton of if statements.

SMWebRequest also provides incredibly nice support for parsing your response data in a background thread while maintaining a separation of concerns. For more, continue to Part 2.

A lightweight XML parser for iOS

Thu, 20 Jan 2011 09:28:00 -0800

Check out SMXMLDocument on Github.

If you’ve ever tried to parse XML on the iPhone or iPad using NSXMLParser, you may have wondered if you’re taking crazy pills.

Is this really how people parse XML on iOS? Really?

I mean, yes, it’s true that using NSXMLParser forces you to write extremely efficient stream-based parsing without buffering the entire XML structure in memory.

But it also forces you, the savvy developer who already hates XML, to hate it even more as you write tons of conditional code and temporary classes so you can manually keep track of state.

When we wrote our first iOS app, Style.com, we looked around for XML-parsing alternatives on iOS, and there are quite a few. But they all felt like…too much.

What we really wanted was just the simplest possible class that would use NSXMLParser itself to build up an easily-traversable Cocoa object hierarchy.

So we made one. It’s a single class, with like one page of code.

And we find it very pleasant to use:

We’ve used this class to parse XML on iOS for years now, and we’ve never had any problems. You may want to fallback to NSXMLParser if you have to deal with a multi-megabyte XML document though.

Simplify your models with SMModelObject

Wed, 01 Dec 2010 11:16:00 -0800

Check out SMModelObject on Github.

For almost every app we’ve made, I find myself writing “model classes” to store structured data and logic. For instance, when you search for a book in the Barnes & Noble app, we fetch book results from an XML-based API and parse the XML into Cocoa objects that get passed around to our Controllers and Views.

Pretty standard stuff. Now, one way to represent this data in memory would be to use anonymous NSArray+NSDictionary structures, like so:

I don’t know about you, but I cringe when I look at that code. So verbose, hard to read, no refactoring, no code completion; but most importantly, no type safety. I might write @"pric" by mistake somewhere else and waste an hour debugging.

So let’s write a “model class” to store Books in a typesafe way.

Again, very standard. Now we can create these typesafe objects and access their properties directly:

So, ahhh, much better.

But, man, that Book class seems like a lot of wasteful typing. Every property has to be written up to four times: declare instance var, write property, write @synthesize, and release in -dealloc if necessary.

Seems manageable until you start dealing with real-life objects. In the Barnes & Noble app, Books have twenty-one properties. And Book is just one of a couple dozen model classes in the app. Sigh.

Now, it turns out that ObjC has gotten better over the years, and as of the latest iOS SDK (4.2), LLVM+Clang can create your instance variables automatically. This is really nice!

Leveraging this feature, our Book class now looks like:

Which is great, but we can do even better. Objective-C makes it easy to introspect classes at runtime, so we’ve created a simple base class called SMModelObject.

Using runtime introspection, SMModelObject can do lots of great stuff for free:

Automatic release of properties in -dealloc
Automatic implementation of NSCopying
Automatic implementation of NSCoding so you can archive/unarchive your model objects to disk for state saving or for the clipboard
Automatic -isEqual and -hash implementation to compare model objects by value

Now our Book class looks like this:

SMModelObject even overrides -description to print nicely-indented model object hierarchies for easy debugging.

Kickass.

EDIT 3/26/2011: This article used to demonstrate a feature of the Clang compiler that was experimental at the time: automatically writing @synthesize statements for you. It was awesome, but Apple decided it wasn’t finished and so the official Xcode release doesn’t contain it. I’ll update this article again once it’s released.

This all started when André Pang wrote an amazing model base class called RMModelObject a few years back that is incredibly sophisticated and provides these same great features on the legacy ObjC runtime. RMModelObject was the inspiration for my class, which was much easier to write since ObjC 2.0 does all the heavy lifting.

We’ve historically used RMModelObject for all our model classes, so I must give full credit to André for this wonderful concept, and for saving me many extra hours of typing over the years.

Raaarr: A Growl Style

Fri, 05 Nov 2010 09:22:00 -0700

Update: This style is now included with Growl 1.3! Go download it from the App Store and enjoy.

Download Raaarr Now [Growl pre-1.3].

It all started way back 2 days ago when James McDonald tweeted out a design for a new Growl style:

It was a lovely Photoshop design and I offered to take a stab at coding it up.

I started with a basic HTML and CSS structure cribbed from the very slick “Eleven” Growl style by Christopher Lobay.

Since Growl notifications are presented using Webkit, I was able to heavily leverage some advanced CSS3 techniques. For instance, the soft, semi-transparent gradient background and border effects are all done using CSS gradients.

I soon had the basic design finished using only HTML+CSS.

But I wasn’t happy with the way most icons blended into the background of the notification. Like that yellow duck above.

What I wanted was a dynamic subtle stroke around the outside of the icon. But a standard CSS “border” wouldn’t work because the icon is technically square.

So I turned to image-based CSS masking. I created a simple <div> that was a semi-opaque black square that sits behind the icon. Then, I used a reference to the icon image as the argument to a mask:

Then I stretched the <div> to be slightly larger than the icon sitting on top of it, and voilà:

Finally, I wanted a nice subtle animation to give these notifications some personality. The animation should be fun, but also shouldn’t break the physicality of the notification itself; I dislike things shifting about and animating for no reason.

I ended up being inspired by iOS alert bubbles, and created a more subtle version of a “pop-up” using CSS3 hardware-accelerated animations:

The result was extremely pleasing. You can see it on the demo site (best+accurate results in Safari).

Speaking of the demo site, it’s got a neat trick too: it demonstrates the style by embedding the style itself in the browser, which is pretty cool. But for the actual content of the demo notifications, it’s dynamically querying Backtweets for tweets that link to the site itself!

So go tweet about the Raaarr style and you’ll show up on the homepage.

A Brief Review of the 11" MacBook Air

Thu, 04 Nov 2010 09:39:00 -0700

OMG OMG OMG OMG OMG OMG OMG OMG OMG OMG

A Less Brief Review of the 11” MacBook Air

It’s been my primary computer for a week or so, and I have zero regrets. I can’t imagine going back to my 13” MacBook Pro. Which, even with an SSD drive upgrade from Apple, felt slower than this machine.

I don’t know how to explain it. I guess CPU clock speed is meaningless now? It seems most applications are IO-bound and so benefit very much from the flash storage. Also the super-fast graphics.

The screen is awesome and doesn’t feel cramped at all. I even write code with Eclipse on this thing and it’s great.

There’s something truly magical about this form factor. It’s crazy ultra portable. Look, it even fits in my man-bag with my iPad!

There’s basically no reason to buy any other computer, especially for the price. It’s that good.

DropDAV = Dropbox + WebDAV

Mon, 18 Oct 2010 09:42:00 -0700

Go use DropDAV now.

When the new iWork update for iPad dropped, I was in the Bay Area for an Important Meeting. While in transport to this meeting, I had created a Keynote presentation on my iPad. Because I want to be hip with the kids!

Now we’re sitting in the rental car in the parking lot of the Big Company, and the presentation starts in 5 minutes, and I need to shuttle the Keynote file off my iPad and onto my MacBook to throw in some crap I made in Photoshop about how awesome we are.

I ended up dragging out my sync cable and moving the files through iTunes. It felt dirty and uncool. But it was OK, because we never even had a chance to show our Big Presentation and spent the whole meeting chatting instead.

What would have been perfect is if Dropbox had a WebDAV API, since 1) Dropbox is civilization, and 2) The new iWork integrates with WebDAV and MobileMe. Then I could just post the file straight from iWork to my Dropbox and it would magically appear on my MacBook!

So this weekend I set out to build a WebDAV frontend to Dropbox. And here it is.

I wrote it on Google App Engine since I’d already implemented a WebDAV server for App Engine, and so that I don’t have to think about hosting. The Dropbox API part was made much simpler thanks to their official Python API.

Sadly, you can only transfer files up to 1MB, due to limitations with urlfetch.

Otherwise, feel free to use it to get things into and out of your Dropbox until they provide an official WebDAV frontend.

iPad Does Everything

Wed, 29 Sep 2010 09:35:00 -0700

In 1984, Bang & Olufsen released the Beosystem 5000, a large component-based stereo system. It shipped with the most awesome remote control of all time, the Master Control Panel 5000.

I was seven years old when I saw this thing at my Aunt’s house and it was just about the coolest thing I’d ever seen. That bottom silver panel flips open to reveal even more buttons. It’s totally sick.

Fast forward many years later, and now I finally have one for myself. Except this time it’s a free app I downloaded from the App Store to control our Sonos music system.

I wonder what this will look like in another 25 years?

iOS Icon Template for Perfectionists

Sat, 25 Sep 2010 20:16:00 -0700

Download the modified template

After creating a few icons with the excellent iPhone 4 icon PSD template from Cocoia, we started noticing the dreaded “black corner pixels” effect on iOS and iTunes, which you see all over the place these days.

Why does this happen? It’s because Apple is very liberal about the compositing of your image. Let’s say you make a nice icon in Photoshop, and “eyeball” the corners:

When iOS gets ahold of your nice transparent icon, it will immediately slap it on a black background…

…then apply this masking image:

Now your icon looks like this:

You could sneak this by in the past because the iPhone homescreen was always black anyway. But now that we have customizable homescreen wallpapers, these black corners will be revealed right quick.

How did we fix this problem? Well first off, we started by rebuilding Cocoia’s template around the system masks we extracted from the iOS firmware.

But even designing against the exact masks isn’t enough to avoid a faint black line around the corners. So we also made it easy to “extend” the outer pixels of your icon all the way to the edges using a Smart Object.

+ =

Look carefully at the colors we’ve chosen to extend, it’s not the dark red interior background, it’s the outer pixel:

So now Apple can apply all the masks and effects they want and your icon will still look perfect:

The template leverages Photoshop Smart Objects heavily to ease the burden of designing all your different icon sizes simultaneously.

But here’s the best part: when you’re ready to export the final output, just unhide the top Corner Mask preview layer and Save for Web:

Each icon has its own Slice, set to export with the correct filenames like “Icon.png,” “Icon@2x.png,” and even “iTunesArtwork” for .ipa distribution.

Just one save and you’re done.

Comments? Feedback? Hit me up on Twitter.

Moving my Photos to the Cloud

Mon, 13 Sep 2010 20:07:00 -0700

I went to visit my extended family on Lake Michigan last weekend, and ended up snapping a few fancy-schmancy HDR photos on my iPhone 4.

Like the world needs more photos of beaches.

Later, I captured some germane pictures featuring actual family members. After which I thought, man I sure would like to show these to my grandparents on my big-screened iPad which is sitting right here. Also, I’m on the phone with my Mom, and can’t I send them to her, too?

So yes, because I’m a nerd I can make these things happen but ugh, I’ve gotta 1) unpack my laptop and dig out my cables and 2) sync my iPhone which takes forever, then I’ve gotta 3) deal with all the other crap in my Camera Roll and organize everything into iPhoto Events and such, then post them to a “place” like Flickr or MobileMe or god forbid Facebook, then 4) Re-sync my iPhone and iPad to get the newly organized photos back on there. By which time everyone’s moved onto watching Fox News and chastising me for buying a Prius.

Dealing with photos shouldn’t be this cumbersome. Enter Google Picasa.

I looked at a few cloud-based photo storage systems, and chose Picasa for a few reasons. First, it’s powered by The Google, so I’m not concerned about their infrastructure or ongoing development. Second, it’s been around for a while so they have a great ecosystem of tools.

Most importantly, they have Web Albums: a 3rd party app for iPhone and iPad that, seriously here, rivals Apple’s built-in Photos app.

Web Albums has replaced the native Photos app on my iOS devices. Now I can take photos using the Camera app, then go to Web Albums and make a new album, queue it for upload to Picasaweb, and copy the private viewing URL to the clipboard so I can email the link to Mom right from my phone. Meanwhile I grab the iPad and “pull to refresh” the album list, and BAM it’s right there.

So that’s my new workflow, and all my photos will be stored on Google’s servers rather than carting them around on my laptop and worrying about backup.

Picasa also makes it dead easy to migrate my existing photos from iPhoto using their “native” OS X application. Fortunately I only need to use it for this single purpose, otherwise I’d die having to look at the jankiest UI widgets on the Macintosh.

(Aside from the UI, this program is otherwise quite powerful and impressive. It also did a better job identifying faces than iPhoto.)

The best part is that Picasa’s hosting is really cheap. It’ll only cost me $5 a year to store my 17GB collection of all the digital pictures and video I’ve ever captured.

iPhone 4: No Italics!

Sat, 26 Jun 2010 08:12:11 -0700

This sounds crazy, but seems to be true: +[UIFont italicSystemFontOfSize:] simply returns a regular non-italic font on iPhone 4 hardware.

The release notes state:

iPhone 4 uses a different system font than earlier devices. References to the Helvetica font in nib files will be decoded as the system font on these newer devices.

The “different system font” appears to be Helvetica Neue, for which there is no italic version included.

Since you’ll always want to use the system font for your user interface, what this means is: no italics for your UI.

This absolutely must be intentional and not a bug. Changing the system font on a new iPhone model for which a primary new feature is better font rendering, is a huge deal.

I’m not complaining about it, I think it’s a fine decision, but also extremely interesting, don’t you think?

How to check out new music on Rdio

Mon, 21 Jun 2010 08:16:00 -0700

1) First, search for an artist you’re interested in:

Now scroll down to “Popular Songs.” See that Play button?

2) That’s the one. Press that. Press it.

3) Now you’re listening to some awesome music. How easy was that?!

For extra fun, share it with your friends:

Improvements to Google Wave Notifier

Fri, 26 Mar 2010 20:01:00 -0700

Download the notifier now

I tried out the Unofficial Google Wave Notifier and liked its functionality, but wasn’t thrilled with the UI:

So I made some changes:

The icon glows blue when you have unread waves, inspired by Tweetie for Mac:

I also added a selector for choosing which browser the Notifier opens Google Wave in when you click things.

Creating this selector in Cocoa on OS X was a lot more involved than I thought going in. But at least it’s not Windows, which would have been 10 times more painful.

I also refactored the notifier to be fully asynchronous so it doesn’t block the main thread and is always responsive.

Check it out on Github.

There, I fixed Xcode—You’re Welcome.

Fri, 05 Mar 2010 20:01:00 -0800

Update: Xcode 4 ships with a brand new completion engine and UI that makes my hackjob plugin look like a toy. Go use that instead!

Download xcode-auto-assistant now

In my last installment, I discussed Xcode’s frustrating implementation of code completion.

I’ve now taken matters into my own hands.

It turns out Xcode has an (undocumented) plugin system. And it also turns out that this guy created a really fantastic plugin for Xcode that automatically inserts a matching opening bracket ‘[’ when typing the closing bracket ‘]’.

Now, it turns out Apple added this bracket-insertion feature on their own, possibly being inspired by this, so the plugin is now just reference material.

Really useful reference material for doing what I want to do.

I’ll save the nitty-gritty details of how the plugin works for a later post (or just browse the source). Let’s just say that we have access to keystrokes as you type them in Xcode. How would we use that to achieve automatic completion list display?

Take 1: Popup all the time!

The most useful behavior, it seems, is for the popup list to appear as soon as you type a reasonable character that can be completed, such as an alphabetical character. Here we’ll type ‘u’ because we want UIViewController.

So that’s the first thing I implemented. Listen for alphabetical character, popup the list.

The problem turns out to be that the list takes “a while” to appear, because we’re in Objective-C which is still C and the number of legal symbols you can type in a particular location is immense. I mean look at that tiny scrollbar! There’s all manner of detritus in there like u_quad_t and UIKIT_STATIC_INLINE.

You might think, no problem, I’ll just ignore the popup and keep typing because the list will narrow itself down as I go. But, in practice, it turns out to be extremely annoying because you can’t type small words like “if” and “for” without the popup list slowing you down.

Examine our options

I imagine that Apple encountered this same problem, and it seems the way they addressed it was by analyzing the number of items that would match and only giving you a suggested completion if the number of possible matches is small.

This is why, with Apple’s completion, you must type “nss” before it will automatically suggest something like “NSString”. If you just type “ns” you can sit there forever and it’ll never suggest anything. But if you type “cl” it might suggest “CLLocation” because there aren’t a lot of other things starting with “cl”.

My beef with this approach is that it’s unpredictable. How do I know how many letters I’m supposed to type before I can press enter and move on?

Take 2: Smart delay

The solution turned out to be surprisingly simple. Display the list after typing any alphanumeric character, but with a delay proportional to the number of characters in the word entered thus far. On the 4th character and beyond, the list always appears immediately.

This way you can type “uivi[enter]” as fast as possible and you get UIViewController (depending on your typing history, but this is intuitive).

By the time you get to the 4th character, the list is almost always reasonably small and therefore much more helpful.

If you just type “u” and forget what you were doing, we’ll wait about 0.4 seconds before presenting the list to help you.

More importantly, you can type “for (int i = 0…” at normal typing speed without the popup appearing at all, and once you get stuck on something you’ll pause naturally and only then will the list appear.

Extras

Of course, you don’t want the list appearing on just any alphanumeric character: If you’re writing a string or a comment, the list isn’t going to help you. So the plugin does some extra work to detect those situations. It’s not a full-on lexer but it seems to work 99% of the time.

Additionally, if you type a period ‘.’ to access a struct member or ObjC property, the list always appears immediately.

One last neat feature: When you type a semicolon, it will be automatically moved to the end of the line as necessary. I don’t know about you, but I often find myself in this kind of situation:

…having just typed a method name and needing to cap off the line with a semicolon. Normally I’d have to go find the right arrow key first, but with the plugin you just type ‘;’ and it puts it in the right place.

Pretty cool!

Try the plugin here.

Code Completion and XCode

Sun, 14 Feb 2010 19:59:00 -0800

Update: I wrote a plugin to address these issues.

Later Update: Xcode 4 Preview 3 shipped with a brand new completion engine and UI that happens to address all these issues with aplomb. Yays!

The newish mac app Espresso contains a great (and uncommonly beautiful) implementation of code completion.

It goes like this. Say you’re editing a CSS file:

That’s a nice blue background, but you also want a border. You start by typing the letter “b”:

Since Espresso knows that there are many possible options that start with “b”, it presents them to you in this lovely but minimal popup. You can use the arrows and press enter to select something from the list. Or, you can pretend the list never appeared and keep typing. Once you type enough to eliminate all other options, the list disappears and you’re left with a more standard OS X “completion” highlight. You can still press enter to accept this last suggestion.

The two things I want to emphasize about this workflow are:

It’s predictable. I trust Espresso to always give me all possible relevant options after each keypress. And I know that I just press enter to accept and move on.
It’s useful. Whenever there are multiple options, they are presented to me in the list, and the list appears automatically when needed.

Predictable

XCode goes like this. Say you’re writing some Objective-C:

We need to make a new instance of UIViewController, so we begin our journey of typing the class name.

XCode does nothing so far. We know it has a set of suggestions to help us—if you press ESC now, you’ll see a nice list of all the classes starting with “UI”. But for some reason it’s decided not to jump in yet. (Note: My Code Sense delay is set to Immediate). We press on, typing “v”:

Ah ha, there it is! Clever XCode! That’s what we want—so we’ll press enter:

Curious. It has only partially completed the word. See how before, only the ‘i’ was highlighted? This is a (newish?) feature of XCode. It turns out there are a few other classes starting with the prefix “UIVi” and it doesn’t want to assume that I want something starting with UIView and not, say, UIVideoEditorController which I never knew existed until just now.

At this point if I press enter again, it will go ahead and fill in the rest of the word.

So it eventually gave me what I wanted. But here’s a wrinkle: if I would have typed “uivi” myself first, it would have suggested UIViewController just the same, but in that case it would have completed the entire word when I pressed enter.

The problem here is that XCode is not predictable. When I’m typing code, my brain is moving faster than my fingers. I can decide to type [[[UIViewController alloc] init] autorelease] a hell of a lot faster than I can actually write it. And my brain can’t move on to a more interesting problem until it can give my fingers a known sequence of keys to press. XCode’s completion is a different back-and-forth conversation with the editor every time. How do I get it to finish UIViewContoller? Do I press enter once, twice, three times? It depends how many characters I typed first, which also depends on factors like XCode tailoring its suggestions based on my code history.

Useful

Here’s another example. Let’s set the frame of our new controller’s view, by first declaring a new CGRect:

Now here I’ve typed the letters cgrect just like that, and XCode hasn’t suggested anything at all. Maybe I have to type more than 6 characters before XCode jumps in? (Nope, that’s not it.)

OK well, I’m done typing now, so I have to fixup this cgrect by turning it into a real CGRect with proper caps. Maybe XCode can help with this? I’ll press ESC.

OK, so I got lucky, it happens to be the 2nd item in the list. (If this list was sorted alphabetically, as it is by default, CGRect by itself wouldn’t even be on it). But still, I’ve written an exact match, shouldn’t that be what’s selected by default instead of CGRectInset? Now I have to fiddle with arrow keys and scrolling and by this point I could have just typed out CGRect myself with proper carpal-tunnel-inducing capitalization and skipped all this business.

It gets worse

These are just two examples out of many. In fact, XCode’s completion is so unhelpful that I can only assume the engineers at Apple never have it turned on, and maybe just code everything in Vim anyway. To me, it feels like the sort of feature that was built to “satisfy” demand from non-Apple developers. Look, fine, we’ll give you your ‘completion’, you Microsoft-coddled sissies, now please go away and let us work on OS X 10.7 already!

It’s just a bit sad for me, because I have tasted the sweet nectar of real, predictable, useful code completion, and it is wonderful and productive. This isn’t an intractable problem! It just needs some more TLC.

If you agree with my findings, I encourage, nay, command you to go fill out a bug report with Apple (they really do read these).

I have also reposted the issue on Open Radar.