Paul Hart

The catalyst for this post is an email I received a couple of days ago in relation to my “day” job.

We have a client based in the northern U.S. who own and operate some electricity generation plants. We picked them up as a client almost by accident; we attended a conference with assumptions that were way off base, but we walked away with a (then prospective) client as a result. We’ve now been working together for a couple of years, and while they aren’t a huge revenue source for us, we’ve built a great rapport.

Last week our client contact sent an email to confirm that our most recent invoice was being processed. This was followed by what could best be described as a love letter, extolling how our two cultures were a great fit and that we’d be their first stop for any future custom software development.

My first reaction to the note was “well of course we’ve been focused on your needs, why wouldn’t we work that way?” Having given it some thought, it seems clear that there are two business models in play here. Our objective has been to develop relationships with our clients. We get to know the players, learn about their business and needs, and come up with solutions designed to target their particular environment. We don’t claim to be experts at everything, but we’re very good at what we do and we have some accrued technical knowledge that we can apply to a business problem to better serve our clients.

Right now we’re working for our client on a project with another technology partner, and their focus is different. They are selling a prepackaged solution to our client and applying some customizations to it (we’re integrating various data feeds into their system). The other vendor may not see the same future with our client as we do, as their business revolves around their existent product – once it’s installed and customized, they’re done and their major association with the purchaser is over.

Neither model is “right” in the sense that one is superior to the other. Both work for the business models they support. However, I prefer creating a situation where my clients want to do business with me again in the future, and sometimes that’s lost in the short-term thinking that can be associated with a sales-driven mindset.

While it’s nice to know how many people have acquired your app, whether through iTunes Connect or with a third-party application like AppViz, neither of those will tell you about how your app is being used. For that kind of information you’ll need a metrics library that sits inside your application and measures usage patterns. Fortunately, Pinch Media offers a great solution called Pinch Metrics. Here’s a quick guide on setting it up for your app.

Jump Into The Pool

As with so many services online, you can’t play until you’ve registered. Cleverly, the folks at Pinch Media recognize that the entire point of a developer signing up with them is to put the Pinch Metrics library into their app, so the registration process includes a step to add an initial application. After this, and once you’ve confirmed your email address, you’ll be provided with a unique key to identify your application, as well as a link to download the metrics library.

Project Configuration

Now that we’ve got the basics available, it’s time to build them into the project. When you crack open the zip file that contains the metrics library (at least as of version 69), you’ll find a couple of header files and a library ‘.a’ file. If you’re using Facebook Connect, you’ll want to use the Beacon+FBConnect.h file; otherwise, or if the last few words made no sense to you, use the Beacon.h file.

Drag the header file from the finder into the Classes folder of your project in Xcode, and check the ‘copy items’ box before clicking ‘Add’. Do the same process with with the libPMAnalytics file, but copy that to the Frameworks folder.

Next you’ll need to add a few more frameworks that the Pinch Metrics library depends on. These are CoreLocation, SystemConfiguration, and libsqlite3.a. You should be able to find these by control-clicking on the Frameworks folder, selecting Add… Existing Frameworks…, and then highlighting the required items from the list.

Initial Code Updates

The foundations are now in place for you to track user habits, and your code needs to build on them. The first thing to do is to import your selected header file into your application delegate’s header (something like ‘blahblahAppDelegate.h).

To start gathering metrics, you need to call the Beacon object’s initAndStartBeaconWithApplicationCode class method. This call should be made in your applicationDidFinishLaunching method. You can pass parameters to configure whether or not to collect the user’s location, and whether or not to send metrics over a WiFi connection only.

While you don’t have to stop the Beacon cleanly, it will consider closures of the application without a clean shutdown as crashes. To close the Beacon, call the endBeacon instance method. You’ve now done enough to start collecting useful data about the number of times your users run your app, where they are (either based on physical location or by IP address), and how long they had your app open.

Getting Granular

While it’s nice to know that people used your app, it’s better to know what they were doing with it. You can add as many ’sub-beacons’ to your app as you like. No configuration is required at Pinch Metrics to create more sub-beacons, you can just create them in your code as needed. Each sub-beacon requires a unique name of 32 characters or less. A sub-beacon is created by calling the startSubBeaconWithName instance method.

You can specify whether or not you want your sub-beacon to be timed. In some circumstances you want to know how long a user accessed a particular activity, such as playing a game. In other cases, you’re simply interested to know whether or not something was accessed at all, perhaps an in-app purchase screen (or better yet, a purchase confirmation screen). If you create a timed sub-beacon, you’re responsible for stopping the timer by calling the endSubBeaconWithName instance method. Any sub-beacons you forget to stop will automatically be stopped when the application exits.

Knowing Is Half The Battle

With the addition of a tool like Pinch Metrics, you’ll get a better idea of how your users are interacting with your application. This kind of knowledge can help inform your plans for further development.

Up to this point I haven’t been using any source control on my iPhone project. As Sven pointed out in a comment on my last post, if I’d had source control in place, I could’ve branched my code, performed the cocos2d upgrades described previously, and merged the changes once they were successful. Instead I created an archive of the project’s state at the time.

Source control is the better solution. I’ve already had a couple of those “how do I un-break this?” moments where being able to revert changes would have been helpful. Let’s bring some control to that code.

A Plethora Of Choice

Today’s developer has many options available when considering source control solutions, rom the old-school options of RCS and CVS, through to today’s Mercurial and Git. I’ll be using Git for this project, as I already have some experience with it and I have an account at GitHub. I’ll be using GitHub to host the master repository.

Unfortunately there isn’t any integration of Git into Xcode. If you want to have that integration, then Subversion is the tool for you. Hopefully by 10.7 we’ll see more options (or a plugin system) available in Xcode. This doesn’t bother me too much, as I’m rather fond of my terminal windows (I keep Terminal in my dock).

Hub-a Hub-a

The folks at GitHub have made it extremely easy to work with Git. As I’ve already got an account there, I created a new (private, sorry folks) repository. GitHub then presents the steps required to get started with the freshly minted repository. These steps are fine for most projects as-is, but when working with Xcode there’s a bunch of stuff we don’t want to store, such as build output, and some other files need to be treated in special ways. I created a .gitignore and .gitattributes files based on the content at Shane Vitarana’s blog.

Once these additional files were in place, I initialized the repository, added everything to it, and did a first commit followed by a push to GitHub. Mission accomplished!

You don’t need to use GitHub by any means, but I like the tools and web view they offer. The important thing is having your code in a repository.

While I’m making good progress with my project, I’m still far enough from completion that I don’t mind trying out bleeding edge versions of the libraries I rely on. In that vein, I’ve upgraded my game to use the cocos2d 0.9.0-alpha library that was announced a few days ago. Here’s my upgrade story.

Do No Harm

First things first, make a backup of the project. In case of emergency, it’s easier to revert the processes undertaken. I simply made a tar file of the project directory and then gzipped it.

Excise The Old Tissue

I deleted the ‘cocos2d’ directory inside my “cocos2d Sources” group of classes (I’d create the project using one of the cocos2d templates). When asked, I told Xcode to move the files to the Trash, not just delete the references.

Introduce The Transplant

Next was copying in the new ‘cocos2d’ directory from the 0.9.0-alpha tarball into the place the old version of the directory inhabited. I stated I wanted to copy the files, not just references, and that I wanted them added to the ‘cocos2d libraries’ subproject.

Administer The Anti-Rejection Medication

At the bottom of the new ccConfig.h file is a commented out line that creates a CC_COMPATABILITY_WITH_0_8 flag. This is required initially, and will make cocos2d create stub classes that use the 0.8 naming conventions but flag their use with deprecation warnings.

Move to Intensive Care and Observe The Patient

Now that the new files are in place and prepared, it’s time for a clean and compile. The result: a whole bunch of warnings as expected, but also a handful of errors. Errors are bad.

Fortunately, all the errors were the same – the compiler was complaining about the lack of a TargetedTouchDelegate protocol. This has been renamed CCTargetedTouchDelegate, so that change was applied liberally through the header files, the compile was fine, but the linker hated me. Turns out that the addition of the files to the ‘cocos2d libraries’ subproject was a mistake. With that checkbox unchecked, the linking went fine.

Fool Me Once…

Okay, so I really wanted to have my cocos2d folder live within the subproject build, not the main project. I deleted that new cocos2d directory again, and before adding it back I set the active project to be the ‘cocos2d libraries’. When I copied the files back into place, I was given the choice of making them exclusively part of that target, and did so. Then I set the active project back to my app, updated ccConfig.h again, cleaned the project, and compiled again. All good.

Removing The Stitches

The setup was all corrected, now I needed to deal with the warnings. Most of these simply required the addition of the new ‘CC’ namespace prefix. A few class names had changed completely though:

• TextureMgr is now CCTextureCache
• AtlasAnimation is now part of CCAnimation
• AtlasSprite is now part of CCSprite
• AtlasSpriteManager is now CCSpriteSheet

Where the class name had changed, there were a few method name changes to go alongside. Animation changes were slightly more involved, but not significantly so. My code now compiled without any warnings. All done, right?

Fool Me Twice…

The last step was to re-comment the line in ccConfig.h that enabled 0.8 compatibility. A clean and compile later, and there’s a ton of errors again! Looks like not everything has a deprecation message yet. These classes included Director, TouchDispatcher, and some animations. The fixes were all class renames, and then it was done.

A Simple Operation

All in all, this was a pretty simple feat to accomplish, though I got a lot of help from the upgrade guide and the community forum.  The cocos2d library is great and I look forward to seeing what new functionality the 0.9 series will bring us.

As I mentioned in passing in my previous post, I’ve started doing some iPhone development again. Last time I developed an application for playing soundboards (ignore the Flash-specificity) on the device, and creating them via a web application. This time, I’ve decided to create a game.

The cocos2d-iphone library seems to be the best option available for creating two-dimensional games. It’s been proven in production games many times, and several of the most successful iPhone games have been developed with it. The latest distributions include built-in support for a couple of physics libraries, Chipmunk and Box2D.

My game doesn’t use gravity (the core mechanic is a top-down tower defence thing), but physics libraries offer some useful characteristics that have made my game easier to develop.

What a Creep

Tower defence gameplay takes place on a grid. Two points in the grid are occupied at the start of the game – one is the location from which the creeps (bad guys) will start, and the other is the destination they want to reach. The player can place towers anywhere on the grid to shoot at the creeps and impede their movement, so long as the creeps can still reach the destination. Creeps will spawn from the start point at intervals.

The dynamic layout of towers in the grid means that the creeps must be able to figure out the optimal path to their destination. There is a standard algorithm for doing this called A* (and Alexander Bussman has done all the heavy lifting with some great sample code). This pathfinding algorithm tells me which direction the creep should move in next, but it doesn’t manage the movement itself.

I didn’t want to have to track the location of each creep all the time, so I decided to use chipmunk to manage the movement of the creeps. With chipmunk it is very simple to define a speed vector for each object in the game space. I can also define a number of other characteristics for the object, such as the shape of its body (the area I state it displaces in the game space), and a “collision type” that tells the engine what kind of object it is. I can also write functions than handle collisions between different types of objects, so they are handled in various manners.

Now that the creeps have a “physical presence” in the game world, I needed to be told when they got to interesting points in the map (i.e. places where they might have to change direction). I created phantom bodies in the game space that the creeps would “bump into”, and associated the two collision types of the creeps and the phantoms with a callback function. When the function is called, I make the creep recalculate its path to the destination square on the grid and change direction if needed. For the purposes of the physics engine, I ignore the collision.

Bang Bang, Shoot Shoot

I decided early on that I wanted the towers to target a single creep while it remained within range, and that the bullets should home in on that creep. Unfortunately I can’t use the physics engine to find the collision between the bullet and the one creep that its targeting, but chipmunk does make the homing very simple.

By defining a location of the bullet, I can calculate the current distance vector between the bullet and its target. I can then set the velocity of the bullet to have the same direction as the distance vector, and even apply an angle (just because an object is moving in a particular direction doesn’t mean it’s pointing in that direction).

With each tick of the game state I check all in-flight bullets to see if they’ve hit their targets. If so, I apply damage as appropriate and remove the bullet from the visible gameplay. If the target has disappeared, the bullet is also removed.

An Easier Life

While I may not have used the chipmunk physics engine as intended, having access to its large feature set has been valuable in simplifying my code development. Admittedly, sometimes the documentation is lacking, but there are many examples online explaining how it can be put to use.

It seems that Apple can’t catch a break these days, at least as far as their developer community is concerned. As someone who is actively developing an application (again) for iPhone and iPod Touch, the issues around the existing application approval process concern me greatly.

Below is a rehash of some comments I left at Fred Wilson’s blog.

Today, the vast majority of iPhone developers are targeting the App Store as their only distribution channel. Though Apple has made an “ad-hoc” distribution channel available, it is unwieldy and extremely limited in its scope. Some developers have attempted to use this channel to circumvent the App Store; the reaction from Apple was to further limit the ad-hoc channel to the point that it was no longer viable for mass distribution.

While many commenters feel the whole idea of having an approval process is wrong on a moral level (“my customer’s device, my customer’s choice”), it does provide some value. In summary, some of the approval process is automated (“is this application only referencing public API methods?”) and some requires human input (“does the application meet our UI guidelines?”).

Given that some of the approval process is automated, I believe Apple should execute the automated steps as early as possible – right after the application has been uploaded. There is no value in a developer sitting around for two weeks for their program to be approved, only to find out that they’ve been rejected because an automated test has finally been run. The sooner this rejection reason can be communicated, the better.

Looking beyond this automation, there is the question of distribution. Currently Apple controls all distribution of applications for their mobile devices. I think they could open this up to some extent, while still maintaining control over certain aspects of code quality.

When developers submit their applications for approval, they could request an approval for “independent distribution”. Such applications would be required to pass the automated parts of the existing approvals process, and would probably have other restrictions (i.e. no access to StoreKit, no Push Notifications, possibly no network access). Passing applications would be signed by Apple as having been approved for independent distribution and could be installed via iTunes or directly through Mobile Safari and a slightly updated version of the existing App Store program on the iPhone.

If the developer chooses to only have their application approved for independent distribution, it is not put into the queue for human approval. This moves simple applications out of the extended approval process. Apple could introduce additional timing incentives for developers to start using this approval option. For instance, if the developer wants both forms of approval, they don’t get the signed binary for independent distribution until the full App Store approval process has been completed.

At the time of writing, the approval queue is approximately two weeks long (“96% of applications are approved within 14 days”). This queue is part of a workflow that takes a developed application and eventually makes it available to users exclusively through the App Store. By introducing some automation and other limiting criteria, Apple could create a better experience for their developer community and enable new distribution channels.