Early MacOS OK and Cancel buttons

From mechanical to digital

In the pre-digital, mechanical world, buttons as we know them were pretty rare. Toggling switches were much more common. But when buttons did exist, by necessity they would have a direct physical connection to the thing they were acting on and usually some immediate effect. Unfortunately in the digital realm this relation no longer holds, and that’s what make it so easy to misuse buttons in a user interface.

UX – “Press me”

So, what experience do users have of the buttons in your application’s UI?

The biggest issue is: how will they know the button’s true purpose (without pressing it to see)? Will it open a file or delete the contents of your hard disk? In the wrong hands it could do either of those things, or none. Your only clue is the label. In much the same way as the “drink me” and “eat me” labels in Alice’s Wonderland: the appearance of the thing isn’t congruent with its effect.

The easy way out

Unfortunately the very non-specificity of a button is what makes it so easy to over-use by inexperienced UI creators. If they haven’t thought carefully about the specific operations their users are performing, the quickest thing to do is have pressing a button be the action that invokes whatever functionality you need.

The Apple human interface guidelines stress that you should use a verb to indicate what your button will do, and this is a useful guideline when deciding whether to use them at all. You should only use a button to perform a single well-defined action in a context where the corresponding noun is clear. If it’s not granular enough, maybe you need to break things down into smaller tasks. Think of examples like ‘Cancel’ (whatever operation is underway), ‘Close’ (the document you’re working on).

So how did we get to the current state-of-the-art in buttons?

A visual history

The early years

BIOS-style buttons

OK and Cancel from DOS Word

NeXTStep goes kinda 3D

Round rect

Early MacOS OK and Cancel buttons

OK button from Windows 1.0 circa 1990.

Windows 3.0 OK button circa 1990

The Borland years

Borland-style OK and Cancel buttons

MacOS 8/9 buttons

Shiny!

Nowadays things are getting serious. We have graphical processing units that can generate squillions of pixels per second even on a run-of-the-mill machine. What shall we do with all this processing power? Let’s make our buttons shiny! And transparent. And with a gradient and specular highlight. And let’s make them pulse.

However shiny our buttons get, remember that they’re not a catch-all for every action in your user interface. The golden rule is to use the most specific control that maps closely to the operation that is occurring from the user’s point-of-view.

Screenshot of the finished lava lamp effect

A bit of background – shaders

OpenGL ES 2.0 introduced the idea of programmable shaders to replace the ‘fixed function pipeline’ of previous versions. What does this mean? You can write little programs that are invoked to modify vertices (points in the model) or fragments (pixels on the screen). Other types of shaders have been introduced in other versions of Open GL for desktop platforms, but vertex and fragment shaders are your limit on iOS/Open GL ES 2.0.

The shader programs are written in a C-like language, and then compiled (at app run-time) into code that can then be run directly by the GPU. That means they get executed on the highly data-parallel graphics hardware, running the same code on multiple lightweight ‘threads’ (not your run-of-the-mill OS threads).

It’s possible to write shader programs that get quite complex. You can define and call your own functions, use common functions – for helping with things like vector manipulation and linear interpolation – and make use of built-in OpenGL variables to read and write key data. Here’s an example of getting the length of a 2D vector, the straight-line distance between 2 points.

float dist = length(vec2(balls[i].xy - p));

That code also demonstrates the use of swizzling; a concise way of accessing and mapping elements from one matrix or vector to another. Specifically balls[i] is a 3D vector with x, y and z components and we’re creating a 2D vector from only x and y.

Make a quad and paint it

In the case of our app, we’re not doing much in the vertex shader, we’re just going to pass vertices through unchanged. All we need to do is draw a single, screen-aligned quad (consisting of 2 triangles), and then “paint” it using our fragment shader.

Drawing a quad with a triangle strip

By using an orthographic projection we can remove the need to take any perspective adjustments into account and just use the screen width and height for the size of the quad. Using a combination of UIView and GLKit, we can easily create the project matrix we need:

float w = self.view.bounds.size.width;
float h = self.view.bounds.size.height;
_projectionMatrix = GLKMatrix4MakeOrtho(-(w/2), w/2,
-(h/2), h/2,
0.0, 1.0);

I also set the contentScaleFactor on UIView to 1.0 – it defaults to 2.0 on Retina devices – in order to reduce the actual number of pixels that get drawn.

The meat: The metaballs

So now that we’ve got our quad on the screen, what are we actually going to draw into it? There are lots of metaball tutorials and descriptions around, this is a very useful one. With a little inspiration from this stackoverflow answer, I got it coded up in GLSL:

Here I’m also setting a graduated colour in the fragment shader by returning the level rather then simply a boolean “in or out” flag. This gives a pleasing ‘glow’ to the blobs.

Calculating the pixel value with one metaball

This isn’t a particularly efficient implementation. It gives me a solid 30 FPS on an iPhone 4S or iPad 2 with 5 balls, but increasing that number quickly starts to impact the performance. I’m sure there are some optimisations that could be made (e.g. marching cubes), but that wasn’t really what this experiment was about.

Debugging

XCode provides excellent support for debugging OpenGL apps; albeit only on an actual device, not the the simulator. While your app is running, look for the somewhat hidden button or select Product|Debug|Capture OpenGL ES Frame, it will grab the state of your app and let you explore all of your state at will, including the very powerful ability to edit and recompile shaders on the fly. Very nice.

You can also use View|Show Debug Navigator to see the frame rate as your app is running. There’s a good introduction to what you can do in the official Apple docs here.

The Result

It looks pretty nice, I think. I added some code to manage the balls, giving them an x, y and z (radius) direction so that they move and grow, as well as a bit of adjustment when they reach the top and bottom to make things look a little more realistic. I also added a small adjustment to the colours across the width of the display, to provide an interesting visual effect (it was originally intended to give a sheen, as if the blobs where behind cylindrical glass, but this was how it ended up instead)!

So, I’m sure most of you are just going ‘yeah, yeah, great description, but SHOW ME THE CODE’, so here it is. Enjoy.

Ever been in that situation where you (or someone else) finds that Visual Studio just won’t set a breakpoint in some source code that you’re sure should be being used? You’ll see the hollow breakpoint icon and something like ‘The breakpoint will not currently be hit. No symbols have been loaded for this document’.

The first, and most obvious, step is to make sure that a PDB file is actually being loaded at all. Look in the modules window and check that Symbol Status is Symbols Loaded and there’s a symbol file listed. Assuming there is, how can we dig a little deeper and find out what the PDB file actually contains? Remember: the PDB will only contain symbols for code that’s actually used in your binary, so that will exclude any dead code stripped out by the linker.

Of course, there are a couple of existing mechanisms to examine PDBs: you could write something yourself using the Debug Help Library (aka dbghelp) directly – a little too labour-intensive for this case – or you could use the x (eXamine symbols) command in WinDbg (or in the immediate window of Visual Studio). E.g. this will dump all of the symbols (probably a lot of them) in module testapp:

x testapp!*

Of course, in order to use a debugger to do this, you’d have to have a crash dump or live session with the DLL loaded.

Wouldn’t it be cool if there was some way of examining the PDBs offline? Well, it turns out there is, it goes by the name of DBH, it ships alongside WinDbg in the Debugging Tools For Windows package and it’s incredibly useful. It works in one of two modes: either an interactive REPL or batch mode with a single command passed as an argument.

Its target can be a running process, the PDB file itself, or a DLL file. In the latter case, and assuming you’ve got _NT_SYMBOL_PATH properly set-up, it will identify and download the symbols automatically based on the DLL identity. With the “noisy” option enabled, we can see what it does in a simple case where symbols are co-located:

C:>dbh -n testapp.exe
verbose mode on.
DBGHELP: No header for testapp.exe.  Searching for image on disk
DBGHELP: C:\Users\Administrator\dev\testapp\Debug\testapp.exe - OK
DBGHELP: testapp - private symbols & lines
         C:\Users\Administrator\dev\testapp\Debug\testapp.pdb

To dig deeper, let’s look inside the file for some destructors, i.e. all symbols containing a tilde:

C:>dbh testapp.pdb enum *~*

 index            address     name
     1            1011400 :   testClass::~testClass

But for the particular scenario we’re discussing, we’d like to see which source files are indexed by the PDB, rather than which symbols. You can do that with the src option on the command line:

C:>dbh testapp.pdb src
...
c:\users\administrator\dev\testlib\testlibclass.h
c:\program files (x86)\microsoft visual studio 10.0\vc\include\vadefs.h
...
f:\dd\public\sdk\inc\winnls.h
...

Here I’ve shown some of the files that highlight the fact that the PDB file contains the source that we built, the VC headers that are compiled into it, and the headers that have been compiled into the version of the CRT that we’re using.

So, now, given a compiled DLL and it’s PDB file, we can quickly answer the question “why can’t I set a breakpoint in file X?” by checking that the source file is actually included in the PDB.

What are they?

In technical terms, they’re an algebraic data type. I won’t attempt to precisely define that myself, because this page does a much better job than I ever could. Suffice it to say that a record type is a combination (product) of named values of other types.

For example we can take an int and a string and construct a record type like this:

type MyRecord =
    {
    foo : int
    bar : string
    }

Of course, you can then use these record types as fields in other records:

type AnotherRecord =
    {
    r : MyRecord
    x : string
    }

It might look like this is similar to using a C# struct, but there are some significant differences. For instance, record types can’t be generic like structs can, and they’re .NET reference types, not value types, although they don’t necessarily act like reference types, we’ll talk about that later.

Benefits

So why might you want to use records?

• They help to encourage strong typing. You can use tuples in some of the situations where you’d use records, but in my opinion the ability to name fields gives records the edge when it comes to code readability.
• They encourage immutability. Although (some would say unfortunately) they don’t require it, see below.
• They integrate well with other language features such as pattern matching
• They’re concise

Defining records

The syntax for defining new record types is pretty straightforward.

type MyRecord =
    {
    foo : int
    bar : string
    }

This is similar to F# class definition syntax, but notice there are no implicit (type MyRecord () =...) or explicit constructors. Records have to be constructed in a specific way using record expressions that specify all field values:

let r = { foo = 1; bar = "a" }

Note that, as you’d expect, the F# compiler will attempt to infer the type, you don’t have to declare the type of r. If there’s ambiguity in the current scope, with multiple types having the same fields you can specify the type explicitly on either side, or fully specify one or all of the fields.

// Specify type of record
let r2 = { foo = 1; bar = "a" } : MyRecord
// Specify type of function
let r3 : MyRecord = { foo = 1; bar = "a" } 
// Specify field
let r4 = { MyRecord.foo = 1; bar = "a" }

Another extremely useful feature of record types is that as well as fields, they can also include member functions, static functions, and even implement interfaces:

type Vector =
    {
    X : float
    Y : float
    Z : float
    }
    /// Member function has access to fields 
    member this.add() = this.X + this.Y + this.Z
    /// Static member, here is passed an instance as a parameter 
    static member foo2 v = v.X + v.Y + v.Z
    /// Implement an interface with members
    interface IDisposable with 
        member this.Dispose() = ()

At this point they’re starting to look an awful lot like good old-fashioned OO classes. The big difference is really in how they’re constructed; it’s done in one-shot via record expressions, rather than with a multi-step instance create and modify. Because of this you can’t provide any code that runs at construction time, as you would with do statements in F# classes.

Modifying records

One of the surprising things – that I only discovered recently – is that you can actually modify record fields post-construction, provided they’re explicitly declared as mutable:

type Person =
    {
    Name : string
    mutable Age : int
    }

I consider this pretty nasty, and I have to say that I’ve never actually used records in this way. It’s typical of the way in which F# uses functional programming idioms like immutability in a pragmatic way, encouraging good practice but not strictly requiring it.

Personally I prefer to pretend that records are immutable once they’re constructed, and that modifying them requires copying. Luckily there’s a concise way of creating copies with modified field values using with. Here’s a function that takes an instance of a record type and returns a copy with a modified foo field:

let newMyRecord r = { r with foo = r.foo + 1 }

Pattern matching

A nice aspect of records is their ease of use in pattern matching. For instance you can very simply match against an individual field in the record, by using the underscore ‘wildcard’:

let hasZeroY =
    function
    | { X=_; Y=0.; Z=_ } -> true
    | _ -> false

Or you can even just specify an individual field; useful if you’ve got many fields:

 let xIsZero = function {X=0.} -> true | _ -> false

Structural equality

By default, record types use structural equality. This means that although under the covers they’re reference types, that’s not how they’re compared; the actual field values are used instead. This is an important difference between using simple C# classes and F# records.

Because of the default reference equality semantics in C# (which essentially compares pointers), this code will output “False”, despite the obvious similarity of r1 and r2:

class CSharpRecord { public int a; }
static void Main(string[] args)
{
    var r1 = new CSharpRecord() { a=1 };
    var r2 = new CSharpRecord() { a=1 };
    Console.Write(r1 == r2);
}

Whereas this returns ‘true’:

type FSharpRecord = { a : int }
let r1 = { a=1 }
let r2 = { a=1 }
r1 = r2

Apparently there’s a performance bug in the currently released version of F# whereby records with lots and lots of fields (circa 300), will take a long time to compare. Personally, I’d argue that if you’ve got records with 300 fields, you’ve got bigger problems to solve, but you can at least work-around it by disabling structural equality and comparison with the NoComparison and NoEquality attributes:

[<NoComparison;NoEquality>]
type MyRecord = { X : float; Y : float; Z : float }

This removes the custom Equals and CompareTo implementation that would otherwise be generated by the compiler.

How do they look?

If you do a bit of ILSpying (Reflector is so last year), you’ll probably be surprised at the amount of boilerplate that’s been generated on your behalf by the compiler.

Most of it is the interfaces and overloads required for structural equality, but we also get 3 items for each field: the actual CLR field that provides the storage, a getter method and a property that calls the getter. It’s more code than you’d have for the vanilla C# class we used above, but it’s not particularly bad.

And to non-F# consumers, records look like perfectly normal types:

var fr1 = new FSharpRecord(1);
Console.Write(fr1.a);

Summary

So there you go; a whistle-stop tour of records. If you want more info you can check out the MSDN page, or, if you’re feeling hardcore, the language spec, but in the meantime… have fun!

I created a .NET 3.5 app that does nothing except load a library. The library (doublelib.dll) contains a class, so we can reference it from the app, and a large uncompressed 24-bit BMP to waste a bit of space. In real life you’ll find lots and lots of code will also serve to waste space.

vmmap screenshot

If we ramp up vmmap and select the Images type, we can clearly see the 1.6mb DLL loaded twice. Click on the image for the full size screen shot.

You’ll notice that this only affects DLLs that aren’t in the GAC, and only affects .NET 2.0-based apps.

So let’s cut to the chase: there’s a hotfix available, and you can grab it from here: http://support.microsoft.com/kb/981266. It was reported a long time ago on MS Connect, but it seemed as if it had ended up in the wontfix pile… Then suddenly, a few months ago, a fix appeared. The only caveat is that it’s an opt-in thing; I guess this, and the delay, is probably because 2.0 is a “legacy” – although still officially supported – version of the runtime. MS seem reluctant to mess with what’s broadly working.

So, if you’re squeezed for memory, give the hotfix a try and reclaim your address space…!

Postscript

There’s a terrible bit of advice/misinformation on that KB page about the hotfix. It suggests one of the fixes is to:

Run the application on a 64-bit operating system. 64-bit operating systems have a large virtual address space.

This might be true for a 64-bit process on a 64-bit OS (where it’ll get a whopping 16TB), but in the case of a 32-bit app (which is specifically what the bug affects), you’re only going to get a relatively small amount of additional address space by running on 64-bit Windows; in the realm of a few hundred extra MB out of a theoretical maximum (excluding use of special switches) of 2GB.

“The 25th Consumer Electronics Show… showed very clearly that one thing continues to dominate the media and electronics business in the USA. This is not the personal computer – which seems to be causing far more interest in Europe than in America – but the video game.”

So while in the UK we were busy typing in listings from games magazines, in the US Atari, Mattel were creating ready-to-play cartridge based games.

Getting compelling press coverage was made difficult by the fact that it was impossible to get decent screen shots. Think how much of the pages in modern games mags are covered with glossy, full-colour, high-resolution screen shots. Without these, you’re left with nothing but words to describe these visual wonders. Luckily, you didn’t need much of a vocabulary to describe the games of the time; they were either based on existing analogue games, or they were derived from the small pool of original video game ideas:

“Munchie, which is similar to PacMan” … “Cosmic Raiders is a fast-action Defender style games” … “Solar Conqueror is an Asteroids game.”

Of course, some of this “re-purposing” was pukka; Coleco made table-top versions of things like PacMan, Donkey Kong, and Frogger (image above). You can imagine how faithful these arcade conversions actually were…

We’ve made quite some progress in the last 30 years, both in terms of game mechanics and graphics. It’s best summed up by 2 images, I’m sure you can guess which is from 1982, and which from 2012?

Click through these images for the full scans on flickr.

In these times of financial woe, people love to complain about all the big, nasty, faceless companies avoiding paying tax. They inevitably moan about it on Facebook, Google and Twitter (and sometimes even do something about it in the real, physical, world). But what about those companies themselves? The Web 2.0 behemoths are now some of the largest companies in the world, and they’ve decided – just like the evil old companies – that they don’t like paying all that tax. Don’t be evil… and don’t pay any tax if you can help it. But how do they do it?

The Numbers

An Irish Times newspaper article caught my eye the other day. It discusses the rapid growth of Facebook’s Dublin operation in 2010, whose accounts have just been published (as they must be by law, despite FB’s apparent reluctance). The headline figure is that:

[Revenue] is up from €15.2 million to €229.1 million

That’s a pretty significant increase! But that’s only revenue, how much of it was left over as profit?

Facebook Ireland generated a pretax profit of €1.9 million

What?! Where did the other €227 million go?

According to the article it mostly disappeared into a mysterious black hole known as “administrative expenses”:

Administrative expenses increased … to €221.6 million as a result of … royalties paid to other Facebook entities for services provided during the year.

How do they do that?

Is it me or does that sound suspicious? Well, it should do, because it is.

It turns out that Ireland’s significantly lower rate of corporation tax (12% vs 26% in the UK, and one of the lowest in the world) isn’t the only reason why companies like Facebook, Google et al move there. There’s also the very useful fact that, unlike most developed economies, Ireland chose not to introduce any legislation to prevent companies siphoning off their revenue to low-or-no-tax regimes like the Cayman islands or Bermuda.

So that’s where the “missing” €221 million has ended up: it’s been paid from the Irish part of the business to the tax-haven subsidiary, leaving only a small amount subject to corporation tax in Ireland. This practise is known in tax circles as the “double Irish”, and it (along with its Dutch equivalent) seems to be fairly widely used and well understood, even having its own wikipedia entry. Of course Facebook now funnels as much as possible of the revenue from the UK (its second biggest market) through the Ireland operation to get the most out of this arrangement. That explains the large increase in the numbers since last year.

There are many high-profile tech companies that have Dublin operations and may be avoiding tax in this way, including:

• Facebook
• Twitter
• LinkedIn
• Google
• Microsoft
• Oracle

That’s quite a roll call.

The Result

The result of all these shenanigans for Facebook? It pays a ridiculously small effective tax rate of less than 1%, even better than Google’s 2.4% rate. And given Ireland’s current economic state I can’t imagine their government will be introducing more restrictive tax legislation any time soon in an attempt to crack down on it. They can’t risk these big companies abandoning their new homes in Dublin’s Silicon Dock.

Of course, you should feel free to ‘like’ this blog post on Facebook, after all, what will it cost you?

(* Disclaimer: These are solely my opinions, not those of my employer or anyone else).

Work: Using F# in anger

During working hours (and sometimes beyond) I’ve been developing a large project using lots of F#, a little bit of C# and a bit too much XAML. It’s quite an interesting mix, with technologies that have a vastly different outlook on life: F# with it’s strong, compile-time type checking and XAML with its, err, not-so-strong type checking. In fact, XAML and WPF play so fast and loose with types, that errors in the binding mechanism only happen at run-time and are almost always eaten silently. As you can imagine, this makes for some fun debugging. All I can say is thank goodness for Snoop.

We have a quite a substantial amount of ViewModel code in F# (tens of thousands of lines), much of it using Async to allow us to create responsive UIs without requiring tons of boilerplate code. Generally it works nicely, but I do have some concerns about the amount of thread hopping going on, and how that will affect performance. Especially as we break things down into pretty small pieces of functionality, sometimes just a few simple operations, and each is run on the thread pool. I don’t have any concrete figures to go on here, and I’m hoping we don’t end up in a situation where we sacrifice user productivity for developer productivity. Time (and perfmon) will tell.

Debugging

I’ve done less hardcore WinDbg stuff this year. In fact, a couple of times I’ve been guilty of jumping in with the debugger where it probably would’ve been more effective to take a high-level look first. A case of having a debugger-shaped hammer, and everything looking like a nail.

Moving to 64bit

A very positive thing that happend this year was the move to 64-bit Windows 7 for development at work, meaning that Visual Studio actually stays up without crashing for more than an hour. Previously I’d been having a terrible time: the combination of a couple of large-ish F# projects and 32-bit XP caused frequent VS out-of-memory errors, which was very frustrating. Luckily the move to Windows 7 has resolved it, and I can even run more than a handful of apps at the same time; what a luxury.

Home: iOS

After a long day at work, I finally get to go home, put the kids to bed and then my feet up, and break-out Xcode for a bit of iOS hacking. This year I’ve been feeling like I’m finally getting my head around some of the things that are fundamental in iOS development; from Objective-C concepts like release/retain semantics to iOS specifics, view controllers, table views etc. Previously I’ve been guilty of some copy-and-paste coding, mostly because it’s pretty slow going getting up to speed with new tech (and the myriad iOS APIs) when you’re only getting to do it for a few hours while knackered after work. Well, that’s my excuse anyway.

I’ve been trying to finish off some of the apps that I’ve started, but not shipped. I tend to procrastinate a bit (massive understatement), and of course things aren’t helped by the development ‘fat tail’, where the last 20% – polishing and getting things ‘just right’ – takes at least 80% of the time. My 2010 post on Core Animation flip clocks continues to get a lot of traffic, and I finally bit the bullet and posted a (free!) app that uses it and it’s getting a lot of downloads, which is nice. I also had a look at iAd, which I’ll reserve judgement on for the time being, at the minute it’s not looking particularly lucrative…

As well as iOS stuff, I also took a look at OpenGL. I tend to do this every now and again, each time dipping in a little further and understanding a bit more. This time round it was looking at shaders (in OpenGL ES 2.0) and integrating with Bullet physics. My learning was certainly helped by this excellent Learning Modern 3D Graphics Programming tutorial.

Kinect and F#

Also while at home I finally got around to setting-up by my Kinect to do a bit of F# hacking. In the end I didn’t produce very much, but it was pretty good fun anyway.

Bring on 2012

So, to sum it up: more of the same really, I guess. Although this year there’s definitely been a bit more of a focus on UI development, in both WPF and iOS, which I’ve been enjoying. It does tend to feel a bit schizophrenic, switching between technologies and platforms at the end of the working day. It can be interesting to identify the common themes and significant differences in the two approaches to GUI development.

This year I’m hoping to make my blogging a bit more regular, but who knows if I’ll be able to stick to it… If there’s anything you’d particularly like me to focus on, feel free to leave a comment.

Star and text

Drawing the basic shape

The first step is to draw the ‘star’ shape. I decided to create a re-usable path, although at the minute I’m actually only drawing it once, so the benefits are limited. Doing this involves using the CGPath... versions of the Core Graphics functions, that add themselves to a mutable path objects, rather than being drawn directly on the currently active graphics context.

    CGMutablePathRef r = CGPathCreateMutable();
    // Always have to move to a start point
    CGPathMoveToPoint(r, NULL, x1, y1); 
    CGPathAddLineToPoint(r, NULL, x2, y2);
    CGPathCloseSubpath(r);

Once you’ve got created the path you can merrily set various stroke and fill colours and draw it over-and-over to your hearts content.

The star drawing is parameterised in a few ways: we can set the inner radius (r2), outer radius (r1) and the number of points, which must be divisible by 3. We draw the points in groups of three, the first on the outer radius, then the inner, then the last on the outer. In that way the sections tesselate into a complete circle.

Using it with CALayer

So now we’ve got some code to draw the shape we want, we need a way to get it onto the screen, using CALayers. There are 3 main ways of providing content for layers:

• Use a delegate that implements drawInContext (and don’t forget to call setNeedsDisplay at least once to cause it be drawn!)
• Set the content to a CGImageRef. Meh… that’s going to mean it’s a bitmap, with all the associated aliasing/scaling issues.
• Subclassing. Nah.

We’ll use the first approach; we can create a simple NSObject-derived class that can manage the layer hierarchy (more of that later) and implement the required selector on it. In that function we can switch on the layer we’re being asked to draw, and do the appropriate handling:

- (void)drawLayer:(CALayer *)theLayer
        inContext:(CGContextRef)context 
{
    if (theLayer == _textLayer) {
        // ...
    } else if (theLayer == _starLayer) {
        // ...
    }
}

Animating

We’re only going to be doing fairly basic rotation animation here, so we can use CABasicAnimation. We use the key-value coding support to specify the transform.rotation property as the target. This is an alias for rotation around the Z axis, which is pointing “out” of the screen. We rotate from 0 to 2*pi radians, repeating essentially indefinitely by specifying a large repeatCount.

    CABasicAnimation *animation = 
        [CABasicAnimation animationWithKeyPath:@"transform.rotation"];
    animation.duration=8.0;
    animation.repeatCount=HUGE_VALF;
    animation.autoreverses=NO;
    animation.fromValue=[NSNumber numberWithFloat:0.0];
    animation.toValue=[NSNumber numberWithFloat:TWOPI];
    [_starLayer addAnimation:animation forKey:@"rotation"];

Drawing the text

This was an interesting one. I originally started looking at a CATextLayer-based solution, but was surprised to find that it’s quite difficult to get vertical alignment within a rectangle. Instead, I decided to use the NSString UIKit additions that provide enough drawing and – importantly – measuring functions for us to work out exactly where we need to place the text.

One important thing to note here is that we’re potentially mixing Core Graphics and UIKit functions here. They have different expectations about how to get hold of the required graphics context; with Core Graphics it’s always passed explicitly, whereas UIKit will grab the current context. This means that if you try and call drawInRect within your drawLayer function, you’ll see errors like “Invalid context: 0×0″ on the console, and no output.

The solution is simple when you know how: tell UIKit about your explicit context, like this:

- (void)drawLayer:(CALayer *)theLayer
        inContext:(CGContextRef)context 
{
    // ...
    // Let UIKit know about this context
    UIGraphicsPushContext(context);
    // Because this function uses it internally...
    [myString drawInRect:r 
                     withFont:font
            lineBreakMode:UILineBreakModeClip 
                    alignment:UITextAlignmentCenter];
    UIGraphicsPopContext();
}

By measuring the text before we draw, we can align it centrally vertically and fill the space horizontally, letting iOS worry about the horizontal alignment. sizeWithFont takes into account a bounding rectangle and our desired breaking/clipping options:

        CGSize sz = [s sizeWithFont:font 
                 constrainedToSize:theLayer.bounds.size 
                     lineBreakMode:UILineBreakModeClip];

Setting up a layer hierarchy

Given that I wanted some parts of the thing to rotate, and others to be static, I needed to create multiple layers and put them together. This is very easily achieved by adding layers to the subLayers collection of our root layer, then we return the root layer and add that to the view.

Layer arrangement

    _star = [[StarLayer alloc] initWithRect:CGRectMake(100, 100, 100, 100)];
    [[self.view.layer] addSublayer:_star.root];

Next Steps

Here’s a red star and random text sitting a bit incongruously in a prototype of a spelling app I’m writing.

It would be good to create a whole load of stars (probably not with text in) and shoot them across the screen in a star-burst by generating a random direction/speed vector and animating their speeds, opacity and scale to make them fade out.

You can check out the code here.

OpenGL

The 3D work I’d done previously on iOS was using OpenGL ES 1.1, so as part of doing this, I also needed to get up to speed with the changes in version 2.0. The move involves replacing the fixed function pipeline approach with the use of shaders crafted in “shader language”, specifically GLSL. This approach is more flexible, but it means you take full responsibility for combining all the relevant matrices (model, projection etc), rather than letting OpenGL do it for you.

There are 2 distinct types of shader programs that operate on either vertices (vertex shaders) or pixels (fragment shaders). The steps required to create shader programs mirror the process of creating “normal” programs: they’re loaded, compiled and linked. Once you’ve got a program loaded, you can initialise it by setting variables of various kinds: attribute, uniform or varying. These are used for vertex and colour data, constants and passing data between vertex and fragment shaders respectively. If you’re interested in learning more, I suggest you check out some of the plethora of internet and dead-tree material on OpenGL. I’ll only be doing pretty basic stuff here.

Bullet

I decided to try using Bullet as the physics engine. It looks very powerful and is widely used in various games and movies; the only bad thing I can say about it is that decent documentation is a bit lacking. I found the best way to get help was googling for API names on the Bullet forum; not a very efficient way of doing things. Maybe I’ve just been spoilt by the copious Apple and MS docs (yeah, yeah).

Building it

Luckily Bullet comes with an Xcode project “in the box”, so with a bit of autoconf magic, it was soon up and building the demo apps. Although there are loads of files in there, the core library itself isn’t too large or complex. As such, I decided to create a separate static library project targeting the iOS simulator (i386) and devices (armv6/7).

API basics

My intention is to use only a small subset of the Bullet API, encompassing rigid bodies and a couple of simple constraint types. For the purposes of the demo, I’m going to create the pretty standard set-up of a large static ground-box, along with a collection of more dynamic objects.

The key part of joining up Bullet with your existing API is the btMotionState class. It enables the API to callback into your code with updated positions at each ‘tick’ of the physics engine, and you can then alter your geometry appropriately. I created a simple class that derives from btMotionState, implements the required pure virtual methods and contains a reference to my world object. Bullet calls the subclassed methods and we pass the transformations on to the object.

class QuadMotionState : public btMotionState {
    Quad *_object;
    btTransform _transform;
public:
    QuadMotionState(const btTransform &initialpos, Quad *node) {
        _object = node;
        _transform = initialpos;
    }
 
    virtual ~QuadMotionState() {
    }
 
    void setNode(Quad *node) {
        _object = node;
    }
 
    virtual void getWorldTransform(btTransform &worldTrans) const {
        worldTrans = _transform;
    }
 
    virtual void setWorldTransform(const btTransform &worldTrans) {
        // Pass the worldTrans to _object
    }
};

Debugging

Now, obviously you will write the perfect code first time, and will have no need for any kind of diagnostics. But I am not that perfect; I need to see the difference between what I’ve told the API to do, and what it’s actually doing. You can do this by creating an object implementing btIDebugDraw and passing it to the (slightly oddly named) setDebugDrawer function on your world:

btIDebugDraw *debug = new DebugDrawHelper();
m_dynamicsWorld->setDebugDrawer(debug);

The most important function on btIDebugDraw is drawLine. It will be called repeatedly to draw axes and bounding boxes in a variety of colours to indicate the object’s state. We can use the Shader we created earlier to give us an easy way of generating these debug visuals. All we need is a very simple shader, so can declare it inline:

program.loadShaders(
		"attribute vec4 position;\n"
		"uniform mat4 projection;\n"
		"void main () {\n"
		"gl_Position = position * projection;\n"
		"}\n", 
 
		"uniform highp vec3 color;\n"
		"void main () {\n"
		"gl_FragColor = vec4(color.r, color.g, color.b, 0.0);\n"
		"}");

Of course, anything more complex than this and you’ll want to put it into a separate file, but this program allows us to pass in the start and end vertex and its colour to draw the line in our implementation of DrawLine:

virtual void drawLine(const btVector3& from,const btVector3& to,const btVector3& color) {
        glUseProgram(program.getProgram());
 
        // Set the projection matrix
        GLint pu = glGetUniformLocation(program.getProgram(), "projection");
        glUniformMatrix4fv(pu, 1, 0, _projection.Pointer());
 
        // Set the colour of the line
        GLint puc = glGetUniformLocation(program.getProgram(), "color");
        vec3 v = vec3(color.getX(), color.getY(), color.getZ());
        glUniform3fv(puc, 1, v.Pointer());
 
        // Set the line vertices
        float tmp[ 6 ] = { from.getX(), from.getY(), from.getZ(),
            to.getX(), to.getY(), to.getZ() };
        glVertexAttribPointer(0, 3, GL_FLOAT, false, 0, &tmp[0]);
        glEnableVertexAttribArray(0);
        glDrawArrays( GL_LINES, 0, 2 );
}

Bullet debug output

Populating the world

So in order to have something nice to look at, we’re gonna need to put some ‘things’ into our world. And in order to make it act like the real world we’ll need to give those things some physical properties.

I created a simple class to render a textured box. This OpenGL object then needs to be represented in the physics worlds by a rigid body object, which in turn contains a collision detection object that closely matches the dimensions of the original object. In fact, in the case of a box, the collision detection object matches exactly, otherwise you’ll need to create an approximation using the more advanced classes. We use a btBoxShape to initialise our btRigidBody instance, along with setting its mass, inertia, and making a link to the state object that I mentioned above.

btRigidBody *addShape(Quad *shape, btScalar mass = 1.0f, float restitution = 0.2f)
{
	// Set the initial transform based on the current location of the object
        btTransform transform;
	transform.setIdentity();
	transform.setOrigin(btVector3(shape->getX(), shape->getY(), 0.));
 
	btCollisionShape* cshape = 
            new btBoxShape(btVector3(btScalar(shape->getWidth()/2),
                                     btScalar(shape->getHeight()/2),
                                     btScalar(shape->getDepth()/2)));
        btVector3 localInertia(0,0,0);
	if (mass != 0.0f)
            cshape->calculateLocalInertia(mass,localInertia);
 
        QuadMotionState *state = new QuadMotionState(transform, shape);
	btRigidBody::btRigidBodyConstructionInfo rbInfo(mass, state, cshape, localInertia);
	btRigidBody* body = new btRigidBody(rbInfo);
 
	body->setDamping(0.85, 0.85);
	body->setRestitution(restitution);
 
        // Add the rigid body to the Bullet physics world
	m_dynamicsWorld->addRigidBody(body);
 
        // Establish the link between our object and the physics object
	shape->setPhysicsObject(body);
	return body;
}

To make things look a bit more polished I added some textures to the quads, along with very simple normal mapping to get some lighting effects. I also added the ability to rotate the view and zoom in and out by using UIGestureRecognizers and changing the camera transform appropriately. The “finishing” touch (yeah, right), is the ability to tap to add a new quad.

The results

Here’s how the final thing looks. It’s very basic, I’ve hardly touched the surface of the Bullet API – there are no constraints in play, for instance – but it’s still kind of fun to play with. It’s running fairly slowly here, what with it being in the simulator, and being recorded. On a physical iPad it’s much snappier.
Let me know if you’d be interested to see some more coverage of some of Bullet’s constraints and hinges features.