IOS: TrackMe Progress

Had a little time over the weekend to add some navigation to the app in the form of different menus and-the-like. Quick video below (27 secs) showing the flow of the app in the simulator.


iOS: TrackMe

A while back I posted a couple of entries about Swift (here and here) and I stated:

Despite my initial misgivings of Swift (these posts have been on the negative side), I know I’ll end up developing with it.

Well done smarty-pants me! I’m now actively using Swift for some iOS development.

I always like to approach using different bits of tech in a way that is either of some use to me personally (see LearnAWord), or just a bit of a laugh (see ILoveTwitterLamp). This particular app is mostly in the first camp, but a little in the second.

Being a biker, I like to go for rides and explore the countryside a bit – have a look at a map and just pick a general direction to ride in. I’ll put my proper Garmin GPS in my bag as a “just-in-case” measure, but it’s definitely more fun not having some device doing all the navigation for you sometimes. Of course this all goes out the window when you have somewhere specific to be 🙂

Often it’s annoying to come back from a ride and realise you’re really not sure where that great little off-the-beaten-track section of road was, or maybe you can only remember the route again if you were riding it, rather than being able to skip a bit out and head straight to the good stuff. This led me to start developing a little tracking app I can set running on my phone that stores my GPS locations as I ride – and I can view the routes I’ve taken (See the red line in the image below, of a route being simulated in the iOS simulator).

TrackMe Prototype showing a polyline being rendered at the tracked coord points.

TrackMe Prototype showing a polyline being rendered at the tracked coord points.

Admittedly, I can view a large amount of my route history on my normal GPS device, but I can’t really do anything with that data, other than view a cruddy pink line on a cruddy little screen. I have tried getting the data off the SD card, but even the export menu is next to useless.

With this system I can track where I go and (ultimately) share this data via iCloud docs too I hope. This means I’ll be able to create some sort of “Desktop viewing app” for all the routes I save on my iPhone. Of course I’ll add tagging for points of interest and the like to the app too.


You may be asking why I don’t just use my iPhone as my GPS unit on my motorbike. Simple answer: I live in the UK, Manchester no less. It rains here on the majority of days (I’m not kidding, see this post on the Guardian!) and I just don’t trust waterproof cases with my very expensive phone. I do however trust my specifically engineered Garmin Motorcycle GPS unit, that I’ve inadvertantly dropped-kicked across many a carpark, to do the job

Unity: SimpleGizmoDisplay

Recently I’ve found myself using a lot of Gizmos in Unity , to such an extent that it became worthwhile to have some quick and easy component to re-use rather than scripting up the same OnDrawGizmos call repeatedly.

So here it is, SimpleGizmoDisplay. It currently supports Cube, WireCube, Sphere, WireSphere, Icon and Line. It’s quick and bare-bones, but it can save a lot of time in pretty short-order.

The options available in the Inspector for SimpleGizmoDisplay.

The options available in the Inspector for SimpleGizmoDisplay.

Do with it as you wish!

SpectrumShock Redux

So many times I’ve started posts on this blog by apologising for not updating for a while. So why break a habit? Here’s another! 🙂

Over the past few days I’ve been working with Tim (whom I’m working with on the Dungeon Runner) on some rapid prototyping of a (sort of) new version of Spectrum Shock (a game I developed several years ago using Torque2D). This time I’m working in Unity and it’s coming together at a very rapid rate as you can see below.

I started on Thursday evening, and this first video was from Friday

This video was from Saturday.

You’ll notice in the second video that the environment is “tipping” around, this is matching the orientation of the iPhone6 (With relevant scaling) that I’m playing it on. It really adds quite a bit to the overall feel of the game.

I’m using Aron Granberg’s AStar project which you can find here:

DPSDisplay released on Curse

The WildStar Addon I mentioned a while back now has a project page on Curse (as I write I’m just waiting for the download itself to be moderated).

Currently it supports all the features as shown in my last post on it, but I plan to add saving and customizable time-windows etc in the future. It’s “fully functional” now, so it seemed worthwhile to release it now rather than waiting.

On Curse it is found here.
And you can also grab it from GitHub here.


Update July 11th

D’oh. Turns out there was a bug on Curse’s end with file uploads (I confirmed one they knew about and found fresh one for another for them – I bet they love me…) that meant the files weren’t downloadable. I had no idea as I was off on holiday in Turkey. Thankfully all is sorted now, and 40 minutes later I’m seeing downloads already!

Thoughts on Swift (Part 2)

This is part 2 of my “Thoughts on Swift” post. See part 1 here

Immutability inconsistency

Swift has some really weird behaviours when it comes to what counts as immutable and what doesn’t. The following twitter post explains and demonstrates it very well. Note: These are *designed* behaviours and are functioning as expected as per what is in the language guide. Ugh…


A Couple of Quick Additional Oddities

  • Enumerations can have methods etc. Simply feels a bit odd to me, but probably ultimately very useful given the right circumstance. I expect abuse of this feature to be prevalent 🙂
  • Swift has the concept of Extensions (Categories in ObjC) and although I use features like this, I always feel like I’m maybe breaking the second principle of SOLID, namely, “Open for Extension Closed for Modification”. I mean this in the sense that when you are adding functionality to an existing class without deriving from it, you ARE modifying it and not extending it. i.e. The *original* class now has a different set of behaviours to what it had before – calling it an “extension” is a slight of hand.


A key part of any language is not so much to do with the syntax and features that it offers, but more to do with the adoption of said language by developers. A particular language can live or die depending on what libraries are available for it. This concept spreads to toolsets as well as languages, just think of the many “out of date” scientific tools that are still in common use. Sometimes systems become so large or so “embedded” in a particular industry/market that it requires seismic shift in that particular industry to jolt it into action to update and/or move away from it.

Despite my initial misgivings of Swift (these posts have been on the negative side), I know I’ll end up developing with it. The primary reason for this is that I can well imagine ObjectiveC is going to have little-to-no real development on it moving forward. I however don’t anticipate anyone bothering to do rewrites of their ObjC libraries to Swift, as Apple have made it so there is neither a benefit nor a penalty for doing so.

This is smart and should drive adoption of Swift at a pretty decent rate, at least amongst developers inside the Apple ecosystem already. It doesn’t do much to entice more in I don’t think.

I think, for a while at least, I’ll probably sit on the side and watch Swift develop before launching into it “full-on”. For the moment, let’s enjoy seeing recruiters starting to post job ads asking for 3+ years Swift experience eh? 🙂