The SBJSON test ran NSString#JSONValue, and the equivalent YAJL test ran NSData#yajl_JSON. The YAJL bindings operate directly on NSData, and this makes a bit more sense since we usually have NSData first, whereas for SBJSON you have to decode to a string before parsing. I didn’t include this difference in my tests though.

These are tests of parsing only (and not loading of any data or strings) of the 4 APIs datasets run 100 times on the original iPhone, 3G and 3GS:

So the YAJL framework gives about a 60% speed increase. The YAJL Objective-C bindings can be found on github.

Be sure to thank @lloydhilaiel for making YAJL full of so much awesomeness.

Update: The project used to do the perf test can be found here.

Hopefully, sometime soon I will do some performance comparisons. In the meantime, if you try these bindings, let me know how it goes. You can find it on github at: http://github.com/gabriel/yajl-objc.

Right now, I only have a framework (for 10.5) built, but check back and at some point will have a static iPhone library built as well.

Here are some quick usage examples:

Usage

Usage (Streaming)

Usage (Document style)

Updated (07/01/2009): Updated usage to use new API changes for better streaming support.

This limitation can be really frustrating, particularly when you are using NSOperation or threading in general and need your delegates to call back onto the main (UI) thread.

A possible solution is to use NSInvocation with performSelector to deal with multiple arguments and primitives, for example:

but it gets cumbersome, especially setting up the invocation instance. (BTW, the first argument is at index 2 because of the hidden arguments self and _cmd.) Also you would need to call retainArguments if your arguments were objects, that may be released by the calling thread.

Thankfully there is a better way. In a post called ‘Grab that Invocation‘ and later at Dave Dribbin’s post ‘Invoke on Main Thread‘ we can see how to get an NSInvocation instance from an NSProxy/forwardInvocation: automatically; and now we can combine the proxy with performSelector:onThread: or any of the other peformSelector methods to invoke back on the main thread, invoke on other threads, delay invocation, or other more general aspects like timing methods, debugging, logging, or security.

You can find Dave Dribbins original DDInvocationGrabber implementation in his DDFoundation library.

I’ve expanded on it a bit in GHKit, (see GHNSInvocationProxy) and plan on adding more features. If you use it with the GHNSObject+Invocation category, it gets even better:

This category also includes other performSelector helpers (supporting var args and argument lists).

What might be some other ways to use this? Maybe an NSOperationProxy that allows you to queue and prioritize invocations, or more complex debugging or analytics proxies that can keep stats of certain activities.

GHUnit (pronounced \ˈgü-ˈnit\, I guess?), hosted at gabriel/gh-unit, is meant to be installed as a framework (or embedded in your project for iPhone apps), and run as an application in a separate Test target. The idea being that you can run and crash into the XCode debugger directly and utilize all the debugging techniques that you normally use. The test GUI should allow you to see test failures more clearly, view timings / stats and not have to go fishing for the build console window. And an automated way to view stack traces.

Details on how to use the framework are included in the README.

GHUnit Test GUI for Mac OS X App

Unit Test GUI for iPhone App

For the iPhone side, I included a similar GUI that runs the tests in the simulator. Though since frameworks are not supported on the iPhone SDK, you’ll have to embed it in your project, which is a little bit cumbersome. (Any ideas on how to make this easier?)

GHUnit can be used as a standalone test framework (by subclassing GHTestCase), or with your existing SenTestCase tests or GTMTestCase tests.

So far its pretty basic, but I am using it on a couple projects and its been helping my development a bunch and letting me to write tests as I go without completely destroying my workflow or sanity.

Any feedback is appreciated and let me know if you have any problems with the install/embed instructions or in general. Also thanks to the GTM peeps, on which much of this is based.

Maybe the next step is an XCode plugin?

Thanks!

As far as I could work out, traditional methods of grabbing a symbolic stack trace don’t work on the iPhone. (If I am remembering right, I don’t think NSStackTraceKey exists in UIKit.)

A little while ago I hacked the GTMStackTrace from google-toolbox-for-mac, to lookup the symbolic stack trace from the call stack return addresses (NSException#callStackReturnAddresses introduced in 10.5) and print it out using NSSetUncaughtExceptionHandler. Life has been a little bit easier ever since. Thankfully, the awesome people who work on GTM added it in themselves (see GTMStackTrace.h#61). Here is how you might set it up, in main.m:

For me, DEBUG is set in GCC_PREPROCESSOR_DEFINITIONS via the awesome GTM xcconfg files, which you should also be using. Hopefully, you should get a trace that looks like:

And the source of the exception usually starts around the 5th line.

Me and my friends have been using it for a little while to keep track of when we are uploading files (via RSS) and it seems to work pretty well.

Last week, I was playing around with the idea of a MuxTape/OpenTape type format where you could point it at a directory of mp3’s and you could play them straight from the browser. I have a preliminary version, an example of it, at: http://shrub.appspot.com/m1xes/sub-pop-mix-1/?format=tape (songs from the official Subpop Records free downloads page). So it seems like an OK way to share mixtapes by hosting them on your own S3 account, or to just stream mp3’s that you have backed up from a web browser.

In order to get it to show the track information, I wrote a handler to pull ID3v2 tag info from the mp3s by doing a request using the Range header (which S3 supports) of the first 1024 bytes (Range: bytes=0-1024). I think most ID3v2 taggings are at the beginning of the mp3 (I think ID3v1 was at the end). For example, if you have the S3 file:

sub-pop-mix-1/01-Dntel-The_Distance_(ft._Arthur&Yu).mp3

in the m1xes bucket, you can do an ID3 lookup using format=id3-json:

http://shrub.appspot.com/m1xes/sub-pop-mix-1/01-Dntel-The_Distance_%28ft._Arthur%26Yu%29.mp3?format=id3-json:

{ "album": "Dumb Luck",
  "performer": "Dntel",
  "title": "The Distance (Ft. Arthur & Yu)",
  "track": "5/9",
  "year": null,
  "isTruncated": false }

It will parse as much as it can from the first 1024 bytes of the mp3 (and isTruncated will be true, if there was more data after that). ID3 lookups are cached for 5 minutes.

Right now it doesn’t do any authentication (not sure if I want to store secret keys), so its only useful for public buckets and files. I think it makes sense to open source it and then add auth capability, and then people can configure it with their own keys and host it on their own app engine space. I will try to throw some code up on github really soon, after I re-factor some of my noobish python code.

Mainly, its just an excuse to help me learn python and play with mako and google app engine.

All this, and more detailed info is at: http://shrub.appspot.com/. If you see anything wacky, let me know.

Update: The source is now available on github: gabriel/shrub

• GHNSDate+Parsing.m: Various RFC and ISO date formatting and parsing
• GHNSString+TimeInterval.m: Time ago in words
• GHViewAnimation.m: View animation helper.
• GHNSString+HMAC.m: HMAC-SHA1 implementation which works on iPhone

And other stuff for generating uuids, mime types, etc. I blogged earlier about the date parsing and time ago in words.

Also, be sure to checkout the Google Toolbox For Mac which is way comprehensive (definately check there first). Feel free to pick and choose stuff at will. All files from other sources should have their original licenses which should all be MIT-like.

PS, sorry about the crazy feed crossing before. If you want to switch to a “cleaner” feed you can use this url: feeds.feedburner.com/gabrielh. Google reader caches the feed entries on the other one, so those will likely live forever.

HTTP Date

Some quick background on HTTP dates first. S3 requires sending a ‘Date’ header field as part of an authenticated request. (This and signing the request is a common countermeasure against a replay attack.) The spec says, the format of the date should be “one of the RFC 2616 formats (http://www.ietf.org/rfc/rfc2616.txt)”.

HTTP applications have historically allowed three different formats
for the representation of date/time stamps:

Sun, 06 Nov 1994 08:49:37 GMT ; RFC 822, updated by RFC 1123
Sunday, 06-Nov-94 08:49:37 GMT ; RFC 850, obsoleted by RFC 1036
Sun Nov 6 08:49:37 1994 ; ANSI C’s asctime() format

The first format is preferred as an Internet standard and represents
a fixed-length subset of that defined by RFC 1123 [8] (an update to
RFC 822 [9]). The second format is in common use, but is based on the
obsolete RFC 850 [12] date format and lacks a four-digit year.
HTTP/1.1 clients and servers that parse the date value MUST accept
all three formats (for compatibility with HTTP/1.0), though they MUST
only generate the RFC 1123 format for representing HTTP-date values
in header fields. See section 19.3 for further information.

So these are the standard formats. When sending a formatted date you should only use RFC1123 but should be able to handle any of the formats listed. This is just a way to maintain compatibility while trying to move everything to the latest format. If you are wondering what the difference is, RFC 1123 updated 822 by changing the time zone from hour format (±0000) to GMT format (GMT).

For example, the ‘Date’ or ‘Expires’ header fields for requests have this (RFC1123) format. Replies might have an HTTP date format in a Last-Modified or Date header as well.

ISO Date

XML data which has formatted date fields might use a date format which is defined by the ISO8601 standard and looks like ‘2006-02-03T16:45:09.000Z’.

Date parsing in Cocoa

Prior to 10.4, the Cocoa API supported “strftime-style conversion specifiers”. In 10.4, they added support for the Unicode Technical Standard #35 (version tr35-6).

The pre-10.4 strftime patterns look like: “%m/%d/%y” and the Unicode standard looks like “MM/dd/yyyy”. The default behavior (for backwards compatibility) is strftime format. In order to use the Unicode standard (which you will, its way better), you need to set the formatter behavior to NSDateFormatterBehavior10_4 either by calling setFormatterBehavior or setting the classes formatter behavior globally. Do NOT use the initWithDateFormat:allowNaturalLanguage: constructor, because it will give you a pre-10.4 date formatter. Using the strftime style of pattern when configured for the 10.4 (Unicode) behavior will fail silently.

So fast forward a few weeks, an S3Hub user told me he was getting authentication errors (invalid signing) trying to connect. I couldn’t replicate the problem but I eventually got the raw HTTP request header it was sending and the Date header looked like.

Fr, 06 Jun 2008 08:49:37 GMT.

Turns out the user is in Germany and when I change my locale to something German, I can reproduce the problem. Date formatters themselves can have specific styles (and symbols) that are modified by the locale. In the German locale the weekday symbol for friday is ‘Fr’ instead of English locale which is ‘Fri’. So when you use a date formatter in this way (with day or month symbols, for example) make sure to set the locale to en_US. The final date formatter looks like:

Update: See GHNSDate+Parsing gh-kit category on github for a collection of these date formatters.

As far as the domain goes, rel.me is taken from XFN:

XFN presents a simple and easy solution for this identity consolidation problem, with the new “me” value in XFN 1.1.

So if you use the rel=”me|friend|co-worker|enemy” attribute on your links, a crawler can build a social graph.

View a demo (Though, its possible it might not work)

The steps I used to generate this are:

• Load SWF
• Javascript calls to Actionscript fonts() method via ExternalInterface
• Get the list of system fonts in Flash via Font.enumerateFonts(true)
• Curse Flash for giving you a list of font names, where half of them are garbage.
• For each font name, in javascript, create a test which adds a DOM element temporarily with a fallback font family set. For example, font-family: 'Apple Garamond Pro', 'Times New Roman';, where Times New Roman is your fallback.
• Then check the actual width (via offsetWidth). If it does not match the offsetWidth of the fallback font, then we know it rendered ok. (The original idea is from http://www.lalit.org/lab/javascript-css-font-detect)

The only caveat is, if the actual font width and the fallback font width do match, then you would have a false negative. So its not bulletproof.

The actionscript to enumerate the fonts and call back out is pretty simple:

Expose the method in the constructor using ExternalInterface:

FontList.as

I used swfobject to load the SWF. Also be sure to enable allowScriptAccess.

The javascript to test the fonts is at: font-detect.js

You can use it by including:

In the end, I don’t think this is useful in practice, but I thought I would share anyway. Its on github too.

Updated: Now uses call straight to actionscript, doesn’t marshall JSON first so its much faster, and other refactoring.