(The git mirror that I had created for OpenCV's svn is now gone.)

Note: If you've cloned a previous version, use git submodule init and git submodule update after pulling the latest rev to pull the correct version of OpenCV. If you get build errors, you probably need to do this.

I'm looking for someone (cough. I'm lazy.) who will take on the project of writing a step-by-step for integrating OpenCV static libs into a new iOS project. The examples directory has a SURF example that will automatically build all of OpenCV using cross-project dependency in Xcode that can be used as a basis for this. Any takers? Go ahead and fork me (heh) and issue a pull request.

Thanks to Nathan de Vries (@atnan) for improving the submodule checkout foo in the readme file.

Note: If you've cloned a previous version, use git submodule update after pulling the latest rev to pull the correct version of OpenCV. If you get build errors, you probably need to do this.

You can view a shaky video of the example running on an iPad 2 here.
You can get the code from github here.

Be aware that this code is GPL, which (among other things) means that you have to release any changes you make to the code under GPL and that this code cannot be used in a commercial project. There is also some speculation that the terms of using the App Store preclude GPL licensed projects as well. Caveat Coder.

Fast forward (ahem... cough... already?) years and I've lately had the pleasure of driving a Silver 2003 BMW M3. This is a machine that laps the Nüburgring in 8:22, gets from "naught to sixty" in 4.6 seconds. You wouldn't expect it, but the back seat is actually usable for two non-American-sized people and they both fold down to reveal almost station-wagon-like cargo space, passing through to the trunk. No kidding. I brought a 6' wire shelf home the other night. In real - world driving, it gets just barely less than 30 miles / gallon on the highway, which is waaay better than the latest M3, which, while it has 414 HP and obviously flies, gets about 20 MPG on the highway. That's worse than my E46 city numbers of 23 MPG or so, even though I drive with occasional (ahem) spirit. The engine redlines at 8000 RPM and the peak horsepower and torque both live very near that (around 7000), which means you have to grow accustomed to keeping the car above about 3000 RPM if you want any kind of torque. Oddly, that's a good thing. When you want to drive conservatively, it's easy to do so as the car has relatively little low-end power. If you want to throw it around a bit, keep the revs up. Simple. Very girlfriend friendly driving down low, grins up high.

(Over the break for pics and more)

I have a client who hasn't yet released any applications. (SOON! Right, Randy?) We ran into this problem together and spent a couple of hours pulling our hair out over this one. I suggested that he go ahead and add his banking information before escalating the problem to our friends at Apple and everything started working one he got himself setup for payments. Unless I'm missing something obvious in the docs, and since there is no error message that comes back from the Store Kit callback indicating why an item is invalid, there is really no way that one would know that other than to have stumbled upon it like we did.

(facepalm)

• It should be distributed, allowing me to branch and commit locally. I have lately taken to making atomic local commits and using local branches to experiment and I really miss that workflow when I'm working in svn.
• It should be ubiquitous and familiar. I don't want to learn another version control system, okay? I already have three version control systems competing for the mental space that used to hold one. I really just want one version control system that deals with everything.
• It should be able to easily pull subprojects from git, mercurial, and subversion repositories in a manner similar to subversion's svn-externals.
• It should allow me to work within those subprojects through plugins or natively so as to avoid the use of "foreign" version control command sets. In other words, I should be able to use the überVCS's command set inside of, for example, a subversion subproject. Ideally, I could work in one version control system and have subprojects from other version control systems just work somehow.

./contrib/gdata http://gdata-objectivec-client.googlecode.com/svn/trunk/ svn
./contrib/hgsubversion https://jonmarimba@bitbucket.org/durin42/hgsubversion hg
./contrib/mogenerator http://github.com/rentzsch/mogenerator.git git

  
./contrib/gdata http://gdata-objectivec-client.googlecode.com/svn/trunk/ svn --revision 533

[hooks]
post-status = python:hgexternals.extstatushook

./contrib/mogenerator git://github.com/rentzsch/mogenerator.git hg

./contrib/gdata svn+http://gdata-objectivec-client.googlecode.com/svn/trunk/ hg -r 533
./contrib/hgsubversion https://jonmarimba@bitbucket.org/durin42/hgsubversion hg
./contrib/mogenerator git://github.com/rentzsch/mogenerator.git hg

I'm performing a 5 minute "lightning" talk at the iPad/iPhone DevCon tomorrow and I'm not planning to use slides. I don't want to burn half of the 5 minutes getting keynote working, but hopefully attendees would like to have some of the links and code I'll reference. So! Here are my notes, links, and other such fodder. There is a lot more than 5 minutes worth of material here as I've been making notes about my habits for the last week or so; this is all of them. I plan to talk until I run out of air or out of time...

Tiny Little Habits for the iOS Dev to Avoid Premature Baldness

A foolish consistency is the hobgoblin of little minds, adored by little statesmen and philosophers and divines.

Here are some consistencies that I think are not foolish. These little habits have saved me a lot of stupid, often difficult to debug, mistakes.

Similarly

Speaking of delegates and protocols

Do as little setup work as possible in xibs, they work best for simply putting together UI geometry

• Avoid xib file dependencies (See this BNR blog post) Avoid making view controllers in MainWindow.xib
  • It's easy enough to make 'em in code. It's easier to know where things come from when you make them in code.
• Avoid setting delegates in xib files. Do it in code.

Lines of code are (mostly) free

[self setFloozle:[floozaWhat whatWithString:[NSString stringWithFormat:@"jeeminy %@ Christmas, %@", frickin, virginiaName]];

• When apple comes out with yet another screen size, you'll be (somewhat more) ready for it.
• When you want to change the size of something for some other reason, you don't have to generate a new image.
• You get to figure out how on the green Earth you designer does the crazy things they do in photoshop... only in Quartz.

Speed

• Red Sweater NSData thing that prints the hex for you
• IsEmpty from Wil Shipley with a small addition

  static inline BOOL IsEmpty(id thing) {
      return thing == nil
      || ([thing isEqual:[NSNull null]]) //My addition for things like coredata
      || ([thing respondsToSelector:@selector(length)]
          && [(NSData *)thing length] == 0)
      || ([thing respondsToSelector:@selector(count)]
          && [(NSArray *)thing count] == 0);
  }
  

• LogMethod() from Aaron Hillegass

  //Modified from Aaron hillegass's code
  #define LogMethod() NSLog(@"-[%@ %s]", self, _cmd)
  

• CPU and Memory tools I use to see what's really going on that I know I stole from a skojillian places, but can't remember who to thank.
• GTMHTTPFetcher to download stuff (and Google Toolbox for Mac in general)
• Nathan Eror's Core Animation Toys.

Subclassin' -- You stay classy, San Diego

Minimize direct access to the internals of your objects

• Write or synthesize accessors for ivars you want to share. Also, buy Accessorizer.app
• Remember, you can use readonly in a property when appropriate (and it is more often appropriate than you might think).
• Mark ivars you don't want messed with as @private. For srsly.
• Make good use of class continuations:
  • to document the internal workings of your objects (If the header is the public documentation, the continuation is the private, implementation documentation)
  • to suppress "may not respond to" compiler warnings
  • to expand readonly properties to readwrite status internally
  • to make a protected methods header file if you want subclasses, but not other users of a class, to use certain of its internal methods.
    • Import that file in subclasses to suppress compiler warnings.
    • Makes it easy to delineate private vs. protected vs. public methods

Know what you're really doing when you use dot syntax

I rarely return nil from something that is expected to return a string, dictionary, an array, or a set

    return @"";
    return [NSArray array];
    return [NSDictionary dictionary];

Make a logging method you can turn off and one you really can't; both call through to NSLog

#define LogMethod() SBLog(@"-[%@ %s]", self, _cmd)
#define WarnMethod() SBWarn(@"-[%@ %s]", self, _cmd)
#define SBWarn NSLog

#ifdef DEBUG
#define SBLog NSLog
#else
#define SBLog    
#endif

Run the static analyzer, but not all the time

• before a commit to source control
• after I make a new class
• any time I am alloc'ing a lot of stuff

If your code won't work unless some particular condition is satisfied, NSAssert that condition!

On External, third party, projects

• READ THE CODE
• UNDERSTAND THE CODE
• DON'T USE IT UNTIL YOU KNOW HOW IT WORKS (make a little test project to learn it and drop lots of breakpoints)
• If it's hard to read, it's probably broken.
• I'm on the three20 mailing list; you wouldn't believe some of the questions asked there...
• Add external files project relative outside of your project (makes updating the external project easier)
• Freeze external projects at a given revision number; update early on between releases:
  • in svn this is done with gtmOauth -r 19 http://gtm-oauth.googlecode.com/svn/trunk in an svn:external
• Avoid editing external projects directly (makes it hard to merge), instead subclass or make categories to change behavior
• When possible, avoid static libraries
  • Too many places where compiler flags are set.
  • Instead, compile in only those parts you need and their dependencies
  • I usually add just the top level source file I need and pull in dependencies as the compiler pukes, rinse and repeat until no errors or warnings.

Make tiny little test projects for new features

• As your codebase grows, new features can present a difficult integration, so split it into two steps
  • 1. New Feature
  • 2. Integrate new feature into codebase
  • 3. goto 1

If there is any chance that you've got a delayed perform of a selector scheduled, don't forget to cancel those when appropriate

+[NSObject cancelPreviousPerformRequestsWithTarget:]
+[NSObject cancelPreviousPerformRequestsWithTarget:selector:object:]

The iPad/iPhone DevCon will be held in San Diego from September 27 through 29 and I've been invited to give four classes! If you put my last name, SAGGAU, in when you register, you will automatically save a hundred bucks ($ 100.00) -- and it's combinable with their other promotional discounts, like Early Bird Specials and so-on.

The conference program at iPhone/iPad DevCon includes more than 40 full-day workshops, half-day workshops and technical classes over three days – in addition to keynotes by Mike Lee and Aaron Hillegass.

CLASS DATES AND TIMES