ScreenCaptureView

This bit of code allows you to easily capture the contents of any arbitrary UIView:

//  ScreenCaptureView.h
#import <UIKit/UIKit.h>

@interface ScreenCaptureView : UIView {
}

@property(retain) UIImage* currentScreen;
@property(assign) float frameRate;

@end


//  ScreenCaptureView.m
#import "ScreenCaptureView.h"
#import <QuartzCore/QuartzCore.h>

@implementation ScreenCaptureView

@synthesize currentScreen, frameRate;

- (id)initWithFrame:(CGRect)frame {
    self = [super initWithFrame:frame];
    if (self) {
        // Initialization code
        self.contentMode = UIViewContentModeRedraw;
        self.frameRate = 20.0f;//20 frames per seconds
    }
    return self;
}

- (void) drawRect:(CGRect)rect {
    CGContextRef context =  UIGraphicsGetCurrentContext();
    [self.layer renderInContext:context];
    CGImageRef cgImage = CGBitmapContextCreateImage(context);
    UIImage* background = [UIImage imageWithCGImage: cgImage];
    CGImageRelease(cgImage);
    self.currentScreen = background;
    
    [self performSelector:@selector(setNeedsDisplay) withObject:nil afterDelay:(1.0 / self.frameRate)];   //redraw at the specified framerate
}

- (void)dealloc {
    [super dealloc];
}
@end

The ‘ScreenCaptureView‘ class automatically captures its current contents (including any nested subviews) to a UIImage which it exposes through the ‘currentScreen‘ property. You can use this functionality to do things like generate screenshots of your application for use in help/tutorial (or promotional) content, and you can even pass the data as frames to an `AVCaptureSession` to create a live video of your app in action.

Update: An enhanced version of this class that includes the ability to record video is now available.

MultiplexingDelegate

For those rare cases when you want multiple delegate objects to be notified of a change/event in some object:

//  MultiplexingDelegate.h
#import <Foundation/Foundation.h>

@interface MultiplexingDelegate : NSObject {
    NSMutableArray* delegates;
}

- (void) addDelegate: (id) theDelegate;
- (void) removeDelegate: (id) theDelegate;
- (void) sendSelectorToDelegates: (SEL)selector withObject: (id)param1 andSecondObject: (id)param2
@end

//  MultiplexingDelegate.m
@implementation MultiplexingDelegate
- (id) init {
    if ((self = [super init])) {
        delegates = [[NSMutableArray alloc] initWithCapacity: 16];
    }
}

- (void) dealloc {
    [delegates release];
    [super dealloc]
}

- (void) addDelegate: (id) theDelegate {
    @synchronized(delegates) {
        if (theDelegate && ! [delegates containsObject: theDelegate]) {
            [delegates addObject: theDelegate];
        }
    }
}

- (void) removeDelegate: (id) theDelegate {
    @synchronized(delegates) {
        if (theDelegate && [delegates containsObject: theDelegate]) {
            [delegates removeObject: theDelegate];
        }
    }
}

- (void) sendSelectorToDelegates: (SEL)selector withObject: (id)param1 andSecondObject: (id)param2 {
    @synchronized(delegates) {
        for (id theDelegate in delegates) {
            if (param2) {
                [theDelegate performSelector:selector withObject:param1 withObject:param2];
            }
            else if (param1) {
                [theDelegate performSelector:selector withObject:param1];
            }
            else {
                [theDelegate performSelector:selector];
            }
        }
    }
}
@end

The ‘MultiplexingDelegate` class provides a generic starting point for creating delegates that conform to various protocols and support the multiplexing of events to any number of attached listeners. To use it you just need to create a new subclass of ‘MultiplexingDelegate‘ that implements whatever protocol you are interested in. For instance, here is a partial example of a multiplexing UISearchBarDelegate implementation:

//  MultiplexingSearchBarDelegate.h
#import <UIKit/UIKit.h>
#import "MultiplexingDelegate.h"

@interface MultiplexingSearchBarDelegate : MultiplexingDelegate<UISearchBarDelegate> {
}
@end

//  MultiplexingSearchBarDelegate.m
@implementation MultiplexingSearchBarDelegate
//add UISearchBarDelegate methods here, following a pattern like this:
- (void)searchBar:(UISearchBar *)searchBar textDidChange:(NSString *)searchText {
    [self sendSelectorToDelegates: @selector(searchBar:textDidChange:) withObject: searchBar andSecondObject: searchText];
}

//or alternately/equivalently, a pattern like this:
- (BOOL)searchBar:(UISearchBar *)searchBar shouldChangeTextInRange:(NSRange)range replacementText:(NSString *)text {
    @synchronized(delegates) {
        for (id<UISearchBarDelegate> theDelegate in delegates) {
            [theDelegate searchBar:searchBar shouldChangeTextInRange: range replacementText: text];
        }
    }
}
@end

To use the ‘MultiplexingSearchBarDelegate‘ class you would create a single instance and add it as the delegate of your UISearchBar. Then you just register every other object that you want to receive UISearchBar events with the ‘MultiplexingSearchBarDelegate‘ (by using the ‘addDelegate:‘ method), and they will all receive event notifications from the UISearchBar. Simple, but powerful.

NSString+JavaAPI

There’s no getting around it, the standard NSString API just kind of sucks. Wouldn’t it be great if NSString supported an API that was more like what Java provides through its String class? Well now it can:

//  NSString+JavaAPI.h
#import <Foundation/Foundation.h>

@interface NSString (NSString_JavaAPI)
- (int) compareTo: (NSString*) comp;
- (int) compareToIgnoreCase: (NSString*) comp;
- (bool) contains: (NSString*) substring;
- (bool) endsWith: (NSString*) substring;
- (bool) startsWith: (NSString*) substring;
- (int) indexOf: (NSString*) substring;
- (int) indexOf:(NSString *)substring startingFrom: (int) index;
- (int) lastIndexOf: (NSString*) substring;
- (int) lastIndexOf:(NSString *)substring startingFrom: (int) index;
- (NSString*) substringFromIndex:(int)from toIndex: (int) to;
- (NSString*) trim;
- (NSArray*) split: (NSString*) token;
- (NSString*) replace: (NSString*) target withString: (NSString*) replacement;
- (NSArray*) split: (NSString*) token limit: (int) maxResults;
@end

//  NSString+JavaAPI.m
#import "NSString+JavaAPI.h"

@implementation NSString (NSString_JavaAPI)
- (int) compareTo: (NSString*) comp {
    NSComparisonResult result = [self compare:comp];
    if (result == NSOrderedSame) {
        return 0;
    }
    return result == NSOrderedAscending ? -1 : 1;
}

- (int) compareToIgnoreCase: (NSString*) comp {
    return [[self lowercaseString] compareTo:[comp lowercaseString]];
}

- (bool) contains: (NSString*) substring {
    NSRange range = [self rangeOfString:substring];
    return range.location != NSNotFound;
}

- (bool) endsWith: (NSString*) substring {
    NSRange range = [self rangeOfString:substring];
    return range.location == [self length] - [substring length];
}

- (bool) startsWith: (NSString*) substring {
    NSRange range = [self rangeOfString:substring];
    return range.location == 0;
}

- (int) indexOf: (NSString*) substring {
    NSRange range = [self rangeOfString:substring];
    return range.location == NSNotFound ? -1 : range.location;
}

- (int) indexOf:(NSString *)substring startingFrom: (int) index {
    NSString* test = [self substringFromIndex:index];
    return [test indexOf:substring];
}

- (int) lastIndexOf: (NSString*) substring {
    if (! [self contains:substring]) {
        return -1;
    }
    int matchIndex = 0;
    NSString* test = self;
    while ([test contains:substring]) {
        if (matchIndex > 0) {
            matchIndex += [substring length];
        }
        matchIndex += [test indexOf:substring];
        test = [test substringFromIndex: [test indexOf:substring] + [substring length]];
    }
    
    return matchIndex;
}

- (int) lastIndexOf:(NSString *)substring startingFrom: (int) index {
    NSString* test = [self substringFromIndex:index];
    return [test lastIndexOf:substring];
}

- (NSString*) substringFromIndex:(int)from toIndex: (int) to {
    NSRange range;
    range.location = from;
    range.length = to - from;
    return [self substringWithRange: range];
}

- (NSString*) trim {
    return [self stringByTrimmingCharactersInSet:[NSCharacterSet whitespaceAndNewlineCharacterSet]];
}

- (NSArray*) split: (NSString*) token {
    return [self split:token limit:0];
}

- (NSArray*) split: (NSString*) token limit: (int) maxResults {
    NSMutableArray* result = [NSMutableArray arrayWithCapacity: 8];
    NSString* buffer = self;
    while ([buffer contains:token]) {
        if (maxResults > 0 && [result count] == maxResults - 1) {
            break;
        }
        int matchIndex = [buffer indexOf:token];
        NSString* nextPart = [buffer substringFromIndex:0 toIndex:matchIndex];
        buffer = [buffer substringFromIndex:matchIndex + [token length]];
        if (nextPart) {
            [result addObject:nextPart];
        }
    }
    if ([buffer length] > 0) {
        [result addObject:buffer];
    }
    
    return result;
}

- (NSString*) replace: (NSString*) target withString: (NSString*) replacement {
    return [self stringByReplacingOccurrencesOfString:target withString:replacement];
}
@end

Note that this isn’t the complete Java String API (and also that `split()` does not support regular-expressions as it does in Java). It is just a subset consisting of the most useful Java API functions that do not have convenient analogs in the standard NSString API. Still, it makes a lot of common string manipulations a lot more straightforward than they otherwise would be.

Conceptually, one can reason out that Objective-C accomplishes many of its neat tricks by using the performv: selector and a few clever lookup tables placed in strategic locations. For instance, if the member functions for an object are referenced in a function table that is keyed by function name (or more appropriately, selector), and the performv: selector always consults this table when performing a method invocation, then adding new functions to an object can be accomplished, even at runtime, by simply adding some new table entries. It’s a pretty elegant design, really, although that’s a subject for another day, perhaps.

The subject for today is a somewhat simple, somewhat less elegant method that is an integral part of the Cocoa API:

- (void)performSelector:(SEL)sel withObject:(id)arg 
		afterDelay:(NSTimeInterval)secs

What this method does is schedule a given method invocation on the current run loop, to be executed after some amount of delay, specified in seconds. As a brief aside, “run-loops” are an outdated, non-intuitive, and over-complicated concept, and they should go away. Viewed abstractly, a run loop is simply an execution context. It executes a stream of commands serially relative to other commands in the run loop, and in parallel relative to commands being executed in other run loops. In essence, a run loop is simply a thread. It provides an execution context that is asynchronous from other execution contexts in the runtime environment, just like a thread does. And there is little reason to complicate the matter by inventing a new concept to use to model something that every modern Computer Science student is exposed to in their first year of college.

But anyways, the performSelector: method (and its numerous variants) allows a developer to schedule a particular method invocation to occur at some later point in time on the current thread (I shall not be using the term “run loop” any longer). Other instructions on the thread continue to execute as normal between the time performSelector: is called and the time when the target method is invoked (i.e. using this method does not block the current thread). It’s almost, but not quite, like scheduling the execution of a function closure, and can be used to create a kind of poor-man’s multi-threading.

As noted, the method invocation is actually scheduled to execute on the current thread, so there is no true concurrency occurring here; merely the illusion of concurrency. But in many cases, the illusion of concurrency is all that’s really required. To draw a parallel to other languages, the performSelector: method is comparable to the setTimeout() function that is present in both JavaScript and ActionScript. Both of these languages use a single-threaded runtime environment, but can provide the illusion of concurrency through use of the setTimeout() call. Conceptually, the execution engine that these languages use is simply processing a queue of function closures. While there is a closure that is scheduled to execute, the engine dequeues and executes it, otherwise it sleeps until there is a new closure scheduled in the queue. And so it is in a Cocoa thread, except that instead of a queue of function closures, you have a queue of selectors (or “messages”, or “method invocations”, as you prefer).

There are a number of uses for this not-quite-concurrency, such as monitoring the status of an object or operation and then posting a notification to some delegate when that status changes. For instance, here is some simple code to detect the end of a UIView startAnimating sequence:

@implementation AnimatingView 
- (void) checkStatus {
	if([self isAnimating]) {
		//animation is still running, check later
		[self performSelector:@selector(checkStatus)
			withObject:nil afterDelay: 0.1];
		return;  //be sure to do this here
	}

	//animation is done, notify and release our delegate
	[animDelegate notifyAnimationComplete];
	[animDelegate release];
}

- (void) runAnimationAndNotify: (id) objToNotify {
	//[set up your animation stuff here]
	
	//retain the object that we want to notify
	animDelegate = [objToNotify retain];
	[self startAnimating];  //start the animation
		
	//schedule a status notification check
	[self performSelector:@selector(checkStatus)
		withObject:nil afterDelay: 0.1];
}
@end

In many other languages, the above code can only be implemented by spawning a new thread to monitor the status of the animation (or by blocking/sleeping the current thread while the animation is running). You can do it that way in Objective-C as well, but the above method has a couple of advantages over using a dedicated thread:

• No thread creation overhead. Since the current thread is used, no additional resources need to be allocated on spawning a thread just to handle the notification dispatch.
• No need to worry about concurrency/synchronization issues. Because the notification is sent from the same thread that started the animation, there is no need to worry about the notification arriving when the calling object is in the middle of doing something else (unless your program has other threads that are making use of that same object).

Of course, there are some caveats associated with this approach, as well:

• If the current thread blocks or sleeps, the notification will be delayed. Obviously if you are doing things on your thread that would cause it to block or sleep for a long duration of time, you should not use this approach.
• If too much other work is being done on the current thread, then the timing of the notification will be unreliable. That’s just the nature of the beast, just like how ActionScript and JavaScript timers lose their accuracy as CPU load approaches 100%. If your workload is heavy enough to saturate a CPU core, you are better off splitting it up into multiple full-fledged threads.

Overall, however, this is a useful technique for those situations where you want concurrent behavior without having to pay the resource and synchronization cost of true concurrency. It’s not appropriate in every situation, but if you have a simple task that you’re thinking about offloading onto a dedicated thread, this approach may be a quicker and simpler alternative.

Finally, a coding post!