Apples & Rubies
A few months ago I wrote a post about JSON parsing libraries for Cocoa. I compared 4 libraries – BSJSONAdditions, JSON Framework, TouchJSON, and YAJL, I ran a benchmark on all of them, and the conclusion was that YAJL was the fastest and BSJSONAdditions was way slower than the rest.
Last week John Engelhart commented on that post, mentioning his own JSON library JSONKit, claiming that it’s really fast. Of course I had to check if that was true :)
Ever since I started coding in Cocoa, I’ve been wondering what might be the longest name used for any function or constant in the entire API. Cocoa names can get quite long in general, so the longest one should be really ridiculously long… Of course I couldn’t leave it like this and I had to find out what it was :)
I ran a search for *.h files on the whole disk, and I determined that the interesting stuff was either in /Developer or in /System/Library/Frameworks, so I limited the search to these directories only. I passed the list of all header files through a Ruby script that looked for the really long ones and sorted them by length, and then I analyzed the results to find the winners (I decided to divide them into a few categories).
So here’s what I’ve found:
Update: A new post from December 2010 with updated stats is available here.
For a few weeks I’ve been working on a new iPhone application.
Like most of other Cocoa apps I’ve written so far, this app also includes a JSON parser to load some kind of data from a server. The first thing the application does when it starts is connect to the JSON API, download a data file (about 100 KB) and parse it. This used to take about 10-15 seconds on the device, and I thought it was reasonable until I noticed that the HTTP response actually arrives after a second or so. So what was it doing for the rest of the time? I had to find out.
So I did some debugging, and it turned out that the 10 seconds are spent just on parsing the downloaded JSON file. That’s pretty bad… Like in all previous apps, I used an open source library BSJSONAdditions, which I knew wasn’t the fastest one available, but I never had any major problems with it before. On the other hand, I never tested it on a 100 KB file…
I knew there were a few other JSON parser libraries in ObjC, so I decided to make a small benchmark and see how well they all compared to the one I used. The other libraries I tried were: JSON Framework, TouchJSON and YAJL.
As I’ve promised in the previous post, I’ve started working on my first iPhone application, the Blip.pl client, which I’ve given an extremely creative name, xBlip :) (why “x”? that’s simple, because “i”, “m” and “a” were taken, “i” even twice :).
A few screenshots from the current version:
For the last few months, I’ve been spending a lot of time learning how to create apps for the Mac. Since I’m slowly starting to run out of new tutorials to read, I’ve decided to find myself something new to learn ;) Well, not completely new, actually, as a lot of that knowledge about Cocoa is going to be very useful.
I’m talking about iPhone development, of course. I bought an ebook about iPhone SDK from Pragmatic Programmers some time ago, which looks very promising, but I didn’t really start learning, because I wanted to get the iPhone development certificate first, and that took some time. You see, Apple’s platform is so damn open that to install even a “Hello world” on your own phone, you have to have a set of certificates from Apple, which they give you only after you register for an “iPhone developer program” which costs 100$. Really, guys, this is not how you attract developers to a platform… :\
Anyway, I got the certificates now, so I was finally able to run the “Hello world” on my phone :) Here’s a proof:
Photo by Alexander Staubo (CC)
Some time ago I wrote about all the things that I loved in the Cocoa framework. This time, I’d like to write a bit about the worse side of Cocoa – the things that annoy me, confuse me, and make me wonder who the hell came up with such an idea…
So, the things that dislike in Cocoa are:
I read Apple’s tutorial about Interface Builder this week. Most parts of it told about rather basic things and were quite boring, but I’ve learned several useful tricks from it. IB, like most of Apple’s applications, has lots of hidden features which aren’t obvious at first, and can only be found by experimenting, by accident or by reading about them somewhere. Here’s a few things that I’ve learned from the tutorial – some of them are such hidden features, some are just things that weren’t mentioned in any source I’d read before.
I discovered an interesting feature in Interface Builder a few days ago. It seems that it can generate a scaffolding UI for you based on a CoreData model. It works like this: first you have to design a data model in XCode model editor (which you have to do anyway if you want to use Core Data; if you don’t, it won’t make sense to draw the model only to get the scaffold UI, it will be faster to make it yourself…). Let’s say you have a model like in this picture:
