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.
Getting close to finishing up an app for a client in the coming weeks, my business partner and I decided it would be a good idea to include some analytics code so we could track how people are using our application. We ended up using Pinch Media’s Analytics to do our tracking. It came down to this: their code is REALLY easy to implement, and they provide us with just enough information to satisfy our curiosity. I think one of the biggest draws is that it records information regardless of the user’s online status – meaning offline app usage information is stored to a small database and then uploaded once the user reconnects. Had we used a web-based solution, which would have been natural given the nature of PhoneGap (the underpinning of our application) being UIWebView, we would have missed out on some details without considerable work-arounds to cache data as Pinch Analytics does.
Moving forward, I’m likely to investigate some of the finer points of creating my own PhoneGap callback functions so I can embed Pinch Analytics Beacon methods, which are nice little ways to record information about discreet actions taken within your app – recording leader board views, for example.
I recently ran across some major performance problems with a jQTouch app running in PhoneGap. Some of the symptoms included long pauses on touch events, non-responsiveness, and laggy transitions.
Brian LeRoux (Nitobi/PhoneGap), Jesse McFayden (Nitobi/PhoneGap), and David Kaneda (jQTouch) were the stars looking into this issue. Ends up Jesse found where the Accelerometer was taking a 40Hz sample rate and sending the data to a callback. The solution is to just disable Accelerometer use – either in the plist or, as I did, comment-out all the accelerometer bits. Likewise, I removed location functionality, as this app in particular doesn’t need it.
You can read Jesse McFayden’s post here. And if you’ll excuse me, I have an app to finish…