Here’s a test that proves this assertion:

1. Create a server-side web app with your preferred language, and print all the request headers; for example, in PHP: [source:php] $v) { if(ereg(‘HTTP_(.+)’,$h,$hp)) { echo “
2. $h = $v
\n”; } } ?> [/source]
3. Launch MobileSafari.app in either the iPhone Simulator or in your iPhone or iPod touch, and access the server-side script you created previously:
4. Add the application to your home screen, tapping the “+” button on the toolbar:
5. Now launch the application from your home screen, and this is what you see:
6. Compare the outputs (above, those from the latest iPhone Simulator, and below, those from my iPhone 3G with iPhone OS 3.1.2):

   Safari:	HTTP_USER_AGENT = Mozilla/5.0 (iPhone; U; CPU iPhone OS 3_1_2 like Mac OS X; en-us) AppleWebKit/528.18 (KHTML, like Gecko) Version/4.0 Mobile/7D11 Safari/528.16
   Home Screen App:	HTTP_USER_AGENT = Mozilla/5.0 (iPhone; U; CPU iPhone OS 3_1_2 like Mac OS X; en-us) AppleWebKit/528.18 (KHTML, like Gecko) Mobile/7D11

   The texts in italic show the differences between the two outputs.

This difference (in italic above) is only visible when the HTML generated by the server-side script contains the <meta name="apple-mobile-web-app-capable" content="yes" /> tag, which triggers this change of behaviour. Otherwise, the outputs are exactly the same. Most annoyingly, this behavior is not documented (at least not that I am aware of). This problem has already been spotted elsewhere (scroll down until you see the comment by DVO published on Jul 3, 2009 at 7:34 AM; thanks to my friend Bertrand for the link!).

This is not only weird, but it also might break libraries used to generate iPhone-ready websites out of existing web apps (by redirecting the browser using the information in the USER_AGENT header; for example, this is what happens with the current version of the Rails iUI plugin (which is why I found this behaviour :)

The lesson of all of this mess is this: if you have to test for Safari on the iPhone, do not use the word “Safari”, but rather use “AppleWebKit” and “Mobile”, to be sure of catching also the users who installed your application in their home screen.

Update, 2009-10-30: In particular, the line of the Rails iUI plugin that causes problem with this particular behavior is this one.

Fatal error: Call to a member function on a non-object in /home/user/www/wp-admin/includes/dashboard.php on line 647

This has been reported in the WordPress site but no fix has been provided. I found elsewhere a possible fix, but in my case, the new URL would not be saved at all, and the problem would persist.

I fixed it using a good old method, enabled by Open Source™: editing the code directly; I’m posting it here for those of you who would like to do it, until 2.8.1 is released:

[source:php:firstline(646)] $author = $item->get_author(); if ($author == NULL) { $site_link = “”; $publisher = “Someone”; } else { $site_link = esc_url(strip_tags($author->get_link())); if ( !$publisher = esc_html(strip_tags($author->get_name()))) $publisher = __(‘Somebody’); if ($site_link) $publisher = “$publisher“; else $publisher = “$publisher“; } [/source]

I won’t go dive through the basics; I think that Scott Stevenson did a great job in his “Learn Objective-C” tutorial at CocoaDevCentral, from where the image below comes. I’m just going to highlight some iPhone-specific issues here and there, and provide some hints on how to solve them.

To begin with, some important background information:

• The iPhone 3G has 128 MB of RAM, but at least half of it might be used by the OS; this might leave as little as 40 MB to your application… but remember: you will get memory warnings even if you only use 3 MB;
• The iPhone does not use garbage collection, even if it uses Objective-C 2.0 (which can use garbage collection on Leopard, nevertheless);
• The basic memory management rule is: for every [ alloc | retain | copy ] you have to have a [ release ] somewhere;
• The Objective-C runtime does not allow objects to be instantiated on the stack, but only on the heap; this means that you don’t have “automatic objects”, nor things like auto_ptr objects to help you manage memory;
• You can use autorelease objects; but watch out! Since they are not released until their pool is released, they can become de facto memory leaks for you…;
• The iPhone does not have a swap file, so forget about virtual memory. When there is no more memory, there is no more memory.

Having said this, here’s my list of tips:

• Respond to Memory Warnings
• Avoid Using Autoreleased Objects
• Use Lazy Loading and Reuse
• Avoid UIImage’s imageNamed:
• Build Custom Table Cells and Reuse Them Properly
• Override Setters Properly
• Beware of Delegation
• Use Instruments
• Use a Static Analysis Tool
• Use NSZombieEnabled

Respond to Memory Warnings

Whatever you do in your code, please do not forget to respond to memory warnings! I can’t stress this much. I have seen application crashes just because the handler methods were not present on the controllers, which means that, even if you do not have anything to clear in your controller, at least do this:

[source:C] - (void)didReceiveMemoryWarning { [super didReceiveMemoryWarning]; } [/source]

And you might as well respond to them on your application delegate, as follows:

[source:C] - (void)applicationDidReceiveMemoryWarning:(UIApplication *)application { [[ImageCache sharedImageCache] removeAllImagesInMemory]; } [/source]

For the description of the ImageCache class, continue reading ;)

Or finally, as an NSNotification:

[source:C] NSNotificationCenter *center = [NSNotificationCenter defaultCenter]; [center addObserver:self selector:@selector(whatever:) name:UIApplicationDidReceiveMemoryWarningNotification object:nil]; [/source]

Avoid Using Autoreleased Objects

Autoreleasing objects is easy and useful, but on the iPhone you should be careful with it. By default there is an NSAutoreleasePool instance created for you at the beginning of the main() function, but this pool is not cleared up until your application quits! This means that during runtime, your autoreleased objects are de facto memory leaks, since they are retained until the application quits. (please see the comments below; I have experienced better performance when avoiding autoreleased objects, but my understanding of pools is misleading :)

I started getting a better performance from my iPhone apps when I stopped using some methods creating autoreleased objects, for example:

[source:C] // Instead of NSString *string = [NSString stringWithFormat:@"value = %d", intVariable];

// use NSString *string = [[NSString alloc] initWithFormat:@”value = %d”, intVariable]; … [string release]; [/source]

In version 2.0 of the iPhone OS there was also the problem that some “convenience methods” did not work at all; I’m sure you’ve experienced your application crashing when using NSDictionary’s dictionaryWithObjects:forKeys: and then finding out that a replacing that with initWithObjects:forKeys: made your application run just fine. The NDA did not help at the time!

This does not mean that you can’t use autoreleased objects; you should use them, for example, when you have factory methods returning objects not owned neither by the factory nor by the client calling it. You can also use autorelease pools in loops, when you need to allocate lots of small objects, but remember to release the pool right afterwards:

[source:C] NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init]; for (id item in array) { id anotherItem = [item createSomeAutoreleasedObject]; [anotherItem doSomethingWithIt]; } [pool release]; [/source]

Remember to always release the pool in the same context where it was created. CocoaDev has an interesting discussion about using NSAutoreleasePools in loops.

Oh, and please, never release an autoreleased object on the iPhone: your application will crash almost instantly.

Use Lazy Loading and Reuse

If your application consists of several different controllers embedded into each other, defer their instantiation until the last possible moment; this means in practical terms that your init method is minimalistic, and that you do more stuff when you need it; the example below is a typical list + detail layout, using a UITableViewController subclass inside a UINavigationController:

[source:C] @interface UITableViewControllerSubclass { @private NSMutableArray *items; DetailController *detailController; UINavigationController *navigationController; } @end [/source]

[source:C] @implementation UITableViewControllerSubclass

pragma mark -

pragma mark Constructors and destructors

• (id)init { if (self = [self initWithStyle:UITableViewStylePlain]) { // only basic stuff items = [[NSMutableArray] alloc] initWithCapacity:20]; navigationController = [[UINavigationController alloc] initWithRootViewController:self]; } return self; }

• (void)dealloc { [items release]; [detailController release]; [navigationController release]; [super dealloc]; }

// …

pragma mark -

pragma mark UITableViewDelegate methods

• (void)tableView:(UITableView *)tableView didSelectRowAtIndexPath:(NSIndexPath *)indexPath { Item *item = [items objectAtIndex:indexPath.row]; if (detailController == nil) { detailController = [[DetailController alloc] init]; } detailController.item = item; [self.navigationController pushViewController:detailController animated:YES]; }

// …

@end [/source]

As you can see in the example above, not only we are creating a DetailController instance only when needed (that is, when the user taps on an item in the UITableView), but we’re reusing it every time the user taps on another cell of the table; this has another benefit: a reduction of object allocation and instantiation, which also helps increasing performance a little bit.

You could also use UIViewController’s viewWillAppear: and viewDidDisappear: methods to perform some kind of lazy loading initialization and release, and if you really need to go further, you could use the UITabBarControllerDelegate’s tabBarController:didSelectViewController: method to load and unload parts of your application from memory, as you need it.

Avoid UIImage’s imageNamed:

Alex Curylo has written an absolutely great article about the problems with UIImage’s imageNamed: static method. It seems (and in my tests this appears to be true) that the iPhone OS (versions 2.0 and 2.1 at least) uses an internal cache for images loaded from disk using imageNamed:, and that in cases of low memory this cache is not cleared up completely (this seems to be corrected with version 2.2, though, but I cannot confirm).

Since I have projects that must run on version 2.0 of the iPhone OS, I have created a UIImage category with the following method:

[source:C] @implementation UIImage (AKLoadingExtension)

• (UIImage *)newImageFromResource:(NSString *)filename { NSString *imageFile = [[NSString alloc] initWithFormat:@”%@/%@”, [[NSBundle mainBundle] resourcePath], filename]; UIImage *image = nil; image = [[UIImage alloc] initWithContentsOfFile:imageFile]; [imageFile release]; return image; }

@end [/source]

The name of the method includes the word “new”, to comply with Objective-C’s naming guidelines, since the object we’re returning to the caller is not autoreleased and has a retain count of 1. The caller is then owner of the UIImage and responsible to release it.

Once I have this UIImage instance, I place it in an image cache with this interface:

[source:C]

import

@interface ImageCache : NSObject { @private NSMutableArray *keyArray; NSMutableDictionary *memoryCache; NSFileManager *fileManager; }

• (ImageCache *)sharedImageCache;

• (UIImage *)imageForKey:(NSString *)key;

• (BOOL)hasImageWithKey:(NSString *)key;
• (void)storeImage:(UIImage *)image withKey:(NSString *)key;
• (BOOL)imageExistsInMemory:(NSString *)key;
• (BOOL)imageExistsInDisk:(NSString *)key;
• (NSUInteger)countImagesInMemory;
• (NSUInteger)countImagesInDisk;
• (void)removeImageWithKey:(NSString *)key;
• (void)removeAllImages;
• (void)removeAllImagesInMemory;
• (void)removeOldImages;

@end [/source]

Basically, ImageCache can be configured to have a fixed size in memory, and the images that were added first are removed first. It loads the images from the disk as required, keeping a copy in memory, and as suggested by Alex, you can remove them from memory in case of a warning:

[source:C] - (void)applicationDidReceiveMemoryWarning:(UIApplication *)application { [[ImageCache sharedImageCache] removeAllImagesInMemory]; } [/source]

The complete source code of this ImageCache class, together with some unit tests (thanks to the Google Toolkit for Mac), is available on the Projects section of this blog for you to download and play with.

Build Custom Table Cells and Reuse Them Properly

Remember to always use static NSString identifiers for your cells, which helps the UITableView class to reuse them and reduce memory consumption:

[source:C] - (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath { Item *item = [items objectAtIndex:indexPath.row]; static NSString *identifier = @”ItemCell”;

ItemCell *cell = (ItemCell *)[tableView
      dequeueReusableCellWithIdentifier:identifier];
if (cell == nil)
{
    cell = [[[ItemCell alloc] initWithIdentifier:identifier]
                                                    autorelease];
}
cell.item = item;
return cell;

} [/source]

I also avoid using NIBs when working with table cells, for performance reasons. I prefer to draw the cells through my own subclasses of UITableViewCell, themselves using overridden setters for their properties, which takes me to the next point.

Override Setters Properly

As I said above, I tend to create my own subclasses of UITableViewCell, providing a simple property through which I change the model class holding the data that the cell is supposed to show. This has the effect of changing all the values of the fields and labels to the values corresponding to those of the model instance.

To do that, I override the setters as follows; for the following class definition…

[source:C] @interface SomeClass { @private NSArray *items; NSString *name; id delegate; }

@property (nonatomic, retain) NSArray *items; @property (nonatomic, copy) NSString *name; @property (nonatomic, assign) id delegate; @end [/source]

… I use the following implementation:

[source:C] @implementation SomeClass

@synthesize items; @synthesize name; @synthesize delegate;

• (void)dealloc { [items release]; [name release]; delegate = nil; }

pragma mark -

pragma mark Overridden setters

• (void)setItems:(NSArray *)obj { if (obj == items) { return; // thanks Marco! (see comment #3 below) } [items release]; items = nil; items = [obj retain];

  if (items != nil) { // create the internal structure of the cell // if not present, and change the widget values } }

• (void)setName:(NSString *)obj { [name release]; name = nil; name = [obj copy]; // I always copy NSStrings!

  if (name != nil) { // create the internal structure of the cell // if not present, and change the widget values } }

• (void)setDelegate:(id)obj { // do not retain! This is an “assign” property delegate = obj;

  if (delegate != nil) { // create the internal structure of the cell // if not present, and change the widget values } }

@end [/source]

Overriding setters properly is important because you might be introducing memory leaks if done wrong. I usually copy all my NSString properties too, as a rule of thumb.

Beware of Delegation

If your code is delegate of some other object which you are about to release, remember to set its delegate property to nil before releasing it; otherwise, the object might “think” that its delegate is still there, and will send a message to an invalid pointer. To see what I’m talking about, consider this code:

[source:C] @interface SomeClass { @private Widget *widget; } @end [/source]

[source:C] @implementation SomeClass

• (id)init { if (id = [super init]) { widget = [[Widget alloc] init]; widget.delegate = self; } return self; }

• (void)dealloc { // widget might be retained by someone else! widget.delegate = nil; [widget release]; [super dealloc]; }

pragma mark -

pragma mark WidgetDelegate methods

• (void)widget:(Widget *)obj callsItsDelegate:(BOOL)value { // and here something happens… }

@end [/source]

SomeClass is delegate of Widget. Widget instances might be retained by someone else, which means that even after the release message in the dealloc method, widget might still be alive and call its delegate; if this variable is not nil, widget will send a message to a non-existent object, which will surely crash your application.

Use Instruments

The “Leaks” instrument is your friend, and you should use it after you write the first line of code. Typically, I launch it every time before doing a checkin of some new code. In Xcode, select “Run / Start with Performance Tool / Leaks” and you’re done. You can use it in the simulator or on your device.

Use a Static Analysis Tool

Use the LLVM/Clang Static Analyzer tool. This amazing tool will catch naming errors (regarding the Objective-C naming conventions) and some hidden memory leaks, which are particularly nasty when using CoreFoundation libraries (Address Book, sound, CoreGraphics, etc). You can add it to your daily build script, it’s very easy to use.

But you must use it. Enough said.

Use NSZombieEnabled

Lou Franco has posted an excellent article about how to use NSZombieEnabled in your development cycle. The idea is to be able to find which messages are being sent to invalid pointers, referencing objects which have been released somewhere in your code. Always remember who’s the owner of your objects, and check for existence elsewhere!

And You?

How about you? What are your tips or best practices you usually use for your iPhone apps? Feel free to share them in the form below.

Update, 2009-01-29: I am overwhelmed with the response and traffic that this post has gotten so far! Yesterday evening I had the pleasure of discussing this subject with the guys of the iPhone Developers Facebook group, and I got interesting remarks from Marco Scheurer from Sen:te (including a comment below), which I’ve added to this post today.

Oh, and by the way, I’ve uploaded the slides here! They have a Creative Commons license, so feel free to use them if you find them useful.

HTTP Basic Authentication Protocol

This is the simplest HTTP Authentication protocol available:

1. The browser sends a request to a protected resource: GET /index.html
2. The server looks for the “Authenticated” header in the request; since it does not find it, it replies back with a response with the 401 code (“Unauthorized”). The response contains a “WWW-Authenticate” header, with the value “Basic”. This response is called a “challenge”, and it also contains a “realm” text, which describes the protected resource in clear text (the “realm” is shown in the pop-up window that usually appears for you to type your password when this protocol is used).
3. The browser creates a new request GET /index.html that contains an HTTP_AUTHORIZATION header, whose value is the word “Basic” followed by the ‘username:password’ string encoded in base 64. This algorithm is a two-way algorithm: you can retrieve the username and password from the base 64-encoded string.
4. The server receives this response, and since base 64 is a two-way algorithm, it compares the MD5 (or SHA1) password hash to the one stored in the database. If they are the same, the request is processed. Otherwise, the user gets a 401 again.

The advantage of this protocol is that it is simpler to implement, but the tradeoff is that any malicious user sniffing on the network can retrieve the username:password combo and use the base 64 algorithm to get the original values. All of this makes this protocol relatively insecure.

HTTP Digest Authentication Protocol

Simply put, the HTTP Digest Authentication protocol goes like this:

1. The browser sends a request to a protected resource: GET /index.html
2. The server looks for the “Authenticated” header in the request; since it does not find it, it replies back with a response with the 401 code (“Unauthorized”). The response contains a “WWW-Authenticate” header, with the value “Digest” followed by two long MD5 strings (“nonce” and “opaque”) generated specifically for this request, and that the browser will use to answer back to the server. This response is called a “challenge”, and it also contains a “realm” text, which describes the protected resource in clear text (the “realm” is shown in the pop-up window that usually appears for you to type your password when this protocol is used).
3. The browser creates a new request GET /index.html but this time it will not send the username/password combo in clear text (like in the case of HTTP Basic Authentication): it will “hash” this information, together with the “nonce” and “opaque” values received from the server, together with the “realm”, using the MD5 hashing algorithm. This is a username/realm/password hash, so to speak.
4. The server receives this response, and since MD5 is a one-way algorithm (you cannot, theoretically, find the original password from all the blah-blah sent in step 3), it compares the username/realm/password hash to the one stored in the database. If they are the same, the request is processed. Otherwise, the user gets a 401 again.

The advantage of the HTTP Digest Authentication protocol is that the key exchange between client and server is done in encrypted hashes. Even better, the server does not store the password per se, but a complex mix of strings all hashed together. This makes the protocol a very secure option, but at the same time, it requires more processing time and code to execute.

However, the HTTP Digest Authentication protocol implies several design issues:

1. The username/realm/password combo is encoded and stored using the “realm” string. So this means that if the realm changes, all the passwords become invalid. And since MD5 is a “one-way” algorithm, you cannot retrieve the passwords, and your users must retype them. Be careful!
2. Since the default user classes in most web programming toolkits (Django, Rails, etc) just store an MD5 (or SHA1) hash of the password, to use HTTP Digest Authentication you must have a separate database field, somewhere, to store the username/realm/password combo hash.

Update: I admit, it also has a bit to do with the reading of today’s entry in Coding Horror ;) But I love WordPress nonetheless. I prefer it over MovableType (which I used during one year and a half).

The only glitch was: at first, it didn’t work. I think you know the feeling.

The plugin was enabled, everything was activated, yet no files were cached: exactly this same problem. And I found a quick fix to it, hence this post: fire your FTP client of choice and go to /wp-content/cache. If you don’t see a “supercache” folder in there, just create it. Magically, if you have some traffic on your blog and you dig in that folder a couple of seconds later you’ll see already lots of files! No need to modify .htaccess whatsoever.

If you want to populate it, log out of the WordPress admin and start clicking on your blog. This plugin only creates cached files for anonymous visitors! I also turned on the compression so you should start having faster response times.

It was the only thing to do manually to get it working. Hope this helps! Any comments, as usual, more than welcome.

Frankly, it’s not easy. At all (actually this is why I think MySQL is so popular, because of the ease of installation!) So hang tight and read on.

Installation

Russ Brooks says it is better to avoid MacPorts: I must say that indeed, I tried installing PostgreSQL with MacPorts and I got seriously stuck, unable to do anything with it, not even starting the server. So I uninstalled the PostgreSQL MacPorts package and found other options: a PostgreSQL for Mac installer, and Marc Liyanage’s own installer. I decided to go with the first one, since Marc’s installs version 8.1 of the server, and PostgreSQL for Mac offers version 8.3.

The installation goes without trouble, using a standard installer (which means that you need administrative privileges, as usual). However, you want to read these explanations before doing anything ;)

NOTE: if you have trouble installing PostgreSQL using the above installer (as I did after the unsuccessful MacPorts installation / desinstallation), open Terminal.app and try these commands:

$ sudo dscl localhost >cd Local/Default/Users/ >ls

If you see a “postgres” entry in the list of local users, delete it and re-run the installer:

>delete postgres

After the Installation

The installer puts the PostgreSQL installation into /Library/PostgreSQL8. You should add the path to the PostgreSQL binaries in your PATH environment variable before doing anything else:

export PATH=/Library/PostgreSQL8/bin:$PATH (bash) setenv PATH /Library/PostgreSQL8/bin:$PATH (tcsh)

Then, type the following commands to create the default database, owned by the “postgres” user:

cd /Library/PostgreSQL8/ sudo rm -r data sudo mkdir data sudo chown postgres:postgres data cd bin sudo -u postgres initdb -E utf8 /Library/PostgreSQL8/data

In my case (Leopard-powered PowerBook G4) I had the “Shared Memory error” that Russ talks about. So I followed his advice: I created a file named /etc/sysctl.conf with the following contents, then rebooted my computer and everything went fine:

kern.sysv.shmmax=4194304 kern.sysv.shmmin=1 kern.sysv.shmmni=32 kern.sysv.shmseg=8 kern.sysv.shmall=1024

I also used dscl to change the password of the postgres user (otherwise, how to know which is it??)

>passwd postgres postgres

The installer adds some handy utilities on your /Application folder (see the image above). You can also use pgAdmin to manage the database server. Very handy. I tried to use phpPgAdmin but without success (can’t get past the login screen… :(

And that’s it! There are interesting resources out there explaining how to use it from Rails or Django, so I’ll start reviewing them…

Enter vobject. This Python library is part of the Chandler effort (which seems to be somewhat ill-fated since Mitch Kapor announced he was leaving the project). Anyway, you can download this library from here and then install it using the common sequence:

python setup.py build python setup.py install

Finally, here’s a bit of code to quickly extract the names and e-mail addresses from a vCard file called “vCards.vcf” containing lots of vCard instances, one after the other (AddressBook.app exports data this way, instead of creating on file per contact):

[source:python] import vobject

f = open(“vCards.vcf”) s = “”.join(f.readlines()) f.close()

a = vobject.readComponents(s)

counter = 0

while True: try: # “next()” seems to throw an exception # when there aren’t any more “Components” # in the stream… # Talk about nice flow control! b = a.next() counter += 1 if b.contents.has_key(‘email’): # “repr()” below avoids # unicode –> ascii exceptions print repr(b.fn.value), repr(b.email.value) except: break

print “%d e-mails found.” % counter [/source]

The library documentation, to put it simply, isn’t as good as the library itself (see? I can be politically correct sometimes :) Maybe I missed a better way to iterate over the contents of the whole stream of vCard instances inside the file (using exceptions for that is yuck!), but then again, feel free to add your comments below as usual.

[source:python] import unittest

loader = unittest.TestLoader() tests = loader.loadTestsFromName(‘path.to.your.tests.package’) for test in tests.tests: print test._tests[0].class.name.replace(“Test”, “”) for method in test._tests: print ” %s” % method._testMethodName.replace(“test“, “”).capitalize().replace(“_”, ” “) [/source]

This would yield something like this: Business     Accounts have at least one entry     Clerks cannot close accounts Security     Users can create new accounts     Anonymous users cannot access private areas ...

Of course, you’ll get better results if you follow Google’s naming conventions for your tests… ;) This is not rspec (nor an alternative to it) but it might be useful to some of you.

Just as a reminder for Django users: you might need to

setenv DJANGO_SETTINGS_MODULE application.settings

or

export DJANGO_SETTINGS_MODULE=application.settings

in order to make the script work properly! At least I had to :)

However, the current ohcount distribution (which you can download from this link) does not build out-of-the-box in Leopard. Here’s how I made it work in my own Leopard G4 PowerBook (PPC) computer.

• Download pcre-7.6.tar.gz from SourceForge
• Extract the file into the “pcre-7.6″ folder
• cd into the pcre-7.6 folder and ./configure make sudo make install
• Download ohcount-1.0.0.tar.gz from Ohloh
• Extract the file into the “ohcount-1.0.0″ folder
• cd into the ohcount-1.0.0 folder and open “Rakefile” with your favorite editor; modify line 73 as follows:

[source:ruby::firstline(68)] file “#{EXT_DIR}/Makefile” => “#{EXT_DIR}/extconf.rb” do cd EXT_DIR do if ENV['DEBUG'] ruby ‘extconf.rb’, ‘debug’ else ENV['ARCHFLAGS'] = “-arch ppc” # or “-arch i386″ if you use an Intel Mac ruby ‘extconf.rb’ end end end [/source]

• Now cd into the ohcount-1.0.0 folder and rake the project. You should see a series of tests running, with the final message saying “92 tests, 321 assertions, 0 failures, 0 errors”.
• Now you can use the bin/ohcount binary to get statistics from your source code!

The root of the problem is that Leopard’s Ruby installation is a “Universal Binary”, while the pcre library is built as a native binary only; hence, it does not link for the i386 binary, hence, it does not work. Another solution, I think, would be to compile pcre as a Universal Binary, but I leave this as an exercise to the reader :)

I found the fix thanks to this conversation in Ohloh’s forum, which took me to this thread on ruby-talk and finally this wiki page in MacOS Forge.

Hope this helps!

Below there is a sample of the different ways I’ve found to do a network access to a remote server, using HTTP Basic Authentication and a couple of headers, in PHP, Ruby, Python, JavaScript, and even Objective-C! I’m even generating ActionScript 3.0 code, but I’m not a Flash coder :) So I’ll post the wrappers that work best at the moment, and in the future I’ll include other examples, particularly for .NET, C++ and Java.

In all the cases below, there is a “request” function or method that takes an HTTP verb (GET, POST, PUT, DELETE, etc), a URL (without the slash “/” at the beginning) and some parameter data, in the form of a dictionary. The function wraps the underlying libraries of each programming language, offering a simpler interface, and allowing for HTTP Basic Authentication (for HTTP Digest Authentication it would be much, much more complex!). There are synchronous (useful for server or command-line applications) and asynchronous versions (for GUI systems). Off to the code! In PHP (synchronous):

[source:php] $conf = array( “server” => “localhost”, “username” => “”, “password” => “” );

function request($verb, $url, $parameters = array()) { global $conf; $headers = array( “Content-Type: text/html; charset=utf-8″, “Accept: application/javascript”, “Cache-Control: no-cache”, “Pragma: no-cache”, “Content-length: ” . strlen($xml_data), “Authorization: Basic ” . base64_encode($conf["username"] . “:” . $conf["password"]) );

$path = $conf["server"] . “/” . $url; $conn = curl_init(); curl_setopt($conn, CURLOPT_URL, $path); curl_setopt($conn, CURLOPT_HTTPHEADER, $headers); curl_setopt($conn, CURLOPT_USERAGENT, “Identify yourself!”); curl_setopt($conn, CURLOPT_CUSTOMREQUEST, strtoupper($verb)); curl_setopt($conn, CURLOPT_POSTFIELDS, $xml_data); curl_setopt($conn, CURLOPT_RETURNTRANSFER, 1); $data = curl_exec($conn); $code = curl_getinfo($conn, CURLINFO_HTTP_CODE);

if($code == 200 && strtoupper($verb) == “GET”) { return json_decode($data); } else { return $data; }

curl_close($conn);

return $data; } [/source]

The curl library has a distinctive C smell :) The good thing is that after doing this wrapper, doing the C++ one will be fairly straightforward!

In Ruby (synchronous):

[source:ruby] require ‘net/http’ require ‘uri’ require ‘json’

$conf = { “server” => “localhost”, “username” => “”, “password” => “” }

def request(verb, url, parameters = nil) Net::HTTP.start($conf["server"]) do |http| headers = { “Accept” => “application/javascript”, “User-Agent” => “Identify yourself!” } path = “/” + url req = nil case verb.upcase when “GET”: req = Net::HTTP::Get.new(path, headers) when “POST”: req = Net::HTTP::Post.new(path, headers) when “PUT”: req = Net::HTTP::Put.new(path, headers) when “DELETE”: req = Net::HTTP::Delete.new(path, headers) else raise Exception.new(“Invalid HTTP verb”) end req.basic_auth $conf["username"], $conf["password"] req.set_form_data(parameters) if not parameters == nil response = http.request(req) if response.code == “200″ && verb.upcase == “GET” JSON.parse(response.body) else print response.code + ” ” + response.message + ” ” + response.body end end end [/source]

The Ruby library is the only one I found so far that features the four HTTP verbs in the interface!

In Python (synchronous):

[source:python] import simplejson import httplib, urllib import base64

conf = { “server”: “localhost”, “username”: “”, “password”: “”, }

def request(verb, url, parameters = {}): params = urllib.urlencode(parameters) base64string = base64.encodestring(‘%s:%s’ % (conf["username"], conf["password"]))[:-1] headers = { “Accept”: “application/javascript”, “Authorization”: “Basic %s” % base64string, “User-Agent”: “Identify yourself!”, } conn = httplib.HTTPConnection(conf["server"]) conn.request(verb.upper(), “/” + url, params, headers) response = conn.getresponse() if response.status == 200 and verb.upper() == “GET”: obj = simplejson.loads(response.read()) return obj else: print response.status, response.reason, response.read() conn.close() [/source]

I much prefer the Ruby way, if you ask me. I don’t know, it’s more elegant. I can’t get used to the indenting!

In JavaScript, using Prototype (asynchronous):

[source:javascript] var conf = { server: “localhost”, username: “”, password: “” }; var request = function(verb, url, parameters, successHandler, errorHandler) { // A really ugly way to do HTTP Basic Auth, I know :) var api_url = ["http://", conf.username.replace(/@/, "%40"), ":", conf.password, "@", conf.server, "/", url].join(“”);

new Ajax.Request(api_url, {
    method: verb.toLowerCase(),
    parameters: parameters,
    requestHeaders: {
        "Accept": "application/javascript",
        "Cache-Control": "no-cache",
        "Pragma": "no-cache",
        "Content-Type": "text/html; charset=utf-8"
    },
    onSuccess: function(transport) {
        if(successHandler) successHandler(transport);
    },
    onFailure: function(transport) {
        if(errorHandler) errorHandler(transport);
    }
});

}; [/source]

Again in JavaScript, but this time using jQuery (asynchronous):

[source:javascript] var conf = { server: “localhost”, username: “”, password: “” }; var request = function(verb, url, parameters, successHandler, errorHandler) { var api_url = ["http://", conf.username.replace(/@/, "%40"), ":", conf.password, "@", conf.server,"/", url].join(“”);

$.ajax({
    type: verb.toUpperCase(),
    url: api_url,
    async: true,
    data: parameters,
    cache: false,
    // jQuery does not allow to change headers otherwise (?) than using the beforeSend() hook:
    beforeSend: function(xhr) {
        xhr.setRequestHeader("Content-Type", "text/html; charset=utf-8");
        xhr.setRequestHeader('Accept', 'application/javascript');
        xhr.setRequestHeader('Cache-Control', 'no-cache');
        xhr.setRequestHeader('Pragma', 'no-cache');
    },
    complete: function(engine, textStatus) {
        if (engine.readyState == 4) {
            if (engine.status == 200 || engine.status == 201) { if(successHandler) successHandler(engine); }
            else { if(errorHandler) errorHandler(engine); }
        }
    }
});

}; [/source]

The last JavaScript one, but this time using bare bones XMLHttpRequest (asynchronous):

[source:javascript] var conf = { server: “localhost”, username: “”, password: “” }; var request = function(verb, url, parameters, successHandler, errorHandler) { var api_url = ["http://", conf.username.replace(/@/, "%40"), ":", conf.password, "@", conf.server,"/", url].join(“”);

var params = [];
for(var item in parameters) {
    params.push(escape(item) + "=" + escape(parameters[item]));
}
var engine = null;
if (window.XMLHttpRequest) {
    engine = new XMLHttpRequest();
}
if (window.ActiveXObject) {
    engine = new ActiveXObject("Microsoft.XMLHTTP");
}
engine.onreadystatechange = function stateChange() {
    if (engine.readyState == 4) {
        if (engine.status == 200 || engine.status == 201) { if(successHandler) successHandler(engine); }
        else { if(errorHandler) errorHandler(engine); }
    }
};
engine.open(verb.toUpperCase(), api_url, true);
// setRequestHeader() must be called AFTER open() !!
engine.setRequestHeader("Content-Type", "text/html; charset=utf-8");
engine.setRequestHeader('Accept', 'application/javascript');
engine.setRequestHeader('Cache-Control', 'no-cache');
engine.setRequestHeader('Pragma', 'no-cache');
engine.send(params.join("&"));

};

[/source]

To use these JavaScript versions, just pass a couple of functions as parameters, and you’re done; they will be called in case of success or error, asynchronously.

Finally, the Cocoa / Objective-C wrapper (both synchronous and asynchronous, header and implementation files):

[source:c] /* Command-line example that uses this library:

import

int main (int argc, const char * argv[]) { NSAutoreleasePool * pool; pool = [[NSAutoreleasePool alloc] init];

AKResourceSubClass* resource;
resource = [[AKResourceSubClass alloc] init];
[resource get];
NSDictionary* plist = [resource getPropertyList];
// Do something with the results...
[pool drain];
return 0;

} */

import

@interface AKResource : NSObject { NSMutableData* receivedData;

NSString* mimeType;
NSString* server;
NSString* username;
NSString* password;
BOOL async;

}

-(id)init; -(void)setServer:(NSString)serverName; -(void)setUsername:(NSString)user andPassword:(NSString)pwd; -(void)connection:(NSURLConnection *)connection didReceiveResponse:(NSURLResponse *)response; -(void)connection:(NSURLConnection *)connection didReceiveData:(NSData *)data; -(void)connection:(NSURLConnection *)connection didFailWithError:(NSError *)error; -(void)connectionDidFinishLoading:(NSURLConnection *)connection; -(void)sendRequestTo:(NSString)urlString usingVerb:(NSString)verb withParameters:(NSDictionary)parameters; -(void)setAsynchronous:(BOOL)asynchronously; -(NSDictionary)getPropertyList; -(NSString)getResponseText;

@end [/source]

Now the implementation file:

[source:c]

import “AKResource.h”

@implementation AKResource

-(id)init { self = [super init];

if(self)
{
    receivedData = [[NSMutableData alloc] init];
    mimeType = @"application/plist";
    server = @"localhost";
    username = @"";
    password = @"";
    async = NO;
}
return self;

}

-(void)setServer:(NSString*)serverName { server = serverName; }

-(void)setUsername:(NSString)user andPassword:(NSString)pwd { username = user; password = pwd; }

-(void)sendRequestTo:(NSString)resource usingVerb:(NSString)verb withParameters:(NSDictionary)parameters { NSURL url = [NSURL URLWithString:[NSString stringWithFormat:@"http://%@/%@", server, resource]];

NSMutableDictionary* headers = [[NSMutableDictionary alloc] init];
[headers setValue:@"text/html; charset=utf-8"
    forKey:@"Content-Type"];
[headers setValue:mimeType forKey:@"Accept"];
[headers setValue:@"no-cache" forKey:@"Cache-Control"];
[headers setValue:@"no-cache" forKey:@"Pragma"];
NSMutableURLRequest* request;
request = [NSMutableURLRequest requestWithURL:url
            cachePolicy:NSURLRequestUseProtocolCachePolicy
            timeoutInterval:60.0];
[request setHTTPMethod:verb];
[request setAllHTTPHeaderFields:headers];
if (parameters)
{
    NSMutableString* params = [[NSMutableString alloc] init];
    for (id key in parameters)
    {
        [params appendFormat:@"%@=%@&",
            [key stringByAddingPercentEscapesUsingEncoding:NSUTF8StringEncoding],
            [[parameters objectForKey:key]
                stringByAddingPercentEscapesUsingEncoding:NSUTF8StringEncoding]];
    }
    [params deleteCharactersInRange:NSMakeRange([params length] - 1, 1)];
    NSData* body = [params dataUsingEncoding:NSUTF8StringEncoding];
    [request setHTTPBody:body];
}
if (async)
{
    NSURLConnection* connection;
    connection = [[NSURLConnection alloc]  initWithRequest:request
                                            delegate:self
                                            startImmediately:YES];
    if (!connection)
    {
        NSLog(@"Could not open connection to resource");
    }
}
else
{
    NSURLResponse* response = [[NSURLResponse alloc] init];
    NSError* error = [[NSError alloc] init];
    NSData* data = [NSURLConnection
        sendSynchronousRequest:request
        returningResponse:&response
        error:&error];
    [receivedData setData:data];
}

}

-(void)connection:(NSURLConnection *)connection didReceiveAuthenticationChallenge:(NSURLAuthenticationChallenge *)challenge { NSURLCredential *newCredential; newCredential = [NSURLCredential credentialWithUser:username password:password persistence:NSURLCredentialPersistenceNone]; [[challenge sender] useCredential:newCredential forAuthenticationChallenge:challenge]; }

-(void)connection:(NSURLConnection )connection didReceiveResponse:(NSURLResponse *)response { NSHTTPURLResponse httpResponse; httpResponse = (NSHTTPURLResponse)response; int statusCode = [httpResponse statusCode]; if (statusCode != 200) { NSMutableDictionary info; info = [NSMutableDictionary dictionaryWithObject:[response URL] forKey:NSErrorFailingURLStringKey]; [info setObject:@"An error code different than 200 was received!" forKey:NSLocalizedDescriptionKey]; NSError* error = [NSError errorWithDomain:@"API Wrapper" code:statusCode userInfo:info]; NSDictionary* errorData = [NSDictionary dictionaryWithObject:error forKey:@"error"];

    [[NSNotificationCenter defaultCenter]
        postNotificationName:@"ConnectionDidFailWithStatusCodeNotOK"
        object:self
        userInfo:errorData];
}
[receivedData setLength:0];

}

-(void)connection:(NSURLConnection *)connection didReceiveData:(NSData *)data { [receivedData appendData:data]; }

-(void)connection:(NSURLConnection *)connection didFailWithError:(NSError *)error { [connection release];

NSDictionary* errorData = [NSDictionary
                            dictionaryWithObject:error
                            forKey:@"error"];
[[NSNotificationCenter defaultCenter]
    postNotificationName:@"ConnectionDidFailWithError"
    object:self
    userInfo:errorData];
NSLog(@"Connection failed! Error - %@ %@",
      [error localizedDescription],
      [[error userInfo] objectForKey:NSErrorFailingURLStringKey]);

}

-(void)connectionDidFinishLoading:(NSURLConnection *)connection { [[NSNotificationCenter defaultCenter] postNotificationName:@”ConnectionDidFinishLoading” object:self]; [connection release]; }

-(void)setAsynchronous:(BOOL)asynchronously { async = asynchronously; }

-(NSDictionary)getPropertyList { NSString errorStr = nil; NSDictionary* propertyList; NSPropertyListFormat format;

propertyList = [NSPropertyListSerialization
                propertyListFromData:receivedData
                mutabilityOption: NSPropertyListImmutable
                format: &format
                errorDescription: &errorStr];
return propertyList;

}

-(NSString*)getResponseText { return [[NSString alloc] initWithData:receivedData encoding:NSUTF8StringEncoding]; }

@end [/source]

Rather verbose this last one huh? Objective-C has a distinctive characteristic, inherited from Smalltalk (I suppose): methods with named parameters, like “stringByAddingPercentEscapesUsingEncoding:NSUTF8StringEncoding” (decidedly, one of the longest method calls ever :) The good thing is that the code reads like a book. This is why I like this language, as well as Ruby: you can read code in these languages very easily.

Another nice aspect of this Objective-C wrapper is that if you have an API that can return “Property Lists” (like the one I’ve been working on lately), you can send object graphs serialized in XML that are completely Cocoa-compatible. That’s what the getPropertyList method does: client code can deal with standard NSDictionary instances, no need to do anything else!

Of course these are not the only ways to do this, but so far these wrappers have helped me a lot. Don’t hesitate to leave your comments below! And most important, have fun! As always, use this code at your own risk.