The accelerometer in the iPhone allows for lots of interesting new methods of user interaction (here’s a good list of examples.)

We’ve recently been making an iPhone app which required a tilting back and forth mechanism — essentially the ability to ‘nod’ and ‘shake’ the iPhone. A tilt back and forth on the x-axis being a nod, and on the y-axis a shake (the app runs in landscape orientation.)

To watch for a nod or a shake, you can’t simply observe the present accelerometer values — you need to watch a range of them over time. Once you’ve got a set of data over time, you can do a bit of analysis on a particular window and see if it matches the gesture you’re after.

The free Context Logger app is very useful to watch the incoming data from the accelerometer and see what the data looks like for the gesture you’re after. For our gesture, a nod or shake, you get some kind of oscillating waveform. In an ideal world with ideal user interaction you’d get a nice
smooth sine wave with a fixed amplitude and frequency every time — not likely though in real life! You’re more likely to get some kind of triangle or saw wave with all kinds of bits of noise.

If you could really force the user to do one kind of nice wave for you, you could probably do a fourier transform to look at the incoming data and check for a spike at a certain frequency (e.g. suggestions here.) I do think there’s something to be said for forcing the user to conform to an expected input gesture — you can’t possibly capture every user’s interpretation of what a nod or a shake is — but at the same time you have to give a bit of leeway.

So in our case we tried to be more general. We simply watch for oscillations (ensuring the peaks are over a certain amplitude to ignore the low-level noise you always get) and if we get enough in our window on one axis we take it to be a nod or shake. We take an oscillation to be a change from a negative deviation from the mean of the values in our window, to a positive deviation from the mean, or vice versa.

One thing we’ve found in creating iPhone apps and running them on a Jailbroken iPhone to test them is that the directory fetching calls often return a different location from what you’d have in the simulator, or on an actual iPhone – and this target difference makes calls to file writing methods fail.

To get the Documents folder for your application, a typical place you’d want to write files, you’d call something like:

NSArray *paths = NSSearchPathForDirectoriesInDomains
(NSDocumentDirectory, NSUserDomainMask, YES);
NSString *folderPath = [paths objectAtIndex:0];

And then would append your file name to the folder path for your calls to the writeToFile method.

Apple’s documentation states that these differ based on being in a Simulator or on an actual phone – on the phone:

/var/mobile/Applications/30B51836-D2DD-43AA-BCB4-9D4DADFED6A2/Documents

And on the Simulator:

/Volumes/Stuff/Users/johnDoe/Library/Application Support/iPhone Simulator/User/Applications
                                            /118086A0-FAAF-4CD4-9A0F-CD5E8D287270/Documents

However, with a Jailbroken iPhone, it tends to write in slightly less intuitive places – the version we’re using causes the call to return

/var/mobile/Documents

This directory doesn’t exist by default, so you’ll need to both create it, and also give permissions to it – this can be achieved through using mkdir and chmod

After that, your file writing should start working correctly!

Over the last couple of days I have been busy porting the popular Cairngorm framework into JavaFX and have just uploaded the source into a fresh Google Code project: Cairngorm-FX

http://code.google.com/p/cairngorm-fx/

At Encore we have been very busy with JavaFX and are very excited about the technology. We also happen to use Cairngorm extensively in our Flex based projects as it really helps keep code structured/organized and when working in a team, is a real time saver (aside from coding in a reusable and scaleable way of course).

So a port of Cairngorm to JavaFX was pretty obviously going to be very useful to us! And as it will probably be useful to loads of other developers, we thought we would open-source it (under the MIT License).

Anyone who has done a lot of skinning in Flex will know the simplest, quickest and most effective way is to use a PNG with a scale 9 grid (via the Embed directive).

As an example, applied in CSS:

Button
{
    downSkin: Embed(source="/assets/skin_button_pressed.png",
        scaleGridBottom="23", scaleGridLeft="3", scaleGridRight="11", scaleGridTop="3");
    overSkin: Embed(source="/assets/skin_button_hover.png",
        scaleGridBottom="23", scaleGridLeft="3", scaleGridRight="11", scaleGridTop="3");
    upSkin: Embed(source="/assets/skin_button_normal.png",
        scaleGridBottom="23", scaleGridLeft="3", scaleGridRight="11", scaleGridTop="3");
}

So we get passed a PSD from one of the designers, export the PNG’s, then using an on-screen ruler or the guides in Gimp, work out what the scale grid parameters need to be. And its this last step that is just a bore.

So while toying around with JavaFX 1.2, I knocked together a little application which allows us to simply load a PNG, drag four guides to mark the scale grid, then click a button to copy an Embed tag with correct scale grid values to the system clipboard ready to paste into the code.

I know all of us at Encore will be using this little gem of a time-saver, so for anyone else who fancies using it too, I have packaged it up as a Java Web Start application.

Install and launch here:

From InfoQ:

Many in the community have wondered whether Oracle would maintain the same commitment to JavaFX that Sun has. Oracle rarely offers any insights on product strategy before it completes an acquisition, but in a surprise move Oracle’s chief executive Larry Ellison offered public backing for JavaFX at JavaOne, suggesting that it should be adopted by the OpenOffice group as they work on the UI redesign planned for the next version of the suite.