The heart of a DevCamp is the Hack-a-thon and we are happy to (belatedly) post the results of the DevCamp hacking contest. Below is a list of teams that created some of the most inventive, fun, and useful applications at DevCamp and we’ve additional descriptions, links, and some contact information. If you have additional information you want us to post about your entry, email us at info@codefab.com.

Campfire Application – Most original!

• Created by: Vincent Youmans, James Sabia, Ron Anderson, Harry Bowen, Chris Welsh, Jean Leong
• Description: Great campfire effect, in which sound from iPad campfire cooks iPhone marshmallows. Proximity detection or shake to reset marshmallow
• Watch the App in use: http://www.youtube.com/watch?v=fgvwaaYBFeQ
• For more information you can contact: : james.sabia@team.aol.com

Bread Application – Most likely to be used by Steve Jobs in an iPad presentation!

• Created by: Sean, Sandira, Ariel, Steve Liu, Staney Sulamet
• Description: Runs as an application in Safari that rotates and manipulates images on the canvas to make pages more magazine like without Adobe Suite.
• For more information you can contact: sulamet@yahoo.com

I Peel Onion Application – Coolest app!

• Created by: Jesse Pickard, Lucy Zhang
• Description: Cut through the noise of lots of tweets, and shows tweets and dial and graph.  Add metadata to tweet
• Real time voting on events for people!

NSTeam Application – Most likely to be used by developers!

• Created by: Andy Rifkin, Jeff Barg, Devin Duty
• Description: Syntax editor for iPad, Split view with list of files and edit space with syntax highlights, Uses core text
• To see photos and read more about the app go to: http://www.4-iPad.com

Stewie- Most likely to be used by Jason Calicanis

• Created by: Daria, Gilad, Mike Feola, Martin Volerich, Steve
• Description: Social gaming, ipad server, iphones clients, Bluetooth, game kit, universal app, players connect.

Wee Atlas Application – Most useful!

• Created by: Steve, Joshua Vickery, Matt Ferry, Seanita, Nir Pengas
• Description: Zoom in on country and interact with pictures, slide show under each category
• To learn more, visit: http://jsv.mine.nu/gallery/v/misc/iPadDevCampNYC/

Dragonflies Application – Most educational!

• Created by: Tom Fruenhoffer, Eva Potter, Praveen Aravamudham, Steve Bull, Charissa Smith, Ann McDermott, Hiroumi Mitani
• Description: Backyard bugs! Catch bugs or squish, look in jar, get info about bugs and uses cocos2d

Twitter All Stars: Heltweetic.3 Application – Best social app!

• Created by: Thomas Alvarez, Lucius Kwok,  Jeff Soto
• Description: Shows twitter avatars in a grid, allows user to randomly choose one.
• For more information you can contact: jeff@indiancode.net or dmthomas@mac.com

VectorZombie Application – Best game!

• Created by: Jonathan Miller and Karen Jones
• Description: Snowboarding through a field of zombies!
• To see more go to: http://cryptogram.com/zombieboard/
• if you have any questions you can contact: jm@jonathanmillertechnology.com : @notjonathan on Twitter and Karen@geekgirl.com

Ghost in the Machine – Best iPad app!

• Created by: Dominic Tancredi, Danny Sand, Peter Levine, Carolyn Gargano, Catrina Lohan, Scott Benglo, Yan Wong, John Fitzpatrick
• Description: Ghost in the machine ouija board, and has sound, animation takes finger input.
• To see the App in use go here: http://www.youtube.com/watch?v=wCTtI2TMdqA
• if you more questions you can contact: meta.phx@gmail.com

BoomBox Application - Most commercial!

• Created by: Steven Levy, Erin Disselhorst, Rob Kelley, Matt
• Description: Plays music and looks good

CookIt – Best Under Pressure (cooker)

• Created by: Tim Kaminski, Dana
• Description: Sound activated ipad cookbook, you can move to the next step in the recipe with a sound

If we got your name wrong, or lost a last name or contact email, or even if you just want to update the description, ping us at info@codefab.com – we want to get it right!

Well, in the simplest cases, when there are only a few messages, and only a few listeners, and few objects that wake up to look at the userInfo to see if it is interesting, one might opt for the simpler programming / inheritance model and have very little code, reused via inheritance that does all the work. E.G. all objects inheriting from BaseObject listen for message “foo” and then inherit the code for:

-(void)fooNotification:(NSNotification *)notif {
  if ([self.id isEqual:[notif.userInfo objectForKey:@"id"]]) {
    [self handleFoo:userInfo]; // do something
  }
}

The BaseObject class has the id filter notification handler (above), a no-op handleFoo:, which sub-classes can override, and the sender always sends out the same “foo” notification, with the differentiator tucked away in the userInfo for the recipient.

Sounds good, no? Lots of inheritance, code reuse, simplicity. The “leaf-node” classes just implement handleFoo: if they need to. All works great. But where does this break down?

Say you had a thousand BaseObject subclass instances. When they are created, they ask a Loader for some resource and listen for loaderDone Notifications. Loader finishes each request, sends a notification, moves on to the next. (You are using an NSOperationsQueue to manage your Loader pool, right?) Instances get pinged after operations complete and one says “Hey! That’s me!” and does something significant, like update a bit of UI, while the others pass. The rub? One thousand objects wake up and run a few lines of code for each one that does anything. Code is simple, easy to test. Low message dispatch cost. Probably insignificant overhead on your spiffy new PowerMac. Zero problem in testing with a few objects. But on the iPhone / iPad this is 9,999 objects too many involved in handling the event.

What do you do?

First is just good practice: if you don’t care, don’t listen. Don’t register to observe a notification until you are sure you care, then if you no longer need to listen, unregister. For our pseudo-code, only listen between “I need a foo” and “I got a foo” – outside that take yourself out of the loop. That can only help.

The real trick, when you see this pattern, is to find a way from our default case above, where response time depends on number of potentially interested objects, to a response time dependent on just number of actual interested objects. In the base case, where we have N potentially interested objects and just 1 interested object, we are going from a fluctuating case, based on set size N, to a stable linear case. This in turn leads to more predictable and scale-free (or close to it) response times.

(In our initial example above, response time is equal to “([number of objects] * ([filter time per object] + [message time per object])) + ([number of interested objects] * [handle time per object])”. What we want is to only message the interested objects, so we can be “[number of interested objects] * ([message time per object] + [handle time per object])”.)

So what is the simple trick to do this? Have the listening objects listen for a NSNotification with a name like:

  NSString *notifName = [NSString stringWithFormat:@"foo-%@-notification", self.id];

and have the Loaders post matching notifications. The observer lookup table will be a bit larger, with more messages registered, but the observer count will be the same. The lookup will mostly be a hashed lookup based on the memory location of the notification name’s unique string, and on ObjC / Foundation, that kind of lookup is FAST for the set size we are looking at. And even for large sets, we are so much better off paying the price to look up a single observer, than to have to run 4 lines of code in a very large number of objects.

Things that can make the bad case worse?

1. Side-effect cost: You never know what the cost is of asking an object you haven’t written yet a simple question. (“My id? Sure, that’s stored in my NIB file. Which needs to be (re)loaded sometimes. Which instantiates other objects. Which do stuff.”)
2. Threads: An even worse cost is the per-object code that does something that launches or spans thread boundaries. (“My id? Let me fetch that in a new thread. Or in the main thread, which could block stuff.”) Opportunity for thread overload or lock-ups with contention for resources.

Linear response is your friend. Do a little extra work. Easier to debug. Easier to optimize. Happier users.

Remember – your iPhone is like a 100mhz Pentium. CPU cycles are your most precious resource. And less executing code in less objects usually means less less memory, which is our second most precious resource. Less work, less memory, app runs faster, users happier. Everyone wins.

NOTE: For everyone going to WWDC this year, CodeFab will be hosting several iPad/iPhone related events at the SF iPhone Mansion again. On the Saturday and Sunday before WWDC we will be hosting a Mini iPad/iPhone DevCamp (Register Here) in conjunction with our LA iPhone DevCamp/Developer Meetup partners. We will also be hosting a fabulous iPhone Party on (tentative) Tuesday Night. (Hope you remember last year’s blast!)

April 24-25 – LA iPhone/iPad Developer Special Ops Advanced Class
Register here: http://laipadtraining.eventbrite.com/

May 8-9 – NYC iPhone/iPad Developer Special Ops Advanced Class
Register here: http://nycipadtraining.eventbrite.com/

May 22-23 – Chicago iPhone/iPad Developer Special Ops Advanced Class
Register here: http://chicagoipadtraining.eventbrite.com/