EGOCache 2.0

It’s been a while since we’ve updated EGOCache, a large reason for that is that it’s been fairly stable and gets the job done.  There’s not too many bells and whistles you can build into a key value cache store, at least not many that are necessary, so we’ve left things largely alone.  Aside from a few pull requests, not much has changed in EGOCache since we released in October 2009.

So, what’s new in 2.0? Everything. Nothing.

Internally, 2.0 is completely rearchitectured/rewritten.  Externally, the API remains largely untouched, so you’ll be able to drop it into your existing projects and go.

The only major API change is that +currentCache has been deprecated in favor of +globalCache.  This was made purely for semantics, because you can now instantiate your own EGOCache instances and set a different cache directory if you’d like.  This could be useful if you’d like to divide caches for different items (photos vs UI caching).

Under the hood is where all the fun stuff c:

  • EGOCache 2.0 is now built entirely on ARC, Objective-C blocks and libdispatch.  If your projects don’t support these technologies, well, do yourself a favor, learn them and love them.  We were resistant to ARC at first too, just give in ;).
  • All disk saves are now non blocking and processed in a separate dispatch queue.
  • The thread saftey issues that popped up over the last year should be resolved.  All dictionary modifications are now done in a serial dispatch queue.
  • On iOS, when saving a UIImage, EGOCache now serializes the UIImage instance rather than the old way of using UIImagePNGRepresentation.  This allows you to retain all meta information associated with the object, such as orientation and scale.  An additional benefit to this is that the image is saved in it’s original format, so JPEG’s are no longer bloated to PNG size when saved.  One downside to this, if for some reason you were retrieving images via -dataForKey:, that will no longer work.

This is absolutely NOT a beta release.  We’ve been shipping this code on App Store since August and it’s running on millions of devices, so feel confident in switching to it from 1.0.

Grab the code here:

Lastly, I wanted to add a quick update on the rest of our open source libraries:

We still use them, every day.  We’ve been evolving them over the years and they’re all rewritten to utilize the same technologies mentioned above, and will be updated soon.  We don’t take major updates lightly, and we’re not going to put them out there until we’ve already shipped them in our own apps and know for certain they’re rock solid.  Look for EGOHTTPRequest 2.0 in the next few weeks.

Installing ImageMagick for PHP and MAMP

  1. Install Brew (
  2. In Terminal, run: brew install imagemagick
  3. In Terminal, run: brew tap josegonzalez/homebrew-php
  4. In Terminal, run: brew install imagick-php
  5. Copy the compiled extension path (extension= …)
  6. Edit this file: /Applications/MAMP/Library/bin/envvars
  7. Comment out the only lines that aren’t already commented out.
  8. Add the extension= path to your php.ini files.
MAMP Users:
MAMP Pro Users: 
/Library/Application Support/appsolute/MAMP PRO/conf/php.ini
And MAMP PRO > File > Edit Template > PHP > SELECT YOUR VERSION
Everyone Else:
In Terminal, run: php -i | grep php.ini$ to find the location of your .ini file.
Restart Apache via MAMP.

Calculating the height of text in Android

While Android has numerous methods for sizing text, as far as I can see, none of them let you pass in a max width to get the height of the text once it wraps.

This is relatively simple to do on iOS via – sizeWithFont:constrainedToSize:lineBreakMode:.

For Android, I came up with the following convenience method to do it:

With this, you can just do int height = getTextHeight("text", 160, 12.0f, Typeface.DEFAULT_BOLD);  and you’re set.

Android Hardware Acceleration Bug: canvas.drawBitmap NullPointerException

Despite what Google says, there’s still a bug in the Android SDK when doing the following:

As per the Android docs, the second parameter is supposed to accept null.  Passing in null works fine on devices without hardware acceleration, but will result in a crash if the device has HA.  Google claims this bug was resolved in ICS, but it’s definitely still present as of today.

As long as you provide the src rect, everything works fine:

Webkit box-shadow inconsistencies

There appears to be an inconsistency in how Webkit renders the CSS3 “box-shadow" tag depending on whether or not you prefix with "-webkit”.

John Barker brought this to my attention while working on something for so I began to investiate, and sure enough, it’s true:

You can find the code/working example here:

CSS3 Horizontal Navigation

Example of a pretty simple horizontal menu with vertical texted, purely powered by HTML and CSS3.

Head over to jsfiddle to see a working example and view the code:

Note: This only contains the -webkit css prefixes, you’ll need to update with -moz, -ms, etc for production use.

"EGO" Xcode Theme for Xcode 4 + EGOv2

Almost two years ago now, we posted our Xcode theme, “EGO”.  It’s been significantly more popular than I ever thought, we’ve seen a lot tweets about, we’ve seen it in screen casts, and it even made an appearance in the product launch video for robotcat’s Outside app.  There’s no real metric for these things, but it seems to be one of the more popular third party Xcode things (we’re number one in Google!).

So, with the GM release of Xcode 4, we’ve gone ahead and ported our original EGO theme to the new Xcode 4 file format.

We’re also posting a new version of EGO, EGOv2.  It’s based on EGO but has some key differences: New background color, new comment colors, themed console, and other minor tweaks and slight HSB adjustments.  Here’s a comparison:

Original EGO Theme

New EGOv2 Theme

To install the themes, run the following blocks of code in Terminal:

Original EGO

mkdir -p ~/Library/Developer/Xcode/UserData/FontAndColorThemes; cd ~/Library/Developer/Xcode/UserData/FontAndColorThemes; curl -O

New EGOv2

mkdir -p ~/Library/Developer/Xcode/UserData/FontAndColorThemes; cd ~/Library/Developer/Xcode/UserData/FontAndColorThemes; curl -O

Now just restart Xcode, go to Preferences > Fonts & Colors, and select “EGO” or “EGOv2” from the color theme drop down.

Note: Both themes now use Menlo Bold 13pt.  This might not be for everyone, but I’ve found it much easier on the eyes and the bold seems to render nicer than regular, to me.  Feel free to change!

Safari View Source in TextMate

While I love developing in Safari over alternatives like Firefox and Chrome, it lacks in one particular area: View Source.  Safari’s View Source is practically useless, it doesn’t show line numbers, no syntax highlighting, etc.

Safari does offer the Web Inspect, which is nice, but a little annoying for quick look ups since everything is broken down into the DOM tree.

I’ve seen other Safari Extension’s like BetterSource that do this right in the browser, but really, why re-invent the wheel?  TextMate is an awesome editor (albeit with this issues) and would be perfect for this.

I decided to see if I could get a “View Source in TextMate” item in the contextual menu.  After reading over all of the docs, it became apparent to me that opening files in a native app just wasn’t going to happen.

I was able to get it to work by writing a TextMate plugin to handle the heavy lifting via it’s txmt:// URL scheme.  So it all worked out in the end, you’ll just need to install the TextMate plugin as well as the Safari extension.  Enjoy!

Download the ViewSourceInTextMate TextMate Plugin

Download the ViewSourceInTextMate Safari Extension

Facebook Redux: Who doesn’t love a happy ending?

Late last week, we had a bit of a misunderstanding with Facebook. We probably jumped the gun and ended up rendering the title of the post a bit hypocritical, as many of you pointed out. We should have reached out to Facebook first to find out how this happened, but we were pissed off and wanted to tell the world. It’s not easy to get in touch with Facebook, and we were in no mood to sift through their site to figure it out. Apparently, we could have emailed them at

As it turns out, Facebook didn’t even know they did anything wrong. EGOTableViewPullRefresh made it’s way into Three20 by way of a fork merge from a third party. This obviously doesn’t excuse Facebook, since they are responsible for their repository, but it does explain how it happened.

Within hours of our post going up, Jeff and David from Facebook’s Open Source team became aware of the mix up and reached out to us resolved the issue quickly. All in all, we were pretty happy with the resolution. We received credit for our code in three20, and we helped make Facebook’s iPhone app just a little bit better.

Facebook didn’t stop there though, David reached out to me again this week and send me a Facebook Swag Pack:

At the end of the day, Facebook screwed up, but did everything right to resolve it, and then went beyond that by sending us from free Facebook swag.  We’re definitely sorry for how we initially handled this situation as well, since it’s clear now we could have avoided this by simply getting in touch with Facebook right away.

So thank you Facebook, you guys definitely have common courtesy!