BJ Homer's Blog

Detecting backspace in a UITextField

2011-11-17T07:17:00.001-08:00

I recently had need for a token field for iOS while implementing a "To:" field like the one in Mail.app. I ran into a problem, though. The token field consists of a label, some number of tokens, and a borderless UITextField at the end where the user can enter text for the next token. It looks something like this, if you'll forgive the ASCII art:

-------------------------------------------------
| To:  (token1) (token2) (token3) _____________ |
-------------------------------------------------
   ^         ^     ^      ^             ^
UILabel          tokens           UITextField

In Mail.app, if you're at the far left of the text field and hit the backspace key, the rightmost token will be highlighted. Another backspace deletes the token and puts focus back in the text field. But there's a problem. UITextField provides no way to detect a backward delete at the beginning of the field.

Part 1: Discovery

You'd think this would be simple, but it's not. Some of my early attempts included:

Implementing -textField:shouldChangeCharactersInRange:replacementString: in the text field's delegate and looking for an attempt change the range at (0,0). No dice—it's not called if the text isn't actually going to change.
Subclassing UITextField and overriding the -deleteBackward method (part of the UIKeyInput protocol, which UITextField conforms to via UITextInput). -[UITextField deleteBackward] is never called when the backspace key is pressed.
Subclassing UITextField and overriding various methods declared in the UITextInput protocol, such as -replaceRange:withText:, -setSelectedTextRange:, etc. Surprisingly, none of these are called either—despite declaring conformance to the UITextInput protocol, it seems that UIKit doesn't actually use any of those methods when handling keyboard input.

So, we've got a UITextField that claims to implement all these text-handling methods, and yet it doesn't seem to use them when handling keyboard input. It's probably forwarding them on to some other object, but how could we find out who that other object is?

DTrace, of course.

Using a boilerplate app containing a single UITextField, I pulled out Instruments and added a Trace instrument for -[* delete*].

That is, "Trace every ObjC call to any object where the selector starts with the word 'delete'." I launched the app and waited for things to quiet down, then tapped in the text field and hit the backspace key on the keyboard. Immediately, a few delete-related methods showed up, including this stack trace:

Why hello there, UIFieldEditor with a UITextInputAdditions category. We've been looking for you.

I love DTrace.

Part 2: Digging through the dump

Okay, so we know there's something called a UIFieldEditor, and since UITextField wasn't involved at all in the above stack trace, we can guess that the field editor may be doing all of the heavy lifting. So let's look at UIFieldEditor a bit deeper.

If we class-dump UIFieldEditor in UIKit, we see that the first three methods in its method list are these:

+ (void)releaseSharedInstance;
+ (id)sharedFieldEditor;
+ (id)activeFieldEditor;

So it appears that the UIFieldEditor receiving keyboard input is likely a shared object that is reused whenever the first responder needs keyboard input. Since there can only be one first responder at a time, there's probably no need for more than one UIFieldEditor.

Class-dump also tells us that UIFieldEditor is a subclass of UIWebDocumentView. This is interesting, because a bit of time in DTrace will also confirm that -[UITextField deleteBackward] calls down to [UIWebDocumentView deleteBackward]. It looks like the field editor is a view that gets overlaid on top of text input views, and probably handles most of the text editing experience.

So rather than subclassing UITextField, it looks like we really want to be subclassing UIFieldEditor if we want to do something special with -deleteBackward.

Part 3: Dark Runtime Magic

We've got two problems down the "Subclass UIFieldEditor" path, though:

UIFieldEditor is a private class in UIKit, so we don't have its headers. Without the headers, @interface MyFieldEditor : UIFieldEditor is going to cause a compiler error, since it won't know how to inherit from UIFieldEditor.
We don't control the UIFieldEditor instance used by UIKit. Even if we could create our own MyFieldEditor, we still don't know how to swap out the existing shared object for our own.

Fortunately, we can handle both of these problems with the same solution: dynamic subclassing. We'll create our own subclass of UIFieldEditor at runtime and change the class of the existing field editor to be out new dynamic subclass. This sounds crazy—and it is. But it works¹, and it allows us to add our own -deleteBackward functionality without having to swap out existing objects and somehow inform UIKit of what we're doing.

Dynamically creating classes at runtime isn't something you're likely to do very often, but it's fairly well documented, and there have been some great posts about it in the community. I won't bother going into more detail here—it's enough to know that the dynamically-created class works just like any other, once you get it all set up. You just need to allocate a new class pair, register the new class, and add the methods we want to override to the new class. (One caveat of note: calls to objc_allocateClassPair() and objc_registerClass() fail under ARC, so if you're using ARC you'll have to do those in a file that's not using ARC.) You can see how this works in my sample implementation, linked at the end of this post.

Once we've created our MyFieldEditor class, though, we still have to actually change the class of the existing UIFieldEditor. This requires using the runtime function object_setClass(id object, Class newClass). The newClass parameter is easy enough, but what are we going to pass it for the object? We know there's a UIFieldEditor out there, but we still don't have a reference to it.

Let's go back to class-dump for a moment. Looking through the method list on UITextField, you'll see a -(id)_fieldEditor method. Sounds like exactly what we want. Unfortunately, we can't just toss that method declaration in a category and then call it directly; that's sure to fail App Store validation for using private API. So we need some way of calling that method without making it look like we're using that method.

We could probably do it with -(id)performSelector:, but we clearly can't just create the selector with @selector(_fieldEditor); that will fail App Store validation just as quickly as calling it directly. We could construct it dynamically from a string, but ARC introduces some caveats when calling -performSelector: with a dynamically-constructed selector because it can't guarantee to get the memory management right. It would be nice to have something that would work correctly without a lot of overhead.

Key-Value Coding to the rescue! Key-Value Coding is built around the idea that if you know the name of a property, Cocoa can figure out what the appropriate getters and setters should be. So, rather than trying to figure out the exact method we want to call, let's just ask Cocoa to get the fieldEditor for us:

id fieldEditor = [someTextField valueForKey:@"fieldEditor"];

It's as easy as that.

Part 4: Making the call

At this point, we have a reference to the field editor, and we've created a dynamic UIFieldEditor subclass that we can use to customize its behavior. We never actually added any methods, though; MyFieldEditor doesn't do anything differently from UIFieldEditor yet. We'll need to dynamically add a method to MyFieldEditor, but before we can do that, we need to write the method.

Our needs are actually quite simple; when -[MyFieldEditor deleteBackward] is called, we want to call a method letting someone know that a backward deletion happened. Ideally, that "someone" would be the text field itself. Then we want to call through to the superclass implementation.

Here's my implementation:

- (void)fieldEditor_deleteBackward {

    MyTextField *textField = objc_getAssociatedObject(self, BackwardDeleteTargetKey);
    [textField my_willDeleteBackward];

    // Call through to super
    Class superclass = class_getSuperclass([self class]);
    SEL deleteBackwardSEL = @selector(deleteBackward);
    IMP superIMP = [superclass instanceMethodForSelector:deleteBackwardSEL];
    superIMP(self, deleteBackwardSEL);
}

It's really quite simple. We get a reference to the text field using ObjC associated objects, and call -my_willDeleteBackward on it. Then we pass the -deleteBackward method up to the superclass, UIFieldEditor. We have to use the runtime methods to do the superclass call because of the dynamic subclassing game; otherwise, we'd get the wrong superclass.

I'm a little nervous about unilaterally changing the behavior of UIFieldEditor, because it seems likely that every text input area in your app uses the same instance of the field editor. So we do a little dance in MyTextField's implementations of -becomeFirstResponder and -resignFirstResponder. It looks like this:

- (BOOL)becomeFirstResponder {
    BOOL shouldBecome = [super becomeFirstResponder];
    if (shouldBecome == NO) {
        return NO;
    }

    Class myFieldEditorClass = objc_lookUpClass([SubclassName UTF8String]);
    if (myFieldEditorClass == nil) {
        myFieldEditorClass = registerMyFieldEditor();
    }

    id fieldEditor = [self valueForKey:@"fieldEditor"];

    if (fieldEditor && myFieldEditorClass) {
        object_setClass(fieldEditor, myFieldEditorClass);
        objc_setAssociatedObject(fieldEditor, BackwardDeleteTargetKey,
                                 self, OBJC_ASSOCIATION_ASSIGN);
    }

    return YES;
}


- (BOOL)resignFirstResponder {
    BOOL shouldResign =  [super resignFirstResponder];
    if (shouldResign == NO) {
        return NO;
    }

    id fieldEditor = [self valueForKey:@"fieldEditor"];

    if (fieldEditor) {
        objc_setAssociatedObject(fieldEditor, BackwardDeleteTargetKey,
                                 nil, OBJC_ASSOCIATION_ASSIGN);
        Class uiFieldEditorClass = objc_lookUpClass("UIFieldEditor");
        if (uiFieldEditorClass) {
            object_setClass(fieldEditor, uiFieldEditorClass);
        }
    }
    return YES;
}

With this implementation, the shared UIFieldEditor instance will only be of class MyFieldEditor while the text field is actively the first responder. As soon as the text field resigns, it goes back to being a regular old UIFieldEditor. No other text field in the app will be affected, and this text field will hear about all the backward deletion calls as soon as they come in.

This is about the point where everyone working on UIKit starts squirming vigorously. If you'd like people to not do this kind of stuff (which I'd heartily agree with), then let me direct your attention to Radars #10265826 and #10377565.

In the meantime, use with caution. I haven't tried it in the App Store, but I suspect it will pass validation as there are no symbols referencing any private API in this implementation.

The code is on GitHub.

This is actually the same mechanism Cocoa uses to implement Key-Value Observing; when you start observing a property of some object, Cocoa generates a new subclass of that object's class and implements a setter method that wraps your own with calls to -willSetValueForKey: and -didSetValueForKey:. When all observers on an object are gone, its class is set back to the original class. ↩

Adding a fixed image background to UIWebView

2011-10-14T10:17:00.000-07:00

A short post for iOS people.

UIWebView doesn't (as of iOS 5.0) honor background-attachment: fixed; in CSS, so if you need a fixed background image on a UIWebView, you're probably searching Google trying to find the answer.

Hopefully, this will help.

UIWebView *someWebView;

someWebView.opaque = NO;

someWebView.backgroundColor = [UIColor clearColor];

UIImageView *imageView;

imageView.image = [UIImage imageNamed:@"something"];

imageView.autoresizingMask = (UIViewAutoresizingFlexibleHeight | UIViewAutoresizingFlexibleWidth);

imageView.contentMode = UIViewContentModeScaleToFill;

imageView.frame = someWebView.bounds;

[someWebView insertSubview:imageView atIndex:0];

@synchronized vs dispatch_once

2011-09-29T07:43:00.000-07:00

In the comments on a recent Stack Overflow question, someone asked me if there was a significant performance difference between @synchronized and dispatch_once in implementing a singleton. So I wrote a simple test harness to access a singleton using the @synchronized method shown here:

@synchronized(self) {
    if (!synchronizedVar) {
        synchronizedVar = [[Test alloc] init];
    }
}
return synchronizedVar;

and the dispatch_once method shown here:

static dispatch_once_t onceToken;
dispatch_once(&onceToken, ^{
	dispatchVar = [[Test alloc] init];
});
return dispatchVar;

Each test accessed the singleton object 10 million times. I ran both single-threaded tests and multi-threaded tests. Here were the results:

Single threaded results
-----------------------
  @synchronized: 3.3829 seconds
  dispatch_once: 0.9891 seconds

Multi threaded results
----------------------
  @synchronized: 33.5171 seconds
  dispatch_once: 1.6648 seconds

So yeah, dispatch_once is a lot faster, especially under thread contention.You can find my test harness on github.

Tri-Pic is in the App Store!

2011-05-27T20:34:00.000-07:00

Tri-Pic is finally in the App Store! I've been working on this as a side project for a few months, and finally got around to finishing it up. It's a fun little app to mix faces and share them via email, Twitter, Facebook, and other services. And it's available now in the App Store, free.

FrankenMe/my sister/my nephew

Tri-Pic started out as a project to help my brother with a marketing assignment. In the class they had to come up with a game and do a bunch of market research on it. But it had to be a real game. They were allowed to use an iPhone app only if they knew someone who could actually make that app.

As it turns out, my brother knows a guy who can make apps.

The arrangement was pretty simple: I'd make the app, they'd use it with for class and get the grade, and then I could do whatever I wanted with it. Awesome. I got the basics done in time for them to finish the course, but it never felt quite ready to put in the App Store.

The biggest problem was the initial experience. It's fun to mix faces, of course, but when you first launch the app, it doesn't have any faces. I could have included a bunch of stock faces, but it's at least twice as fun to mix faces of people you know, so I really wanted to avoid stock faces. But the first experience with the app was pretty terrible: you spent at least 2 minutes finding a half-dozen good pictures to use and cropping the face in each one before you ever got to mix any faces. Two minutes of tedium isn't a great introduction to any app.

So I added face detection using OpenCV. Tri-Pic will scan your photo library and look for faces, automatically adding them to the database. And even better is that on devices that support multitasking, this detection can continue in the background while off browsing the web or tweeting about Tri-Pic. The initial experience went from super lame to magical.

Is Tri-Pic going to earn an Apple Design Award? Not likely. Nor is it going to change the world, or fix the economy, or anything else monumental. But it's fun, it's free, and you'll at least get a smile or two out of it. And really, who can't use a smile?

Download Tri-Pic.

P.S. If you download it before the next update is approved, you may catch a reference to a previous working name. Let's just call it an easter egg, and not a really lame error, okay?

Subclassing NSInputStream

2011-04-14T21:14:00.000-07:00

Cocoa's NSInputStream is great, but sometimes it doesn't have all the functionality you need. For example, you might want to dynamically encrypt the file as you were streaming it off the disk, or you might want to put up a progress bar indicating how far the input stream had progressed through a large file. NSInputStream doesn't support either of these options natively, but this sounds like a great place for an NSInputStream subclass, right?

Wrong.

Or rather, right, with the caveat that subclasses of NSInputStream don't work correctly when used with Cocoa's URL loading mechanism. ( folks: See rdar://problem/3222783.)

The Problem

When you make an NSInputStream subclass and try to pass it to -[NSURLRequest setHTTPBodyStream:], your app will quickly crash with an 'unrecognized selector' for the following method:

- (void) _scheduleInCFRunLoop: (CFRunLoopRef) inRunLoop forMode: (CFStringRef) inMode

If you implement that, you'll then get another unrecognized selector:

- (BOOL) _setCFClientFlags: (CFOptionFlags)inFlags
                  callback: (CFReadStreamClientCallBack) inCallback
                   context: (CFStreamClientContext *) inContext

If you give that one an empty implementation too (return YES;) and the file you're uploading is small, you may manage to make it to a third unimplemented selector:

- (void) _unscheduleFromCFRunLoop:(CFRunLoopRef)inRunLoop forMode:(CFStringRef)inMode

Unfortunately, while you can avoid the unrecognized selector crashes by implementing these methods, you're very unlikely to get through your whole stream. Further, Apple engineers have stated that such naive implementations are "definitely not safe" and will likely lead to failing in "strange and unexpected ways."

The backstory

The real question here is what these methods are for in the first place. It turns out that these three methods are simply the toll-free bridging versions of CFReadStreamScheduleWithRunLoop, CFReadStreamSetClient, and CFReadStreamUnscheduleFromRunLoop, respectively. Calling CFReadStreamScheduleWithRunLoop from _scheduleInCFRunLoop:..., for example, is a quick way to infinite recursion.

The NSStream documentation indicates that subclasses must override -(void)scheduleInRunLoop:(NSRunLoop *)aRunLoop forMode:(NSString *)mode and -(void)removeFromRunLoop:(NSRunLoop *)aRunLoop forMode:(NSString *)mode. Why? Because the stream's delegate usually needs to be notified when there are bytes available to be read, and that getting that information often requires being scheduled on a run loop. Our three mystery methods serve the same purpose.

NSInputStream is toll-free bridged with CFReadStream. Mostly. From the CFReadStream Reference:

CFReadStream is “toll-free bridged” with its Cocoa Foundation counterpart, NSInputStream. This means that the Core Foundation type is interchangeable in function or method calls with the bridged Foundation object. Therefore, in a method where you see an NSInputStream * parameter, you can pass in a CFReadStreamRef, and in a function where you see a CFReadStreamRef parameter, you can pass in an NSInputStream instance. Note, however, that you may have either a delegate or callbacks but not both.

These methods are required to support the CFReadStream client callbacks, which are distinct from the delegate callbacks.

The solution

-[NSInputStream _scheduleInCFRunLoop:forMode:] is the equivalent of CFReadStreamScheduleWithRunLoop for your stream. Do whatever you need to do so that you can give proper kCFStreamEventHasBytesAvailable notifications (and any other notifications requested) at the proper time. That may involve scheduling a timer on the run loop, or if your subclass is just wrapping a vanilla NSInputStream, simply scheduling that stream on the run loop. Implement this method as if you were implementing CFReadStreamScheduleWithRunLoop for your stream

-[NSInputStream _setCFClientFlags:callback:context:] is the equivalent of CFReadStreamSetClient, you need to do a few things. If the context and callback arguments are not NULL, the caller is trying to set up a callback client.

Inspect the flags, and record which notifications are requested. The possible values are listed in the CFStream Event Type Constants documentation.
Copy the pointer to the callback function. You'll need to use it later.
Copy the context. The documentation for CFReadStreamSetClient indicates that the context struct passed by the caller should be copied, and that the caller is not responsible for preserving it. memcpy(&myLocalContextCopy, thePassedContext, sizeof( CFStreamClientContext)) works just fine.
Retain the context->info. The context struct includes a void *info member and a CFAllocatorRetainCallBack retain member. Call the retain function on the info pointer (if the retain function is not nil).

If the context and callback parameters are NULL, then the caller is removing the callback client, and you need to do the following:

Call the release function (from the context you previously copied) on the info pointer in that context.
Remove your copy of the context and callback; they are no longer needed.

Finally, return YES to indicate that the asynchronous scheduling was successful.

-[NSInputStream _unscheduleFromCFRunLoop:forMode] is the equivalent of CFReadStreamUnscheduleFromRunLoop. You should remove anything you scheduled in the _scheduleInCFRunLoop:forMode: method.

Once you've done these, make sure you've implemented the other methods required for subclasses as documented in the NSInputStream and NSStream reference. Now, when you pass off your NSInputStream subclass to NSURLRequest, your stream will be scheduled on the run loop and the client callbacks will be set up. Once you're scheduled on the run loop, you should be able to notify your client when you have bytes available to read, when you've reached the end of the file, and when an error has occurred. Make sure you're passing those along correctly, and everything will be good to go.

Sample

I've put together a sample implementation of an NSInputStream subclass that demonstrates what I've presented. HSCountingInputStream is a simple class that wraps an NSInputStream, counting the number of instances of a given character have passed through it. Nearly every call is simply passed through to the underlying NSInputStream; the only real code of interest is in the -read:maxLength: and in the undocumented methods discussed above.

I'll keep an eye on the comments, so if you have any questions, please let me know. I'll probably write up another blog here shortly about how I figured all of this out, for those who are interested.

Creating a Finder alias programmatically on Snow Leopard

2009-08-28T12:22:00.000-07:00

My co-worker Dan posted a blog yesterday entitled "How to Create an Alias Programmatically". His example is 21 lines long, and is compatible with Leopard and earlier. It only works if the original item is a folder (though creating an alias to a file is not much different). The code messes with resource forks, and the C interface is generally difficult to read for someone who spends most of their time in Objective-C. The code is also not guaranteed to be 100% accurate, since Apple explicitly did not support programmatic alias creation in Leopard.

This is a great example of how Apple has improved the developer experience for OS X in Snow Leopard. Snow Leopard contains some new APIs for "bookmark" creation, which appears to be the new behind-the-scenes name for aliases. The following four lines of code create a functioning alias on Snow Leopard:

NSURL *src = [NSURL URLWithString:@"file:///Users/bjh/Desktop/temp.m"];
NSURL *dest = [NSURL URLWithString:@"file:///Users/bjh/Desktop/myalias"];

NSData *bookmarkData = [src bookmarkDataWithOptions:NSURLBookmarkCreationSuitableForBookmarkFile
includingResourceValuesForKeys:nil
relativeToURL:nil
error:NULL];
[NSURL writeBookmarkData:bookmarkData
toURL:dest
options:0
error:NULL];

Isn't that about a billion times easier?

I'm not sure what the relativeToURL: parameter is for yet; comments are welcome.

100 Hour Board iPhone app v1.2 released

2009-07-09T18:07:00.000-07:00

As of this previous Sunday, 100 Hour Board for iPhone was updated to version 1.2. This update includes support for iPhone OS 3.0, improves the rendering of quotes in Board posts, and teaches the app to remember where you were when you last closed it. There are also a couple minor user interface tweaks; notably, when posts download they should appear in the list with a smooth animation.

Go check it out! http://tinyurl.com/100hourapp (iTunes Music Store link)

Singleton Pattern in Cocoa

2009-06-16T21:52:00.000-07:00

Peter Hosey recently tweeted:

From the “how NOT to implement a Cocoa singleton” dept: http://developer.apple.com/documentation/Cocoa/Conceptual/CocoaFundamentals/CocoaObjects/CocoaObjects.html#//apple_ref/doc/uid/TP40002974-CH4-SW32

followed by:

If something over-releases an object, the bug is not in that object, and overriding methods in it to break retain/release is not fixing it.

The code sample in question is in the Apple documentation, and prescribes overriding the following methods for a singleton object: allocWithZone:, copyWithZone:, retain, release, autorelease, and retainCount. In addition, it also recommends implementing a sharedFloozit class method, so that users of your class are aware they're using a singleton. Go read that section, or you'll be lost for the rest of this post.

Really, I mean it. Go read that documentation. I'll be referring to it a lot.

That's a lot of methods to override just to implement a singleton. More to the point, a lot of it seems unnecessary. After all, as long as everyone else is doing their memory management correctly, retain counts shouldn't matter, right?

Wrong.

First, though, we need to get a definition straight. A singleton is a class of which there should only be one instance in any given process. There are actually very few singleton classes in the Cocoa framework including NSDocumentController and NSFontManager. [1] You cannot create more than one of these objects; if you try to call [[NSDocumentController alloc] init], you'll get back the exact same object as you do when you call [NSDocument sharedDocumentController], no matter how many times you call alloc and init. NSApplication is arguably a singleton as well; you can alloc another one, but you'll get an assertion failure when you call init.

Singletons are generally useful when initializing an object takes an inordinate amount of time. NSFontManager, for example, has to search several locations on the filesystem in order to do its job. You really don't want to be constantly initializing an NSFontManager. Further, it makes very little sense to have more than one instance of NSApplication within your application. Having one shared object for the whole system can simplify and optimize certain things. [2]

So that's a singleton. Only one instance allowed in the entire process.

There are other classes that have a +[SomethingClass sharedSomething] method or a +[SomethingClass defaultSomething] method. These methods provide access to an instance of the object intended to be shared by all users of the class, but do not prohibit the creation of another instance. Indeed, the Leopard Developer Release Notes specifically note that creating multiple instances of NSFileManager is possible and thread-safe, despite the existence of a globally-available object through +[NSFileManager defaultManager]. These are not singletons. If you're writing a class which provides a shared instance but doesn't not prohibit creation of other instances, then you should absolutely not override retain, release, autorelease, and retainCount, and should probably not override allocWithZone: either.

Most of the time, you don't need a singleton. Just the mention of a singleton is enough to get some people up in arms. But if you really truly need a singleton, then there's good reason for overriding the methods listed above.

Consider the following example:


MyFloozit *floozit1 = [[MyFloozit alloc] init];
[floozit1 doSomething];
[floozit1 release];

MyFloozit *floozit2 = [[MyFloozit alloc] init];  // MyFloozit is a singleton, so this should be the same object as floozit1
[floozit2 doSomething];  // CRASH HERE
[floozit2 release];

When floozit1 is set, a new MyFloozit is allocated, and a static MyFloozit pointer is set. When floozit1 is released, that static pointer is still pointing to the old instance. As a result, when we try to set floozit2 (or when anyone else tries to call [MyFloozit sharedFloozit]), we get back a pointer to that same instance. The one that has been dealloc-ed. Right there, despite following all the standard rules of memory management, you've crashed. The example might seem contrived, but if floozit1 and floozit2 are in separate methods (or separate threads calling the same method), this could be a very common scenario.

The point is, if you override allocWithZone: to force a class to be a singleton, then you must override release (and autorelease), or else anyone who believes they have ownership (after to calling init) will crash your program. Once you're disabling retain counting by overriding release, you might as well override retain and retainCount as well, to be consistent.

In the Apple Documentation linked above, there is a short paragraph right after the code showing the recommended way to override the various methods. It says:

Situations could arise where you want a singleton instance (created and controlled by the class factory method) but also have the ability to create other instances as needed through allocation and initialization. In these cases, you would not override allocWithZone: and the other methods following it as shown in Listing 2-15.

In this situation, I agree with Peter (and Apple) completely; don't override the memory management methods. I disagree with calling it a singleton, but whatever you want to call it, it's clear that you need those memory management methods.

If you think you need a singleton, think again. If you still think you need a singleton, bounce it off someone else to disabuse you of the notion. If you still need a singleton, then follow Apple's advice and override the memory management methods. Otherwise, you'll crash.

Of course, if you're using garbage collection, all retain count operations are no-ops, so none of this matters anyway. Feel free to go on your merry way, pitying the poor souls still living in a retain-counted world.

[1] The documentation referenced by Peter on "Creating a Singleton Instance" lists NSFileManager and NSWorkspace as examples of singletons, but this is incorrect. It is possible to create more than one instance of both these classes; Cocoa just happens to provide easy access to a shared instance which they suggest you use.

[2] It can also complicate a lot of things by introducing shared state. I'm not arguing for the use of the singleton pattern; I agree with Peter that most of the time, if you're using a singleton then you're "Doin It Rong". I'm simply arguing for Apple's implementation of the singleton pattern in the case where you really do need a singleton.

100 Hour Board released... a week ago

2009-03-31T11:05:00.000-07:00

On March 19, my 100 Hour Board app was officially available in the App Store. There were nearly 100 downloads in the first two days, and that was before I'd even started doing any advertising.

Anyway, if you haven't downloaded it yet, it's available in the App Store here. (Link opens in iTunes.)

I've got a small update waiting for approval right now. It adds a popup alert when a search returns no results, so that users don't think it's just a slow search. Next on the feature list is read/unread tracking for daily posts.

100 Hour Board iPhone app coming soon

2009-03-09T09:43:00.000-07:00

I'm a big fan of BYU's 100 Hour Board, an online Q&A forum that provides answers to nearly any question imaginable within 100 hours. I've been working with their webmasters over the last few weeks to get a web API to their content, and today I'm uploading an app that provides an iPhone-optimized interface to the 100 Hour Board. It's a fantastic interface on an awesome website, and I'm excited for it to go live.

I'll be sure to post as it's available.

Surakarta is now available

2009-02-11T17:00:00.000-08:00

Surakarta for the iPhone/iPod Touch is now available for download. (Link opens in iTunes.) I haven't yet been able to find it directly by searching, but hopefully the App Store index will update shortly.

I'm currently working on version 1.1, where I'll add single-player support. In the meantime, download Surakarta and write a review!

UPDATE (6:04 pm): Sometime in the last 10 minutes, it showed up through search. Hooray!

Surakarta 1.0 Released

2009-02-01T10:02:00.001-08:00

Today I'm releasing Surakarta v1.0 for the iPhone (and iPod Touch). It's based on a traditional Javanese game and was included in "The Book of Classic Board Games" published by Klutz Press, under the name "Roundabouts." It currently only has two-player mode, but I plan to release an upgrade to support single-player play (against a computer opponent) soon.

I hope you enjoy the game! For feedback, please e-mail me.