Nick Farina

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.

Read More

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.

Read More

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.

Read More

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.

Read More

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.

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.

Read More

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.

Read More

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.

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.

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?