Today, Seth Godin is giving away iPhone App ideas, the first one helps you avoid traffic:

Have the iPhone use the gps data… upload where I was a minute ago and where I am now. Figure out my speed and route. Use the data to tell other RadaR users which route is best. It’s worth $20 a month if you live in a place with traffic jams. It’s a natural monopoly–once someone figures it out, why wouldn’t everyone want to use the market leader?

The Google Maps app on the iPhone has traffic data already–what’s missing is that I don’t think it takes that into account when selecting a route, or updates it if conditions change. If the traffic data is available with an API (like most google data), then this might be easier than even Seth thinks (no server side) — of course, no lock-in either.

The second idea needs some kind of server-side dialier because Apple doesn’t let apps run in the background:

Here’s an easier one that you could probably sell as well. I type in a phone number and enter a time. Record a message and press go. I can cue up a bunch of messages that are based on time. I can have groups get the message I record, at the time I want them to get it.

Thanks to Google, there’s a unit-testing framework for the iPhone. There’s not much more to say about it — the instructions are crystal clear and it worked exactly as described. It’s compatible with OCUnit (the Objective-C unit test framework in XCode), so once you set it up, you can just create test cases the way you would for any ObjC project.

One quirk — it instructs you to add a build step that runs the unit-tests during build time and shows the failures as compiler errors that you can then use XCode to track down. That’s nice, but I have found that you don’t really have enough of an environment to successfully run every kind of test — they run fine if you run them in the simulator. The main problem I have is with setting up my database in my Documents folder — I get errors at build-time that work just fine at run-time.

On my Atalasoft blog, I wrote some tips for debugging unmanaged crashes in .NET. The idea is the same for iPhone — namely:

The corollary to this tip is to get it to crash as early as possible. It’s no fun to figure out a crash bug once the culprit function has already returned. You really want the root cause somewhere on the call stack when it’s detected.

In XCode, it’s actually really easy to get information about how you might be managing memory incorrectly.

If you think you are having an issue where you go out of bounds of a heap allocated memory block, then in the Run menu, you can check “Enable Guard Malloc”. This will tell you if you overrun your bounds. It’s not going to be as handy as a Page Heap style check (where each heap allocation gets its own page and therefore crashes at the point of the mistake), but it’s better than nothing.

Go to Project->Edit Active Executable, go to the Arguments tab and in the environment variables section, add

NSAutoreleaseFreedObjectCheckEnabled
NSZombieEnabled
NSDebugEnabled

And set each to YES. You can leave them there unchecked, but if you check them, then your application will now do some extra checking on autorelease and release and give you a good stack trace when you have done it wrong. A common problem is to think you need to call release when the object is already set to autorelease (see yesterday’s post on what the rules are for that).

Also, I haven’t needed it yet for the iPhone, but MallocDebug is supposedly available for use when you debug through the device. I have used it for regular applications and it’s quite good at finding heap corruption problems.

I program all day in C# and C++ at my day job, so Objective-C is both natural to me (because of a mostly familiar syntax) and unnatural (because of it’s many differences). In terms of memory management, Objective-C splits the difference between C# and C++. On the iPhone, Objective-C does not have a GC, but NSObject (the base class for all of your classes) supports reference counting. Of course, you could build the exact same mechanism in C++, but it’s pervasive and included in ObjC and there’s also some support in the app runtime for an autorelease concept (release will get called for you on an object at some point when the runtime has control — you are safe in the rest of your stack frame).

When I first started Habits, I didn’t really read through the entire memory management API (there were so many other APIs to read) because I have been using reference counting for a long time (old COM programmer) and the awesome leak detector included in XCode was a good enough guide to what I was doing wrong.

However, the rules are really simple, and now that I know them, I never run into memory management issues:

1. Declare all of your object pointer @properties as retain unless you have a really good reason not to. Then the setter that is generated will automatically call retain when you assign. When you reassign, it knows to call release on the old value.
2. In your dealloc, assign all of your @properties to nil. This has the effect of calling release on the current values if they are not already nil.
3. alloc returns an object with a reference count of 1 — so you have to balance with a release.
4. If you alloc, then you should try to release in that same function. To retain the value, assign it to something that retains. Exceptions are if you are a factory function that is returning a value up to be retained by the caller.
5. Obviously, each retain call needs a release.
6. Built-in convenience functions return objects that are autoreleased. That means you shouldn’t call release on them — the framework will call release at some point (they are registered in an autorelease pool that that is serviced when you return back to the framework). If you created the object without an alloc/init pair, you don’t need to call release unless the docs say you do (but they probably don’t)
7. Check all of your work with the leak detector. Also, if you crash, you’re probably doing it wrong — I will have more to say on that soon.

I highly recommend that you read Very Simple Rules for Memory Management in Cocoa on stepwise.com. Keep in mind that the suggestions for building proper setters is handled automatically if you declare your @properties correctly.

Having now gone through getting Habits built, tested and on the App Store, I wanted to share these tips on getting started with iPhone development:

1. Go enroll in the iPhone developer program before you start. Yeah, I know — it’s 99 bucks. But if you have an idea and a reasonable chance of doing it, just take the plunge. I joined after I finished, and that caused a lot of delays — I could have been completing the other necessary steps in parallel.
2. As soon as you’re in, go get your application contracts going. If you want to make paid applications, you have to give Apple your tax and bank information. Again, it takes some time to get approved, so start early.
3. If you don’t know Objective-C — don’t worry, that’s the easy part. The primer on the iPhone developer site should be good enough if you know C/C++.
4. For Cocoa Touch, I recommend Erica Sadun’s iPhone Developer’s Cookbook. The chapter on coverflow is worth the price of the book, but everything else is there too (navigation, touch, location, contacts, etc)
5. I also highly recommend iCodeBlog. Once you have some basic knowledge of the framework, check out the to-do application tutorial.

Update: just found this great flowchart of the right order to do things