Free Time Studios » Nathan Eror

Fun With Core Animation: Shutter Transition

Nathan Eror — Mon, 06 Sep 2010 05:38:26 +0000

It’s all over the Twitter now that I forgot about my first #idevblogaday post. So, in the interest of hitting my deadline (and keeping my slot), this post will be quick. I’ll also keep the subject matter squarely in my wheelhouse: Core Animation.

While preparing the material for my half-day workshop at iPhone/iPad DevCon at the end of the month, I added some more examples to my stable of Core Animation examples. One of the new examples is based on an idea that has been rattling around in my head for a while. I call it the shutter transition. Rather than explain what I mean by "shutter transition", I’ll let this quick screencast do the talking for me:

While this is a fairly simple animation, it was a fun problem to solve. It was so fun, in fact, that I solved it two different ways. I’ll briefly cover the most universally applicable solution today, and we’ll revisit this code in a later post to cover the other solution. This is going to go fast, so hold on tight. Also, please forgive the directness. I’m on a deadline here.

The shutter animation can be broken into the following steps:

Flatten the layer to be animated into a single bitmap.
Create multiple CALayer objects of equal size to be the shutters.
Loop over all of the shutter layers and:
- Set the flattened bitmap to the contents of each shutter.
- Line up all of the shutter layers horizontally.
- Set the contentsRect of each shutter to be offset slightly based on its position in the list.
Hide the original layer, and show the shutters.
Animate the shutters offscreen, alternating the direction.
Once the shutters are offscreen, remove all of them from their superlayer.

Got it? Good.

Let’s take a look at the code that actually does this. If you are so inclined, all of the code for the shutter transition is on github. Feel free to play with this code and use it however you please in any project. You can also use it to follow along with this post. For those of you following along in Xcode, all of the code I’m about to quote is in the doShutterTransition method.

Let’s get started.

First, We need to flatten our layer into a single bitmap. The renderInContext: method on CALayer makes this very easy for us:

CGSize layerSize = mainLayer_.bounds.size;
CGColorSpaceRef colorSpace = CGColorSpaceCreateDeviceRGB();
CGContextRef context = CGBitmapContextCreate(NULL, (int)layerSize.width, (int)layerSize.height, 8, (int)layerSize.width * 4, colorSpace, kCGImageAlphaPremultipliedLast);

[mainLayer_ renderInContext:context];
UIImage *layerImage = [UIImage imageWithCGImage:CGBitmapContextCreateImage(context)];

See? I told you it was easy.

You’ll notice that I create the two animations next. There is a good reason for this. When an animation is added to a layer, the layer makes a copy of the CAAnimation object for its own purposes. Since we will be adding the animations to layers inside of a loop, we can take advantage of this copy behavior and only create the animations once. That way, we won’t incur the overhead of instantiating and throwing away a new CAAnimation object on every loop iteration.

The animation code is very straightforward:

CABasicAnimation *slideUp = [CABasicAnimation animationWithKeyPath:@"position.y"];
slideUp.toValue = [NSNumber numberWithFloat:-(mainLayer_.frame.size.height / 2.f)];
slideUp.duration = 1.f;
slideUp.timingFunction = [CAMediaTimingFunction functionWithName:kCAMediaTimingFunctionEaseInEaseOut];
slideUp.fillMode = kCAFillModeForwards;

CABasicAnimation *slideDown = [CABasicAnimation animationWithKeyPath:@"position.y"];
slideDown.toValue = [NSNumber numberWithFloat:(mainLayer_.frame.size.height / 2.f) + [UIScreen mainScreen].bounds.size.height];
slideDown.duration = 1.f;
slideDown.timingFunction = [CAMediaTimingFunction functionWithName:kCAMediaTimingFunctionEaseInEaseOut];
slideDown.fillMode = kCAFillModeForwards;

Now we need to remove our original layer from the hierarchy and start creating and adding our "shutters". We also wrap this whole loop in a CATransaction block so that the animations are all in sync.

Finally, we set a completionBlock to remove our shutter layers from the superview once they are offscreen. Because we’re using blocks here, this will only work in iOS 4+. You could implement an animation delegate if you have to target anything earlier than iOS 4. You poor, poor soul.

NSMutableArray *bands = [[NSMutableArray alloc] initWithCapacity:BAND_COUNT];
[mainLayer_ removeFromSuperlayer];

[CATransaction begin];
[CATransaction setCompletionBlock:^(void) {
  [bands enumerateObjectsUsingBlock:^(id obj, NSUInteger idx, BOOL *stop) {
    [obj setDelegate:nil];
    [obj removeFromSuperlayer];
  }];
}];

CGFloat bandWidth = layerSize.width / (CGFloat)BAND_COUNT;
for(int i = 0; i < BAND_COUNT; i++) {
  CALayer *band = [[CALayer alloc] init];
  band.masksToBounds = YES;

  CGFloat xOffset = 1.f / (CGFloat)BAND_COUNT;
  band.bounds = CGRectMake(0.f, 0.f, bandWidth, layerSize.height);
  band.contents = (id)[layerImage CGImage];
  band.contentsGravity = kCAGravityCenter;
  band.contentsRect = CGRectMake(xOffset * i , 0.f, xOffset, 1.f);
  CGPoint bandOrigin = mainLayer_.frame.origin;
  bandOrigin.x = bandOrigin.x + (bandWidth * i);
  [band setValue:[NSValue valueWithCGPoint:bandOrigin] forKeyPath:@"frame.origin"];

  [self.view.layer addSublayer:band];

  [band addAnimation:(i % 2) ? slideUp : slideDown forKey:nil];
  [bands addObject:band];
  [band release];
}
[CATransaction commit];
[bands release];

That’s all there is to it. The real key here is the contentsRect attribute of CALayer. This example was actually created to illustrate its usage (among other things). contentsRect defines what portion to show of the image in the layer’s contents attribute. You’ll notice that the elements of the contentsRect are normalized meaning that each element is in the range 0 - 1. Think of the origin and size of the contentsRect as percentages.

I know we blew through that example really quickly. I’ll be more gentle next time. For now, I need to get this published to meet @mysterycoconut‘s deadline.

Until next week…

SlapHappy!™ is Officially Released!

Nathan Eror — Tue, 16 Feb 2010 05:54:46 +0000

It’s February 16th on the East Coast, and SlapHappy!™ is now live in the US app store. I don’t know about other countries, yet, but I assume that if it is February 16th somewhere in your country, you can get it now.

To celebrate the launch, SlapHappy!™ is on sale for $.99 for a limited time. Check out the trailer below and get it in the App Store!

Chat With Free Time Studios Founder, Nathan Eror, Today at 12PM CST!

Nathan Eror — Tue, 26 Jan 2010 16:11:23 +0000

Nathan will be the subject of the first 360|idev speaker chat at 12PM CST today. This is a great opportunity to get a feel for his sessions at both 360|idev in San Jose this April and at iPhoneDevCamp Houston this Saturday. Drop on in and ask away!

iPhoneDevCamp Houston Presented by Free Time Studios

Nathan Eror — Tue, 12 Jan 2010 17:00:35 +0000

2010 is shaping up to be an exciting year for those of us in the iPhone and mobile software business, and there is no better way to kick it off than with a free community event. Free Time Studios is proud to be a major sponsor and primary organizer of the first ever iPhoneDevCamp Houston. If you are in the general vicinity of Houston on the last weekend of January, this is a can’t miss event. There will be presentations for people of all skill levels covering app development and marketing. Whether you are a seasoned or hopeful iPhone developer, there will be something for you at iPhoneDevCamp Houston.

Also, make sure to get your sleep on Friday night because we will be hacking all night Saturday. Show up with your ideas and your laptop, and work with the top iPhone development talent in the Houston area. Caffeine and sustenance will be provided.

Join the all of people who have already registered and sign up here. It’s free.

Check out the iPhoneDevCamp Houston website for more information.

Introducing FTUtils: Open Source Utilities for iPhone Developers

Nathan Eror — Tue, 05 Jan 2010 19:33:13 +0000

For my Core Animation presentation at 360idev last year, I created a bunch of sample code to show how simple and powerful Core Animation is. I also promised that I would update the sample code with even more advanced examples. That has not really happened (yet!), and it is time for me to atone.

I am very excited to officially release a collection of utility code that I have accumulated over the past year: FTUtils! It is the first dependency I add to all of my projects, and I have already received enthusiastic feedback from developers who have stumbled on the github project.

It probably comes as no surprise that the bulk of FTUtils contains enhancements and extensions to the Core Animation API (called FTAnimation). I use Core Animation a lot, and I have tried to find elegant ways to round off some of the sharper edges of the API. FTUtils is not only about Core Animation, though. It features:

A category on UIView that puts 13+ canned animations only a method call away.
Access to the CAAnimation objects for the canned animations so you can mix and match them all you want.
Implementation of the target/action pattern for animation delegate callbacks. No more huge animationDidStop:finished: methods!
Simple chaining of an arbitrary number of animations.
Embedding of a pre or post animation delay directly in the CAAnimation object (useful for chaining).
performSelector* methods built for calling delegates that elegantly handle non-existent selectors and allow the passing of primitives as parameters.
Simple methods for reversing arrays.
A collection of macros to make common code patterns simpler to use.

Since I use FTUtils in all of my projects, it is updated regularly with bug fixes and new features. Currently, I am working hard at documenting the whole library at ftutils.com, and I will be pushing updates to the site as I finish chunks of the docs.

The iPhone developer community is an active and friendly one, and it has been very good to me. I am glad to have something to give back. Also, for those of you planning to attend 360idev this April (you should go…really), I will be speaking about advanced uses of Core Animation including an explanation of how everything in FTAnimation works.

One more thing…

Here’s a screencast showing off the canned animations in FTUtils. The code for this app is in the Examples directory of the project.

Enjoy!

Core Data Tips for iPhone Devs Part 2: Better Error Messages

Nathan Eror — Fri, 13 Nov 2009 22:13:46 +0000

Continuing our series of Core Data tips and tricks, we turn to error handling. All good developers know that error handling is an essential piece of quality software. Unfortunately for Cocoa developers, error handling can be a little cumbersome and verbose on our favorite platform. This is a small price to pay to be able to work with such outstanding libraries and APIs, but the constant code repetition can eat away at our keyboards. Frustratingly, the errors we work so hard to catch and handle are, sometimes, not useful at first glance. This is definitely the case when saving an NSManagedObjectContext.

The Problem

Early in development, the data model model changes often, and errors are inevitable. Forget to make a new attribute optional, and the code blows up while saving the context. Because I move pretty fast and change things often, this kind of stuff happens to me all the time. Core Data provides me this error message quite often:

Domain=NSCocoaErrorDomain Code=1560 UserInfo=0x14f5480 "Operation could not be completed. (Cocoa error 1560.)"

For the developer inexperienced with Core Data, this is a very disheartening message. It does not give us any indication of what went wrong or how we should attempt to fix the problem.

The Solution

It turns out that, if there is more than one error, Core Data puts an array of NSError objects in the userInfo dictionary with the key NSDetailedErrorsKey. This is not obvious, and it drove me crazy for a while until I turned to Stack Overflow where someone else had already asked my question. There, someone named Charles provided this solution with code to get at the "real" error. Overjoyed, I turned the code into a macro, and I use it exclusively to save a context during development. Here is the macro:

#define FT_SAVE_MOC(_ft_moc) \
do { \
  NSError* _ft_save_error; \
  if(![_ft_moc save:&_ft_save_error]) { \
    NSLog(@"Failed to save to data store: %@", [_ft_save_error localizedDescription]); \
    NSArray* _ft_detailedErrors = [[_ft_save_error userInfo] objectForKey:NSDetailedErrorsKey]; \
    if(_ft_detailedErrors != nil && [_ft_detailedErrors count] > 0) { \
      for(NSError* _ft_detailedError in _ft_detailedErrors) { \
        NSLog(@"DetailedError: %@", [_ft_detailedError userInfo]); \
      } \
    } \
    else { \
      NSLog(@"%@", [_ft_save_error userInfo]); \
    } \
  } \
} while(0);

Now, whenever I need to save the context, I can do it safely and comfortably like so:

FT_SAVE_MOC([self managedObjectContext])

This macro only prints the error messages, but all I want during development is error messages in the console. This code can easily be moved to a function or method to do more robust error handling in a production scenario, but that would fill an entire post on its own.

Core Data Tips for iPhone Devs Part 1: Command Line Shortcuts

Nathan Eror — Wed, 11 Nov 2009 19:17:31 +0000

I recently finished migrating the data management backend for all of my games to Core Data from a custom sqlite implementation. This is part of my commitment to use more Apple APIs where it makes sense, and this one made a lot of sense. While the migration took me a couple of days, the benefits of using Core Data have already paid back that investment in improved performance and better data design. Among other things, my domain objects are now much more granular which allows me to pull only the little bits of data that I need when I need them. Core Data makes managing the relationships between all of these little domain objects dead simple. In other words, I don’t have to write any more join queries!

Core Data is a massive topic, and I have only begun to scratch the surface of its usefulness. Still, I have found myself doing some repetitive tasks both at the command line and in code. Like any self respecting programmer, I hate repetitive tasks, and my Makefile and header file of macros have grown as a result. Since most of the shortcuts I have come up with will probably be useful to others, I am putting them together in a series of blog posts. This is the first of those posts.

The Problem

Core Data allows you to choose from multiple backend storage methods, and, other than having to choose a type, the data store is completely transparent. The recommended store on the iPhone is sqlite, and not only is it fast, but the schema generated by Core Data is fairly readable. Being able to poke around in the sqlite file was an immeasurable help while I was learning Core Data. The biggest problem is finding the sqlite database file. Every time you build and run your app in the simulator, the application directory is renamed with a new GUID which makes it really hard to find:

Can you find your app?

The Solution

Thankfully, OS X has the full compliment of unix command line tools. Wrap the proper commands in a Makefile, and you have some instant command line Core Data database management tools. Unix to the rescue! Here are the four make targets that I use the most:

SQLITE_DB_FILE=AppData.sqlite
SIMULATOR_HOME=$(HOME)/Library/Application\ Support/iPhone\ Simulator

dbshell:
      find $(SIMULATOR_HOME) -name "$(SQLITE_DB_FILE)" -exec sqlite3 {} ';'

killdb:
      find $(SIMULATOR_HOME) -name "$(SQLITE_DB_FILE)" -exec rm {} ';'

dbschema:
      find $(SIMULATOR_HOME) -name "$(SQLITE_DB_FILE)" -exec sqlite3 {} .schema ';'

dbdump:
      find $(SIMULATOR_HOME) -name "$(SQLITE_DB_FILE)" -exec sqlite3 {} .dump ';'

The target names should make their use self explanatory, but I’ll summarize them:

dbshell: Open up the sqlite command line shell with the Core Data database selected.
killdb: Delete the database file. This is useful if you’re making big changes to the schema and you would rather delete the whole database and start over rather than migrating the schema.
dbschema: Dumps the CREATE statements required to recreate the schema. This is useful to see how Core Data persists your object graph.
dbdump: Dumps the schema as CREATE statements and all of the data as INSERT statements.

There is nothing magical or difficult about these, but I have found them to be very useful while developing my data model.

Core Animation: Hands-On @ 360idev. Yes, There is More!

Nathan Eror — Fri, 02 Oct 2009 22:03:14 +0000

I was surprised and excited to see the standing room only turnout for my in depth Core Animation talk at 360idev this week. I thought it would be a popular topic, but Collin really got people fired up to learn more during his introductory talk. I was able to cover quite a bit of material in my 80 minutes, and I got some awesome feedback from the developers in attendance. The most common thing I heard from developers was some variation of “I didn’t know I could do that!” or “You just saved me X lines of code!” It was simultaneously flattering and disappointing.

SlapHappy! is written entirely with Core Animation, and I’ve dug deeper into the API than most people outside of Apple. I’d forgotten how much of the stuff I know was picked up through a combination of trial and error, debugging, digging into headers, and re-reading books and documentation. I didn’t expect that others have been as intimate with Core Animation as I have, but I was still a little surprised to see the lights go on in people’s heads as I spoke.

My experience presenting at 360idev proved what I had suspected: Many iPhone developers look at Core Animation as a low level framework hidden inside the black box of UIKit. I’d like to change that perception. While you can write an entire iPhone app without even knowing that Core Animation exists, just a basic understanding and application of the API and its concepts can go a long way to separate your app from the other 85,000+ in the app store.

Since I was not able to cover everything I wanted to in my 80 minutes at 360idev, I am putting together a series of blog posts with Core Animation tips, tricks, lessons learned, and code. Consider this the first in the series. I’ll kick it off with my slide deck and a link to the more than 1,400 lines of sample code I prepared for the presentation.

The Slide Deck: Core Animation Hands-On: Building Complex and Attractive Cocoa Touch Interfaces
The Code: http://github.com/neror/CA360

I will be adding to the sample code project as I work on this series so make sure to watch the project on github. Also, if you have any burning Core Animation questions that you’d like to see covered in this series, drop me an email or add a comment to this post.

Oh, and thank you again Tom and John for giving me the opportunity to be a part of such a tremendous show!

Speaking at 360|iDev in Denver

Nathan Eror — Fri, 19 Jun 2009 21:00:49 +0000

I’ll be speaking about Core Animation at 360|iDev in Denver this September. Here’s what I’ll be talking about:

Using Core Animation to Build Complex and Attractive Interfaces

Core Animation plays an integral role in the iPhone user interface and is responsible for much of its intuitiveness. Careful use of animation can make even an average app a joy to use. In this session you will learn how to effectively apply the features of Core Animation in your own apps. After a brief introduction to the principles behind Core Animation, you will learn how it is used in UIKit. Then, we will dig into the meat of Core Animation and how to use it effectively. Using the open source FTAnimationManager as an example, you will learn how to tame some of the complexities of the Core Animation API. By the end of this session, you will be comfortable with Core Animation, and your apps will run more smoothly and be more visually appealing.

I hope to see you there. It’s going to be an outstanding 4 days!

The SlapHappy!™ Beta is Coming Soon!

Nathan Eror — Wed, 10 Jun 2009 23:21:59 +0000

I’m gearing up the the first beta of my first game, SlapHappy!™. For the moment, I’ll leave you to figure out what the game is all about from the title.

If you’d like to be a part of the beta program, head on over to the contact page and fill out the form.

More information to come soon…