Raspberry Pi iBeacons

I finally got around to playing with iBeacons on the Raspberry Pi today, following this tutorial from The Register. I chose a cheap (£12) Bluetooth LE USB dongle from Amazon, which Raspbian (from NOOBS v1.3.4) found without any problems. Configuration wasn't quite so effortless. I found that the following was a better order of steps once the BlueZ stack had been compiled and installed:

    sudo hciconfig hci0 up       # to ensure that the device was running
    sudo hciconfig hci0 noleadv  # unadvertise
    sudo hciconfig hci0 leadv 3  # readvertise, but as not-connectable
    sudo hcitool -i hci0 cmd ... # etc. etc.

I wrote a quick Python script to automate starting and stopping the beacon. (I'm still only starting to learn Python, so be gentle.)

On the iOS side, it appears to be necessary to set the (poorly-named) .notifyEntryStateOnDisplay property of the CLBeaconRegion instance you're monitoring to YES in order to get beacon entry and exit notifications while the app is active (as apposed to only when the device is sleeping or the app is in the background).

At the moment I have to walk to the far side of my flat in order to get an 'exiting beacon region' message, so I'm going to have to have a play about with the signal strength property. Or get a larger flat.

Scarce

Reading John Robb's excellent Punk Rock: An Oral History, what struck me from the beginning were the reoccurring tales of the difficulty early fans had in finding information about their new favourite bands, let alone getting hold of their records. Allegiances were formed on the strength of single paragraph reviews in the music press; overnight cross-country pilgrimages were made to see the bands play; the photocopied fanzine was the organ of record. (This was at the grassroots level. The Sex Pistols of course were the brainchild of an arch media manipulator. You had to work hard to avoid hearing about them.)

All of which William Gibson describes far more eloquently in his essay "1977" in Punk: An Aesthetic. He describes the shock of the new upon first seeing a stack of UK fanzines brought back to Toronto. "Today we know what new things look like before we encounter them physically. Usually we know what they'll look like before they even exist." He identifies grunge as the last of the pre-digital counterculture movements, the last to start its slow burn to popularity away from the gaze of a public always hungry for something new.

Even though I grew up in the pre-internet world, I find it hard to image what it would be like to experience such scarcity when nowadays even the most niche form of entertainment is, from its very earliest days, its very inception, only ever a Google away. Rather than fighting to have their voices heard across the great open expanse of culture, these day new experiences struggle to be heard above the cacophonous din of a million competing entertainments. Will the next significant movement benefit by the increase exposure the internet allows? or instead be drowned in a sea of noise?

NIB-Based Xcode iOS Template

I once failed one of those coding test job interviews things because of the changes made while I wasn't looking to Xcode templates. In my defence I hadn't actually needed to create a new project in a while and we'd just moved to a new version of Xcode and so on. The challenge itself wasn't too hard — just grab an XML file from a server, parse it, and then display the results in a table — but by the time I'd beaten the empty project into a shape I recognised most of the time had already slipped away. Ce la vie.

More recently, Xcode has moved to having all new templates use Storyboards by default. Often, this isn't what you want. While there are ways of reverting to the NIB-based templates available in Xcode 4, they aren't quite as simple as all that. Which is why I made this basic NIB-based template, which you can grab from GitHub here. Full installation instructions ("drop it into a folder") are included.

This template isn't a direct clone of the old-style ones, since by default it creates the application window and root view controller in code rather than loading them from a main NIB. What it does do is to create a NIB (or two NIBs, in the case of universal apps) for the root UIViewController subclass. I think this is close enough to the old behaviour for the usual use case of needing a quick test bed for trying something out — for any more substantial projects you're going to want to take the time to configure them by hand anyway. The template inherits (as far as Xcode templates implement inheritance) from Xcode's default iOS template, which means that projects created from it in the future will benefit from whatever (hopefully sane) changes Apple make there.

I was helped to throw this together by this StackOverflow post, and this description of the template format which it linked to.