Github for one...

While I'm doing client work, I always use version control software to keep all the different files locked away and secure.  With PeopleSoft, there are tens of thousands of files, so it's kind of important not to loose track of them.  With my own iOS development, however, I've always avoided using git or the like as I didn't see the benefit.  After the game hack at iOS Dev UK, I've changed my tune and now think it's a great idea!

My approach was always to do manual version control.  I'd just have a bunch of whole directory copies of a project and every now and then I'd clone the whole thing.  As it was just me working on these projects, this worked fine.  If ever I had a slip up, I could just go back to the last version in the backup directory and manually sort things out.

The one issue I had with this was switching between my Mac Book and my Mac Mini.  It was always a bit hair raising when I copied the whole directory from one machine to the other.  The first step was usually to delete the whole thing on the target machine, which was always scary.  I did try setting up a local server, but this never quite seemed to work and was a bit annoying.

During the game hack, however, our team relied heavily on Github to share all our source code.  Previously, when I did use git, it was through the git built into XCode.  That worked OK, but I found I spent more time battling it than using it properly.

This all changed when I started using the stand alone Mac client.  Sure, it has it's flaws, but OMG, when it works, it works well!  With a few button press, you can commit your latest changes, backup the whole project to the web, then distribute it to all your machines.  WOW.  Until I saw this in action, I never saw the point of this type of version control, but when you add in off site cloud backups and internet based distribution, it's magic!

To get things working, you need the Github client from mac.github.com and a Github account.  The slight catch is that the free account only allows you to create public repositories.  To create the private ones that you really want, you need to subscribe.  After using it for a week now, it's definitely worth the $7 a month I'm paying.

As I mentioned, a great feature is that all your code is backed up to the cloud.  This is as huge comfort if you're worried about off site backups.  It's also an amazingly useful way of looking at your past commits and hence prior versions of your code.  Doing the same within XCode can be a bit of a pain, but the simple web interface allows you to look at your code in a really simple way.  Great stuff!

There are a few annoyances with git.  Sometimes it adds things to your project it shouldn't - things like the position and layout of your windows and other project type preferences.  Merging branches can also be a pain and can lead to the corruption of the project file.  This is easily fixed using a text editor, but it's a bit of a pain.  A few googles on using .gitignore sorted most things out, so it's not a show stopper.

In the space of a week, I've gone from wondering why you would bother with the overhead of version control to using it regularly to actually make my work easier.  Great stuff!

Using UIKit with Cocos2d - iOS and Mac!

I was at the excellent iOS Dev UK conference last week and a few people talked about combining the power of cocos2d with the features of UIKit.  This made a lot of sense to me.  Cocos2d is great at graphics and such, but it's a real pig for certain basic behaviours.  For example, I've been putting off adding a feature to my latest game that allow you to edit the name of the players.  The thought of writing a text field control from scratch was a bit daunting.  I now know I can just use a UIKit edit box and avoid all the heavy lifting!

Adding UIKit controls is surprisingly easy.  The cocos2d app Director sets up the screen a regular UIView to display the Open GL stuff.  All you need to do is add a child to this view, then all the standard UIKit stuff can be used.  So easy!

I'm yet to see if there's any performance hits in using this approach, but since it's only going to be used in the menu part of the game, this won't be a problem.

After getting the UIKit working, I next turned to using the equivalent Cocoa controls for the Mac.  This turned out to be a little trickier.  Unlike the iOS Open GL view, the Mac version does NOT allow any child views to be added to it.  D'Oh!

After hunting around for ages, I eventually scraped together some code to do it.  Basically, it involves creating a new NSWindow with a NSView inside.  You then add this window as a child of the root window.    I place it at the top of the view stack and make it transparent, so the user doesn't realise what's going on.  All your Cocoa controls can then be added to the NSView.

There were a few gotchas with this.  First of all, if you add a Window without any chrome (window title, open/close etc),  OSX handily disables all edit functions!  That took me AGES to work out what was going on.  To get around this, all you need to do is sub-class the Window and add a single function that tells OSX to allow editing.  So bizarre!

I'm still working out a few kinks with this approach, but I'm now able to use standard OS controls for editing text, which is amazing. I'll post a complete project with examples on github once I get a nice clean project running.