It’s September 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 September 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!

Nathan will be the subjet 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!

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.

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!

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.

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 usefulnes. 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.

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!

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!

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…