Building Sparrow for Mac, the “open-sourced” email client

September 1, 2012 | Jason Kozemczak

Sparrow was a rather awesome mail client for Mac and iOS that was fairly recently bought out by Google. The acqui-hire caused a big stir in the tech startup scene, and you can find plenty of “fors” and “againsts” throughout the interwebs.

In a rather nice move, Google quickly released “free” versions of Sparrow for iOS and Mac, the caveat being that you have to build it yourself. Today we’re going to walk through the steps to make that happen. You’ll need to be on a Mac, as building requires having access to Apple’s frameworks and build tools.

Installing XCode

Sparrow uses Clang to compile, so we’ll need to have XCode installed. XCode’s available on the Mac App Store, so just use this XCode App Store link to install it.

When you follow the link, the App Store will open to the XCode product page. Click the “Free” button near the top, and click it again when the text changes to “Install.” XCode should begin downloading onto your computer; it will automatically install once the download finishes.

Getting Sparrow for Mac

Next, you need to actually download Sparrow for Mac. As an aside, Sparrow also gave customers the ability to build Sparrow for iOS, but you’ll need to be an registered in the iOS Developer Program to put it on your iOS device. Links to both of the apps can be found in the blog post announcing the availability of the two apps.

After the download finishes, unzip the archive if it isn’t already unzipped.

Fixing the build script

If you navigate to the now unzipped Sparrow directory, you’ll see an ‘app’ directory, and a ‘lib’ directory with a number of static libraries in it. Sparrow essentially gives us an un-linked copy of Sparrow, and we need to use XCode to actually link the libraries.

Fortunately, the guys at Sparrow have included a build script (‘build-mac.sh’) that should make linking a one-line step.

Unfortunately, the path the script uses for XCode will most likely be wrong. Fortunately this is an easy fix. To fix it, open up the ‘build-mac.sh’ file located at the root of the unzipped Sparrow directory in a text editor. On the third line, you’ll see the following:

xcodepath=/Applications/Xcode45-DP2.app

Change the portion after ‘xcodepath=’ to match where XCode is installed on your system. For most people, the line should read:

xcodepath=/Applications/Xcode.app

Save and close the editor.

Building Sparrow

After XCode has finished installing and the above edits are in place, we should now be able to build Sparrow. open up terminal and change directories to the Sparrow directory where you just modified the build script; for most people, this can probably be accomplished by the following command:

$ cd ~/Downloads/mac/

And run the the build script:

$ sh build-mac.sh

Running Sparrow

Once the build script returns, all of Sparrow’s dependencies should be linked against, and we should be off to the races! Open ‘app/Sparrow.app’ under the Sparrow directory and Sparrow should launch. It’ll ask you if you’d like it to be moved to the Applications directory; you can do whatever works for you.

After filling in your email details, Sparrow should be up and running.

Enjoyed the post? Let me know by following me on Twitter or DMing me: jaykz52

WTF UIAutomation? Y u no respect object equality?

August 24, 2012 | Jason Kozemczak

I’ve got good news and bad news. Mostly bad news, at least as far as I’m concerned.

An issue was recently submitted on Github for my UIAutomation framework, mechanic.js. Investigating the issue, I mostly discovered that the resolution was mainly clarifying which functions do what. Fortunately, the documentation for mechanic.js is fairly decent (though it could certainly use more concrete code samples), so a simple link pretty much cleared that up.

I also double-checked the implementation of a number of mechanic.js core functions to ensure they were behaving as designed (I even added a few new specs, hurray!). Everything appears A-okay on that front. That’s the good news.

Now, the bad news: While exploring the Github Issue, I came across what appears to be a fairly recent issue introduced into UIAutomation. From what I can tell from my poking and prodding, Apple seems to have broken element equality when comparing UIAElements. For example, if were to loop over an element’s subelements (say, in a UIATableView) and compare an element to itself, UIAutomation tells me they are not equal (a major FAIL in my mind).

To repro this, you can create a simple Single-View App in XCode, drop some elements onto the NIB, assign accessibility labels to those elements (otherwise UIAutomation won’t pick them up), and then run the following script in Instruments, you’ll see the behavior I’m talking about:

What the hell, Apple? This behavior pretty much flies in the face of how the programmers writing automation test scripts think; to that end, equality did work as expected prior to at least XCode 4.3.3. If somebody can confirm that it is also broken in XCode 4.4, I’d appreciate it (my instinct is that it is).

What this ultimately means for mechanic.js is that it’s pretty broken at this point. Most of the functions related to filtering (`filter()`, `is()`, `not()`, etc.) flat out don’t work. Additionally, quite a few of my former team’s existing automation tests are likely broken as result, mechanic.js aside. I’m going to investigate if there’s a workaround I can implement to get mechanic.js back up to working order, but that’s likely not a one-night sort of fix. I utilize referential integrity pretty significantly (like any decent programmer would) in mechanic.js.

I’ve submitted a Radar ticket to Apple for this. Additionally, I’ve opened an OpenRadar ticket that can be duped if anybody reading this post is so inclined to put some weight behind this issue.

I went ahead and created a sample project on Github that you can run to confirm the issue exists. Give it a run and tell me if I’m crazy or not!

Follow me on Twitter to get the latest updates. Tweet or DM me if you’ve got info that might be helpful; thanks!

Listen: iOhYes, a podcast for iOS and Mac Professionals

August 22, 2012 | Jason Kozemczak

My friend and coworker John Sextro approached me last week about being a guest on his new iOS podcast, iOhYes. Of course I said yes!

You can listen to the premier episode and subscribe to the podcast on iTunes.

This week’s episode involves a wide range of topics, including techniques for writing testable code that takes advantage of the power and convenience of UIKit UIViewControllers, AppCode (a new iOS/Mac IDE by JetBrains), what a new iPhone aspect ratio means for  iOS developers, and a round-up of open-source production-ready apps for new iOS developers to cut their teeth on, among other things.

If you like what you hear, follow me on Twitter to here more!