I occasionally come across the need to grab the contents of a view as an image. This is often the result of needing to perform some non-stock, animated transition between views, but there are a variety of reasons why this might be useful. Thanks to the Core Animation framework’s CALayer class, this is easy to do.

All UIView instances have an underlying instance of a CALayer. The layer is responsible for rendering the view’s contents and performing any view-related animations. CALayer defines a method called renderInContext: which allows you to render the layer, and its sublayers, into a given graphics context:

UIGraphicsContext context = // some graphics context
[viewToCapture.layer renderInContext:context];

Before you can access any layer-specific APIs, you’ll need to make sure you’re linking against the QuartzCore framework. Xcode’s default templates don’t link against this framework so you’ll need to select Target Name > Build Phases > Link Binary With Libraries and select QuartzCore.framework.

Additionally, you’ll need to add the following import to your code wherever you are calling the layer’s properties or methods:

#import <QuartzCore/QuartzCore.h>

With the necessary project configuration out of the way, the next question is where do we get a graphics context into which we can render the view’s content? This can be created using UIKit’s UIGraphicsBeginImageContextWithOptions function which will create a new bitmap-based graphics context for us.

UIGraphicsBeginImageContextWithOptions(CGSize size, BOOL opaque, CGFloat scale);

This function takes a CGSize (you view’s size), a BOOL indicating if your view is opaque, and a CGFloat specifying the scaling factor. If you’re rendering a fully opaque, rectangular view you can pass YES for the opaque argument so the alpha channel can be discarded from the context.

Now that we’ve created a graphics context we can use the UIGraphicsGetCurrentContext() and UIGraphicsGetImageFromCurrentImageContext() functions to get reference to this new context and retrieve the rendered image data from it. Finally, we’ll want to call the UIGraphicsEndImageContext() function to clean up this context and remove it from the stack. Putting all this together we end up with the following:

// Render the views layer contents into the current Graphics context
CGSize viewSize = viewToCapture.bounds.size;
UIGraphicsBeginImageContextWithOptions(viewSize, NO, 1.0);
[viewToCapture.layer renderInContext:UIGraphicsGetCurrentContext()];
// Read the UIImage object
UIImage *image = UIGraphicsGetImageFromCurrentImageContext();
UIGraphicsEndImageContext();

To see this code in action I’ve put together a simple demo app. You can tap on Archer, Lana, or the background to capture the contents of the view and write the image to your Photo Library.

Note: Before running the demo be sure to open the “Photos” app on the Simulator so it can initialize its database or the images won’t be written. Enjoy!

Download Demo

My Core Animation Demos projects was previously available on Github under my personal account, but I have since moved it to my business account. The new location of of the CA demos is:

https://github.com/tapharmonic/Core-Animation-Demos

I haven’t made any major changes to code at this point, however, I did start an ARC branch to house my ongoing ARC changes.

The Factory pattern is a frequently used creational pattern to help abstract the creation of an object from its clients. Although there are a few specializations of this pattern I’ll focus on the most commonly used approach and then look at how we can leverage the Objective-C Runtime to make this solution more robust.

Let’s begin by creating a simple command-line app that creates Animal objects and gets them to speak on command. The various animal objects will all inherit from the abstract Animal class.

@interface Animal : NSObject {
}

- (void)speak;
- (NSString *)key;

@end

@implementation Animal

- (void)speak {
    NSAssert(NO, @"The 'speak' method must be implemented by subclass.");
}

- (NSString *)key {
    // Animal instances will be 'keyed' by their lower case class name
    // Overly simplistic, but will suffice for now
    return [NSStringFromClass([self class]) lowercaseString];
}

@end

With the abstract base class complete let’s create a couple concrete Animal implementations:

@implementation Cat
- (void)speak {
    NSLog(@"Meow, Meow...");
}
@end

@implementation Dog
- (void)speak {
    NSLog(@"Bark, Bark...");
}
@end

Our Cat & Dog objects are ready to go so let’s integrate them into our app and get them to speak.

int main (int argc, const char * argv[]) {

    NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init];

    Animal *cat = [[Cat alloc] init];
    [cat speak];
    [cat release];

    Animal *dog = [[Dog alloc] init];
    [dog speak];
    [dog release];

    [pool drain];
    return 0;
}

Running this app will produce the following console output:

Meow, Meow...
Bark, Bark...

This works as we’d expect, but the main problem with using the Cat and Dog classes this way is coupling. Even though we’ve defined our variables as abstract Animal types we’re still coupled to the specific subtypes. This means we can’t modify our Animal types or evolve their creation without impacting our client code. This may seem like a trivial matter in this example, but these design decisions can have major impacts on real-world applications. Let’s avoid some of the potential ripple effects by introducing a factory.

Creating Animals

We’ll begin by moving the object creation responsibilities from our client to a new object called AnimalFactory. This factory, as you may have guessed, will be responsible for creating and vending instances of Animal. A simple, but common implementation of this could be defined as follows:

@implementation AnimalFactory

+ (AnimalFactory *)factory {
    return [[[[self class] alloc] init] autorelease];
}

- (Animal *)animalForKey:(NSString *)animalKey {
    Animal *animal = nil;
    if ([animalKey isEqualToString:@"dog"]) {
        animal = [[Dog alloc] init];
    } else if ([animalKey isEqualToString:@"cat"]) {
        animal = [[Cat alloc] init];
    } else {
        NSAssert(NO, @"No Animal found for key:'%@'", animalKey);
    }
    return [animal autorelease];
}

@end

The AnimalFactory will determine which instance to create based on the argument passed to the animalForKey: method. It creates the appropriate instance and returns an autoreleased version of it to the client. To use this new factory in our client we can make the following changes:

AnimalFactory *factory = [AnimalFactory factory];

[[factory animalForKey:@"cat"] speak];
[[factory animalForKey:@"dog"] speak];

If you were to run this example again you would see the same output as before, but the introduction of this factory has helped us resolve two specific limitations in our previous implementation:

1. The client is no longer coupled to a particular instance of Animal. As our requirements change the factory can return alternate instances (FatCat, HotDog, etc.) without impacting our client code.
2. The client is no longer in the business of object creation which means how an animal is instantiated is no longer its concern. Additionally, by returning an autoreleased instance we don’t unnecessarily force memory management responsibilities onto the client.

One outstanding problem we have is with the factory itself. Although the client is better decoupled from the specific types and their creation, the factory itself is not. Every time we add a new animal to the app we additionally have to make modifications to the factory.

[Informercial Guy Voice]  There’s got to be a better way!

Enter the Objective-C Runtime

Objective-C is a dynamic language where many decisions are deferred until runtime. This deferment allows for some of the more interesting capabilities of the language and is made possible through the Objective-C Runtime. Although you can successfully use Objective-C without having much awareness of the runtime, understanding how to interact with it can open up some interesting new possibilities.

It would be nice if our AnimalFactory could automatically find and dispense all instances of Animal without us having to continuously modify the factory. Thanks to the runtime, it can.

Automagic Factories

Let’s begin by creating a utility class called RuntimeUtils containing a method to allow us to dynamically find all instances of a particular type. This method will be implemented as follows:

+ (NSArray *)classStringsForClassesOfType:(Class)filterType {

    int numClasses = 0, newNumClasses = objc_getClassList(NULL, 0);
    Class *classList = NULL;

    while (numClasses < newNumClasses) {
        numClasses = newNumClasses;
        classList = realloc(classList, sizeof(Class) * numClasses);
        newNumClasses = objc_getClassList(classList, numClasses);
    }

    NSMutableArray *classesArray = [NSMutableArray array];

    for (int i = 0; i < numClasses; i++) {
        Class superClass = classList[i];
        do {
            // recursively walk the inheritance hierarchy
            superClass = class_getSuperclass(superClass);
            if (superClass == filterType) {
                [classesArray addObject:NSStringFromClass(classList[i])];
                break;
            }
        } while (superClass);
    }

    free(classList);

    return classesArray;
}

This method makes use of two functions defined in <objc/runtime.h>:

1. objc_getClassList - This function returns a list of all classes registered with the app. We'll loop through this list and then filter its results.
2. class_getSuperclass - Returns the superclass of a class. We recursively walk the inheritance hierarchy of each class to determine if it's a descendant of Animal. If so, we add its class string to our array.

With our RuntimeUtils class now ready, let's go back and revisit the implementation of our factory object.

Implementing the Magic

We'll change the implementation of our factory class to leverage this new RuntimeUtils class. We'll start by implementing the init method.

- (id)init {
  if ((self = [super init])) {
    NSArray *animalClassStrings = [RuntimeUtils classStringsForClassesOfType:[Animal class]];
    animals = [[NSMutableDictionary alloc] initWithCapacity:[animalClassStrings count]];
      for (id classString in animalClassStrings) {
        Class animClass = NSClassFromString(classString);
        Animal *animal = [[animClass alloc] init];
        [animals setObject:animal forKey:[animal key]];
        [animal release];
      }
    }
  return self;
}

Our init implementation starts by finding all the class strings for the classes extending Animal. We iterate through the results creating an instance of each class and storing its pointer in the animals dictionary. With the init method complete let's modify the animalForKey: method.

- (Animal *)animalForKey:(NSString *)animalKey {
    Animal *animal = [animals objectForKey:animalKey];
    NSAssert(animal, @"No animal found.  Invalid 'animalType' specified?");
    return animal;
}

We now have a greatly simplified animalForKey: method. Gone are the if/else or switch statements you'd typically see in a factory method. Instead, we have a simple, generic execution path regardless of the number of animals we add to the application.

To see the benefits of our revamped AnimalFactory, let's make a couple additions to our animal kingdom.

@implementation Monkey
- (void)speak {
    NSLog(@"Ooo, Ooo, Eee, Eee");
}
@end

@implementation Bird
- (void)speak {
    NSLog(@"Tweet, tweet");
}
@end

We can go back to our client code and make the following changes:

[[factory animalForKey:@"dog"] speak];
[[factory animalForKey:@"cat"] speak];
[[factory animalForKey:@"monkey"] speak];
[[factory animalForKey:@"bird"] speak];

If you run the application again you'll see the new Monkey and Bird instances were automatically registered with the factory without any additional changes! Winning!

Conclusion

Although this was clearly a contrived example, it hopefully illustrates how leveraging the Objective-C Runtime can result in significantly more flexible factory objects. Some simple modifications could be made to this approach to provide for lazy instantiation or handle more complex object creation. In a future post I'll provide a more concrete example of how this strategy can be put to good use in a real-world application.

Resources

Sample Code

Objective-C Runtime Reference

Understanding the Objective-C Runtime

This past week I gave a presentation on Core Animation to the Minnesota CocoaHeads user group. Core Animation is a truly amazing framework and is really the magic ingredient in the iOS user experience. Understanding how to effectively use it can allow you to add new levels of realism and interactivity to your apps.

As part of the presentation I prepared a number of examples ranging from image effects to 3D animations (OK, 2 1/2 D animations). If you’re interested in taking a look you can find the demo on github and the slides are available here.

A common need in an iOS app is to tile a background image on a UIView. It’s trivial to implement, but not particularly obvious if you’re new to the platform. The solution is to set the view’s backgroundColor property to a UIColor instance created from your pattern image. For instance, the following code will create a pattern image from pattern.png:

- (void)viewDidLoad {
  [super viewDidLoad];
  UIImage *patternImage = [UIImage imageNamed:@"pattern.png"];
  self.view.backgroundColor = [UIColor colorWithPatternImage:patternImage];
}

This will produce the following effect:

Like most things in Cocoa there is usually an easy solution to the problem you’re trying to solve, but what it is may not be immediately apparent if you’re just starting out. Hope this helps.

Cocoa has long defined the IBAction and IBOutlet keywords. These keywords provide metadata hints to Interface Builder providing it some understanding of your underlying code so you can graphically wire instance variables and properties and set target-action behaviors. For instance, whenever you need a pointer to NIB-defined object you would create a property defined as:

@interface MainViewController : UIViewController {
    UIButton *saveButton;
}
@property (nonatomic, retain) IBOutlet UIButton *saveButton;
@end

The inclusion of the IBOutlet keyword in the saveButton’s property definition makes it visible to Interface Builder allowing this connection to be wired graphically as show below:

Using IBOutlet makes it very easy to define your UI in Interface Builder and simply “wire” the object references to your code. However, it does come with one major drawback in that the relationship from a NIB-defined object to property/ivar is always 1-to-1; there was no way to define a collection of components as a single property in your code. Thankfully, Apple quietly introduced a new keyword in iOS4+ called IBOutletCollection allowing you to do just this. Let’s take a closer look at an example where this can be useful.

IBOutletCollection

Like the other keywords previously mentioned, you’ll find the IBOutletCollection keyword in UINibDeclarations.h, which is part of the UIKit framework. The new keyword is defined as follows:

#ifndef IBOutletCollection
#define IBOutletCollection(ClassName)
#endif

You’ll notice that IBOutletCollection takes a class name parameter. This allows you specify what are considered valid values for the collection such as UIView or UIButton. If you’d prefer you can change the “type” argument to id to allow for a heterogeneous collection. So how could this be useful?

Putting IBOutletCollection To Work

I’ve often found times where I needed references to certain components, but really only in an aggregate way so I could change state on them as a group. To do this I’d first need to define separate ivar/property combinations for each component, wire them up in Interface Builder, and then manually collect each pointer into an NSArray and store the collection for later use. Although this works, it is rather tedious and does add unnecessary bloat to your code. A better way to handle this type of scenario is to make use of the IBOutletCollection keyword and wire up this relationship in IB.

In the example below I’ve defined two unique ivars/properties to hold references to my on & off buttons and then an NSArray to hold a collection of other buttons. The on/off buttons are used to change the enabled state of the group of “otherButtons”.

@interface MainViewController : UIViewController {
    UIButton *onButton;
    UIButton *offButton;
    NSArray  *otherButtons;
}

@property (nonatomic, retain) IBOutlet UIButton *onButton;
@property (nonatomic, retain) IBOutlet UIButton *offButton;
@property (nonatomic, retain) IBOutletCollection(UIButton) NSArray *otherButtons;

- (IBAction)toggleButtons:(id)sender;

@end

@implementation MainViewController

- (void)setButtonsState:(BOOL)state {
   for (id button in self.otherButtons) {
      [button setEnabled:state];
   }
   self.onButton.enabled = !state;
   self.offButton.enabled = state;
}

- (void)viewDidLoad {
   [super viewDidLoad];
   [self setButtonsState:YES];
}

- (IBAction)toggleButtons:(id)sender {
   [self setButtonsState:sender == onButton];
}

- (void)dealloc {
   self.onButton = nil;
   self.offButton = nil;
   self.otherButtons = nil;
   [super dealloc];
}

@synthesize onButton, offButton, otherButtons;

@end

I can now easily wire this together in Interface Builder without the need to write any code to collect and store the references to my group of buttons. This is clearly a contrived example, but I hope you can see the benefit of this small addition to iOS 4.

Thanks to everyone who turned out for the iPhone presentation Chris Bartling and I gave at last night’s Jam Session! We had a great time talking about a fun topic. I hope you enjoyed it.

There were some questions about Apple’s approval process. I mentioned that I just submitted an app this past Saturday and said I didn’t know how soon it would be before it was given the thumbs up. I wish I had checked my email during the break as it was approved last night. That’s not too bad a turnaround time. Thanks Apple!

Thanks again and I hope I’ll see some of you at next month’s CocoaHeads.