Found this great little debugging tip over at MarkJ.net. The short of it: You can use NSZombie tracking to debug memory crashes in your code. Great find – this whole time I was kinda under the impression that there was a lot of educated guessing involved based on where your fingers last touched code. I’m so naïve.
Well on my way to becoming comfortable with Objective-C and Cocoa, I came across the need to create two versions of an app I was working on – one a “Lite,” and the other a full version.
Branch merging scares me
Like any good developer, I use source control management to keep tabs on my development cycles. This time, being no different than any other, I dutifully created a new branch for a lite version of my application once I completed the critical features milestone. Being one who doesn’t have a lot of use for branching in most projects, I was reluctant because (be honest here) the notion of merging back and forth between the lite and the full branches was a painful one.
Ok, I know – merging shouldn’t be that big of a deal, but what about this scenario? I’m adding some features to the full version that I decide I want to port back to the lite. Auto merging isn’t going to work (we can give the lite app all the same features of big brother), but neither am I so keen on going line-by-line every time I make a change. Cry me a river, right? Well, no. Actually, the solution is easier than that.
Enter: Compiler flags
I don’t know when I first learned about it – it could have been in my early programming days when I was learning about C – but I’ve always had ideas about compiler flags in the back of my head… very dim ideas. Look through Cocoa demo apps (check your Cocoa docs) and you’ll see several that have lines of code that seem to point to something specific:
//do something here
That’s a compiler flag. That’s the key to getting your lite version separated from the full version at compile time (or runtime, or whatever, depending on your need). Using those compile flags you can separate specific portions of code for one version of your app to another.
I’ll save you the dirty details of how you do this. Instead, head over to Junda Ong’s blog.
It’s Thanksgiving Day weekend – one of my favorite of the year – because it gives me the chance for some nice, quiet R&D time without the pressure of clients or projects asking to get things done. This week I finally made it through enough of my Objective-C/Cocoa/iPhone books that reading further felt like I was just going over more specialized use cases. For now I don’t foresee the need to have covered every topic before I get started – the basics are covered.
Of the app ideas I had going into this weekend, I chose the simplest (training wheels – crawl before I can walk, right?). It’s a Tabata timer for interval-based workouts. Nothing too special. The basic functionality is there, but I want to pretty it up and add a couple features before submitting it to the app store. I doubt it’ll really make me any money, but I did it for the exercise, not for the big bucks. I’ll post screenshots and links when it’s finished/up.