It turns out that Apple actually provides a tool to help you do just this, but it’s kind of hidden away and documentation is relatively sparse. Fortunately, it’s pretty easy to use. When you run it, it’ll output a structured plist showing all of your encoded objects, their restoration identifiers, and restoration class information. Here’s a step by step guide.

1. Download the tool

Head over to the Apple “Downloads for Apple Developers” site and expand the restorationArchiveTool for iOS download. You’ll want the restorationArchiveTool.dmg file right at the bottom of the list on the right.

Open the dmg, and drag the restorationArchiveTool binary out to somewhere you can easily access it. I placed mine in my ~/bin directory.

2. Find your app’s Library directory

Next, you need to know the location of your app’s Library directory in the simulator. This is where the restoration data gets saved, which you’ll inspect with the archive tool. The easiest way to find this is to add a line to your app delegate’s application:didFinishLaunchingWithOptions: (or via a breakpoint). Something like this should do the trick:

Objective-C:

NSLog(@"Library: %@", [[[[NSFileManager defaultManager] URLsForDirectory:NSLibraryDirectory inDomains:NSUserDomainMask] firstObject] path]);

Swift:

print("Library: \(FileManager.default.urls(for: .libraryDirectory, in: .userDomainMask).first!.path)")

The path should get logged out to the console when your app launches. It’ll be something like this:

/Users/bob/Library/Developer/CoreSimulator/Devices/1FF2D964-C615-499E-B1D0-8A7DF7343AE5/data/Containers/Data/Application/D6FE3A2C-9553-4270-8262-A94376EF4E5B/Library

3. Get some data

This part’s simple. Launch the app in the simulator, navigate to the part of the app you’re interested in, send the app into the background, and stop the app in Xcode. If you open up the library folder you found in the last step, you’ll see a folder named Saved Application State. Within that, you’ll find a data.data file.

4. Run the tool

Now you need to run the archive tool and point it at the data.data file you just found. In Terminal, enter the following command, but switch out the location of your restorationArchiveTool binary and your app’s data.data as required:

~/bin/restorationArchiveTool --plist --structured -o output.plist /path/to/your/data/file/data.data

And you’re done! You can then open up the generated plist in Xcode. Amongst other things, you’ll see a list of top level objects, keyed by their restoration identifiers. You should notice that the restoration identifiers form a path based upon your view controller hierarchy. You can expand any object to see any extra data it’s encoded.

At the bottom of the file, you’ll find a list of restoration classes used by each of the encoded objects.

If you’re having some problems with state restoration, then at the very least being able to see this information can give you some hints about whether your issue is with encoding or decoding. Good luck!

Enter Codify. Codify is a new iPad app that lets you create simple games, prototypes and simulations directly on an iPad. You write code in the Lua language using a fantastic code editor (more on that later), with an API that’s very similar to Processing. You can then run that code straight away; play your game, experiment with your prototype, tweak your simulation. It’s fast, easy, impressive, and fun.

Running and debugging

When running your game, you can specify parameters (for example, a character’s speed or size) which show up as sliders in a debugging pane on the left hand side of the screen. You can then tweak those parameters as you play, and observe in real time the effect they have on the game. It’s very neat. You can also watch variables and print information out to a console. Games themselves run very smoothly (unless you write them badly, of course!) and look great. You can pause, resume, or reset your game state whenever you like. You can also flip back to your code with just one tap.

Help and examples

The app comes with a whole heap of examples, from the basics of using the provided graphics functions to clones of games like Doodle Jump, Snake, and Pong (the latter I wrote myself). The code editor also comes with a nicely presented documentation viewer which provides excellent help on graphics functions, the Lua language itself, parameters, multitouch, sounds, using the iPad’s accelerometer, and more.

To see some of the Codify examples in action, check out the following YouTube videos:

• Bit Invader
• Lua Jump (Doodle Jump clone)
• Dungeon Roller
• Ping (Pong clone)

The code editor

The code editor has clearly had a lot of thought and polish put into it. It has a lot of things you’d expect from an editor: syntax highlighting, line numbers, multiple files (with tabs to switch between them), and a function browser. But it also has a slew of features designed to ease the task of programming on a touchscreen device:

• For methods that take a colour as a parameter (RGBA values, for example (255, 150, 99, 255)), you can simply tap on the parameter and a colour wheel appears in a popover allowing you to choose a colour with touch alone.
• You can tap and hold on any number and slide your finger from left to right (or vice versa) to increment / decrement the number without typing.
• A row of custom keys above the onscreen keyboard provides shortcuts for common tasks: tabbing, access to documentation, inserting symbols / punctuation, and more.
• Codify includes support for displaying sprites (images) and comes bundled with a number of high quality sprite packs from Lost Garden. Similarly to selecting colour parameters, you can tap a sprite parameter and select your sprite from a nice popover without the need for any typing.

Check out my Flickr photo set for a couple more photos showing the Codify interface. I’ve also put together a quick YouTube video showing some of its functionality in action (embedded at the bottom of this post).

The Lua language was deliberately chosen for Codify because it has a rather ‘wordy’ syntax, which fits nicely with the iPad’s onscreen keyboard. It means less switching to the ‘symbols’ keyboard, and less frustration for the user. The Lua runtime is also extremely light, which helps keep things snappy.

An introduction to programming? - a brief aside

I think that Codify could shine as a tool for teaching programming. I’ve long lamented the apparent increase in difficulty for kids (and adults alike, I guess) to get started with programming these days. I began coding on a BBC B in BASIC. Back then, you turned your computer on and you were presented with a flashing prompt, into which you could just start typing your code. Commercial games weren’t too advanced, so it was entirely possible you could get at least close to making the sorts of things you played yourself.

These days, where do you start? If you have a Mac or Linux machine, chances are you have something like Ruby or Python built in, so that’s fairly easy to get going with. If you’re on Windows, you’re left to install something yourself. You’ll also likely have to install some kind of text editor and work out how to use a command prompt (not a bad thing to do at all, of course, but it’s another barrier to entry). And then you’ll have to find some kind of games or graphics libraries and learn how those work. And then you might be able to have a go at learning a language and making a simple game. It’s a lot to get through and a lot of opportunities for a newcomer to lose their enthusiasm.

We’re now finally starting to see some potential solutions emerging on the web. For example, Processing.js (a JavaScript port of Processing) and Sketchpad.cc (which lets you just start coding with Processing.js in your browser). Codify is very much like these solutions, but built specifically for iPad and a touch interface. From now on, somebody who wants to get started with simple programming and games may just be able to search the App Store for ‘programming’, install Codify, and have a go; perhaps starting off modifying some of the examples and observing the effects their changes have in real time. It may not be as easy to a newcomer as I’m imagining, but it sure seems a lot simpler to me than what we’ve had in recent years.

Wrap up

Codify was created by Simeon Nasilowski of Two Lives Left and will be launching on the App Store on Wednesday 26th October for £5.49 ($7.99), which I think is great value for everything it offers. It’s a high quality package that finally lets you code on the iPad, and it does so with style. I highly recommend checking it out if you enjoy programming or think you’d like to give it a go. I’d be really interested in seeing what you create with it!

I’ve also posted a video to YouTube showing some of Codify’s features in action:

A common coding/computer science task is to swap the values of two variables. In some languages, such as Java, one may start by creating a new temporary variable. For example (assuming we already have two ints, x and y):

int temp = x;
x = y;
y = temp;

This creation of a new variable uses more memory, and whilst in most circumstances would be fine, it could become an issue if we’re swapping many times, for example in a sorting algorithm.

Some languages allow us to do a nice swap without extra variables, using multiple assignment and tuple packing and unpacking:

x, y = y, x

This is pretty neat, although is apparently slower than using a temporary variable.

Anyway, yesterday I discovered a third method: XOR swapping. Again, this doesn’t require the use of an extra variable, and I thought it was pretty clever (here ^ represents XOR, as in Python):

x = x ^ y
y = x ^ y
x = x ^ y

Neat, huh? It’s fairly simple to see how it works if you simply walk through the steps. Let’s swap x = 7, y = 9:

x = 0111
y = 1001
x = x ^ y = 1110
y = x ^ y = 0111
x = x ^ y = 1001

Apparently this method is quite commonly used in embedded assembly code, however you won’t find it appearing much in code on a desktop computer. It usually is slower to compute than using temporary variables, as most processors attempt to execute commands in parallel - and of course, each of these instructions depends upon the previous result, so they must be executed sequentially. Still, it’s a nice thing to know.

The short version: it seems that if you’re trying to save memory then XOR swap or use multiple assignment, otherwise if efficiency is an issue, use a temporary variable.

My own first solution was Python-based, and a fairly simple one:

for i in range(1,101):
    if i % 3 == 0 and i % 5 == 0:
        print "FizzBuzz"
    elif i % 3 == 0:
        print "Fizz"
    elif i % 5 == 0:
        print "Buzz"
    else:
        print i

Obviously it’s not in a function or anything, but I just wanted to do it as fast as possible. Shortly afterwards, I realised that line 2 could be simplified by changing it to:

if i % 15 == 0:

Because of course, if a number is a multiple of 3 and 5, then it must be a multiple of 15.

Here are a couple of nice alternatives (ideas courtesy of Dave, although re-written by me because we didn’t save them). First, writing FizzBuzz as a iterator:

def fizzbuzz_generator(n):
    for i in range(1, n+1):
        if i % 15 == 0:
            yield "FizzBuzz"
        elif i % 3 == 0:
            yield "Fizz"
        elif i % 5 == 0:
            yield "Buzz"
        else:
            yield str(i)

for result in fizzbuzz_generator(100): print result

Then, a simple function to calculate the correct fizz/buzz, combined with a list comprehension to create the result (man, I love list comprehensions):

def fizzbuzz(i):
    if i % 15 == 0:
        return "FizzBuzz"
    elif i % 3 == 0:
        return "Fizz"
    elif i % 5 == 0:
        return "Buzz"
    else:
        return str(i)

print "\n".join([fizzbuzz(i) for i in range(1,101)])

Finally, here are two neat little Ruby one-liners, taken from the comments of the original FizzBuzz article. I hope the authors (Brendan, and Brian respectively) don’t mind me reproducing them here:

puts (1..100).map{|i|(s=(i%3==0?'Fizz':'')+(i%5==0?'Buzz':''))==''?i:s}

puts (1..100).map{|i|i%15==0?'FizzBuzz':i%5==0?'Buzz':i%3==0?'Fizz':i}

How neat is that? Anyway, as I said, feel free to leave your own solutions below.

I love to code. Since a young age (I think I was about 7 when we first got our BBC B, and I would patiently tap BASIC code into the blinking prompt from childrens’ books about programming), I’ve loved to write programs. I read somewhere recently (unfortunately, I forget where) that it’s not the act of coding itself we love, but rather it’s solving problems that we love. I think that’s one reason I like learning new programming languages, as it allows me to solve problems in different ways.

A while back, I came upon the FizzBuzz idea. In short, it’s a simple exercise for employers to give to potential employees at interviews; a very simple exercise, yet one that someone will only be able to answer quickly if they ‘get’ programming. A suggested FizzBuzz problem is the following:

Write a program that prints the numbers from 1 to 100. But for multiples of three print ‘Fizz’ instead of the number and for the multiples of five print ‘Buzz’. For numbers which are multiples of both three and five print ‘FizzBuzz’.

I invite everyone reading this to have a go now - time yourself, and see how quickly you can do it. Unfortunately, I only timed myself by looking at the clock, but I was glad to have completed it in under a minute. Apparently this shows I can code:

Most good programmers should be able to write out on paper a program which does this in a under a couple of minutes.

Want to know something scary? - the majority of comp-sci graduates can’t. I’ve also seen self-proclaimed senior programmers take more than 10-15 minutes to write a solution.

That is a scary thought, but I expect it’s almost certainly true.

So, this sort of simple problem excites me - I can work out a solution, and then try and improve that, perhaps. Myself and Dave spent a fair while earlier today trying to come up with more and more sophisticated solutions. And y’know what? It was fun!

On a similar note, I thought I’d mention a website that I found a while back (thanks to Matt Gwynne) that might be of interest to anybody else who enjoys these kind of problems. Project Euler is “a series of challenging mathematical/computer programming problems that will require more than just mathematical insights to solve”. It contains a list of (at the time of writing) 195 mathematical problems, and the aim is to write code to solve them. You can then put in your answers, the website will tell you if you’re correct, and check them off the list. Great fun, and it’s neat to see some of the interesting solutions that people come up with (and the range of languages they use!). Hooray for being a geek! \o/