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? 🙂

Thoughts on Swift (Part 1)

WWDC, it always serves something up for you to think about, worry about, be excited about (or complain about?). This time around we got the unexpected news of a new language being released, Swift. Naturally I was interested in this, so I’ve done some reading on it and summarised some (This is heavily truncated compared to what I initially wrote) my thoughts below.



I have to admit, I was rather surprised to see a new language being announced. I still am to an extent. I’m not really sure why Swift exists at the moment. I mean, is it a tacit admission that Objective C has faults and it’s easier to develop something from the ground up rather than try and “morph” ObjC into something new? Or is there something else going on here?

A friend of mine posited the following as a potential reason for the language’s existence:

[Swift is] Apple’s apology for Objective C’s syntax.

He might have a point… ObjC certainly can feel like an alien environment when you first approach it, unless you happen to have a very particular path of experience. However, given that ObjC supports standard C syntax (duh) and you can run your code through as Objective C++ to allow line-by-line ObjC and C++ it feels that there is clearly space in both the language and the compilers to support further morphing of ObjC rather than something entirely new.

There has been a fair bit of progression in Objective C in recent times, obviously the presence of iOS has accelerated this immensely, the growth of the OS X market has played its part too. Prominent areas of development are the inclusion of code blocks and technologies such as ARC (Automatic Reference Counting) – these have both made their way into Swift in one form or another.


Pros and Cons

Swift simplifies a lot of common tasks, and it does them in a syntactically sensible and logical way. Iterating through ranges by using the Range operators in (1…5) is a welcome addition. Implicit typing is certainly part of the coding zeitgeist and for when you still need explicit type declaration, you do it in a JS-style way var 5.5 : float.

Optional chaining as a way of avoiding forced unwrapping is a great way of slimming down code. As daft as it sounds I’m actually quite happy that they used a question mark as the way of marking this up too, it feels “correct”. What I don’t like is how Swift is stricter on what counts as a boolean return (e.g. for use in an expression for an if statement) than what other languages would be. By way of an example, this will produce a compiler error:

let i = 10
if i
// code here

I get the logic in forcing things to be a boolean response, I just don’t like it.

Swift still doesn’t solve the main problem that has stopped ObjectiveC pushing itself into the top-tier of languages in terms of adoption, it still locks you into the Apple ecosystem. In fact, not only does it not succeed in solving this problem, it doesn’t attempt to solve it. It’s locked itself into the Cocoa frameworks tightly.


See part 2 of this post here.