HOO

For Apple’s iOS, below is the code to implicitly animate a custom property, using float as an example, in a subclass of CALayer:

/* MyLayer.m */
@interface MyLayer() {
    BOOL _isPresenting; /* TRUE for presentation layer */
}
@property (nonatomic) float property; /* normally defined in MyLayer.h */
@end
@implementation MyLayer
@synthesize property = _property;
- (void)setProperty:(float)property {
    if (_isPresenting) {
        NSLog(@"Presenting layer");
        _property = property;
        return;
    }
    NSLog(@"Setting value");
    if ([self animationForKey:@"animateProperty"]) {
        _property = [[self presentationLayer] property];
        [self removeAnimationForKey:@"animateProperty"];
    }
    CABasicAnimation *a = [CABasicAnimation animationWithKeyPath:@"property"];
    [a setFromValue:[NSNumber numberWithFloat:_property]];
    [a setToValue:[NSNumber numberWithFloat:property]];
    /* Set other animation properties */
    [self addAnimation:a forKey:@"animateProperty"];
    _property = property;
}
+ (BOOL)needsDisplayForKey:(NSString *)key {
    if ([key isEqualToString:@"property"]) {
        return YES;
    }
    return [super needsDisplayForKey:key];
}
- (id)init {
    if (self = [super init]) {
        _property = 10; /* initial value */
    }
    return  self;
}
- (id)initWithLayer:(id)layer {
    if (self = [super initWithLayer:layer]) {
        MyLayer *l = (MyLayer *)layer;
        _isPresenting = TRUE;
        _property = l.property;
    }
    return self;
}
- (void)drawInContext:(CGContextRef)ctx {
    NSLog(@"%f", _property);
    /* Add drawing code */
}
@end

Then, setting the custom property with:

myLayer.property = 50;

gives the following in the log:

Setting value
Presenting layer
18.953653
Presenting layer
25.723625
Presenting layer
..
..
..
Presenting layer
49.999870
50.000000
50.000000

The animation is working, but it cannot be overridden. It is time to change that by adding:

+ (id<CAAction>)defaultActionForKey:(NSString *)key {
    if ([key isEqualToString:@"property"]) {
        CABasicAnimation *a = [CABasicAnimation animationWithKeyPath:@"property"];
        [a setValue:@"defaultAction" forKey:@"animationType"];
        return a;
    }
    return [super defaultActionForKey:key];
}

and modifying the setter to:

- (void)setProperty:(float)property {
    if (_isPresenting) {
        NSLog(@"Presenting layer");
        _property = property;
        return;
    }
    NSLog(@"Setting value");
    if ([self animationForKey:@"animateProperty"]) {
        _property = [[self presentationLayer] property];
        [self removeAnimationForKey:@"animateProperty"];
    }
    CABasicAnimation *a = (CABasicAnimation *)[self actionForKey:@"property"];
    if (a) {
        if ([[a valueForKey:@"animationType"] isEqualToString:@"defaultAction"]) {
            [a setFromValue:[NSNumber numberWithFloat:_property]];
            [a setToValue:[NSNumber numberWithFloat:property]];
            /* Set other animation properties */
        }
        [self addAnimation:a forKey:@"animateProperty"];
    }
    _property = property;
}

Now, all is good.

Apple’s GLKit framework for IOS 5 is a few objective-c classes that make it easier to program for OpenGL ES 2.0, especially when porting from OpenGL ES 1.1 applications to 2.0. OpenGL ES 2.0 of course is the new graphics API for creating pretty 3D scenes in mobile apps. What makes it particularly hard for developers to program in 2.0 is shader programming. The methods of graphics rendering or fixed-function pipeline in 1.1 has been completely removed and made programable in 2.0, requiring developers to write their own rendering codes in OpenGL shading language or GLSL; that is shader programming. Apple’s GLKit classes manage all the shader programming needed to render scenes in 2.0, so that the developers can eat-the-pie-without-baking-it. It is not such a bad idea except that shader programming is for customizing the rendering process and the main reason for switching to 2.0. If we are going to switch to OpenGL ES 2.0, we should learn shader programming, at least that is what I thought.

Obviously, GLKit is for IOS 5 and does not work in IOS 4. The framework methods are also very standard, mainly to ease the porting of 1.1 applications. GLKit has very few capabilities beyond what was defined in 1.1 that I suspect that Apple’s main reason for creating GLKit is to remove the support for OpenGL ES 1.1 in the future. These are all speculations. It is probable that Apple will improve GLKit defining more classes for volumetric shadows, bump mapping, refraction, and so on. If so, GLKit may be the future, extending its classes into future OpenGL ES API with new capabilities like tessellation. Developers of course have the option to choose third parties’ development kit, making GLKit framework an inefficient and redundant layer.