modernizer.js

If you’re working with HTML5 and CSS3–and you should be–you’re probably wasting a lot of time if you’re not using Modernizer. Modernizer gives you a quick and easy way to check exactly what browser or device features your visitors use using. I’d suggest reading Taking Advantage of HTML5 and CSS3 with Modernizr or How to use Modernizr and the check out the documentation.

respond.js

Respond provides faster css3 media queries for internet explorer 6+. This will help you out when you’re following your mobile first responsive design techniques (you’re doing that too right? right?). Get the source here on GitHub and then check out the documentation.

yepnope.js

yepnope is a nice little script loader but I’d only recommend using it if you have a lot of scripts and each one is rarely used. A much better idea is to combine all your JavaScript’s into one compressed file so that you only need one http request to download everything (especially on mobile devices).

impress.js

While impress may not help improve your site, this CSS3 powered interactive presentation tool will definitely help make client pitches rock. But, what about (Prezi)[prezi.com] you say? Go try the impress demo. You’ll understand why it’s called “impress” (though I have a soft spot for kinetic typography). For another example and some excellent reading check out What The Heck Is Responsive Web Design.

spin.js

Now here’s a great idea. How often do you need a nice little “spinner” loading animation? Gifs are so last decade so try this configurable, cross-browser JavaScript spinner with no images! Set a few properties and you’ll be loading in no time.

video.js

Again with the HTML5 scripts but now focused on video. You may or may not agree with thoughts on flash but you’ll probably like this impressive HTML5 video player. Drop it into your simple html5 video markup and you’ll get a nice cross-browser ui–with a fallback to Flash just in case.

zip.js

A JavaScript library to zip and unzip files. Now you can confuse non-savvy computer users right in teh browser!

psd.js

Parse the Adobe Photoshop PSD files right in your browser. NOt sure what I’d do with it but it’s pretty neat. Drop a psd on the demo page and you’ll get a lit of all the layers in the file.

zoom.js

zoom.js is a just an early experiment that allow you to quickly zoom in on DOM elements or points on a page. For example, click on any element on the demo page to zoom in.

jQuery Plugins

Here’s a few more that are great but also require jQuery.

scrollorama.js

Scrollorama is a fun plugin that helps you with “scrolly stuff” as the web site says. Scroll down the demo page to see various example of transitions, pinning, parallax and more. But, remember, use this responsibly. Don’t make scrolling the <blink> tag of 2012.

lettering.js

I’m a bit of a typophile (yes, I know the current iteration of this blog design needs work) and I love tools that make web typography easier. Lettering provides fine grained control for properties like kerning, layout and more. The gallery on the site is better seen than described so after you’re impressed check out the documentation here.

Official Android ADK Guides

• Official Google Android ADK page
  • ADK Components
  • Getting Started with the ADK
  • How an Accessory Communicates with an Android-powered Device in Accessory Mode
  • How the ADK board communicates with an Android-powered Device in Accessory Mode

Related Android Guides

• USB Accessory Dev Guide
• Android USB driver

Videos

• Google I/O Session Video: Android Open Accessory API and Development Kit (ADK)

Arduino

• Arduino Language Reference
• Arduino Library Reference
• Makezine Arduino Page

Hardware

Android Specific Components

• RT Corp
• Microchip
• DIY Drones

Arduino Components

• Boards
• Maker Shed

Examples

• Robot from Google IO
• 5,000-pound labyrinth from Google IO
• ADK Components

Have any more that I missed? Add a comment and I’ll update the list.

The post is in “blog” format with paragraphs shoved into the middle of code. For reference you can find the original demokit.pde file over in this Gist.

demokit.pde

The Arduino language is based on C/C++ so the file starts off with the typical headers you’ll need for the various libraries used in the sketch (servos, LEDs, capacitive touch, USB, etc).

#include <Wire.h>
#include <Servo.h>
#include <Max3421e.h>
#include <Usb.h>

These two are the ones you added to the Arduino application libraries when you set up your system for ADK development.

#include <AndroidAccessory.h>
#include <CapSense.h>

Next, you’ll see several ‘#define’ constants. These indicate which pins are attached to which features on the Android Demo Shield. If you look at the shield, you’ll notice each pin has a corresponding number. For example #define LED3_RED 2 indicates that the third LED’s red component pin is using #2 on the shield.

Technically you don’t need to do this and you could just use 2 throughout your code but defining a constant makes it much easier to read and understand the code when you use LED3_RED instead of referring to the board to see what pin 2 is.

#define  LED3_RED       2
#define  LED3_GREEN     4
#define  LED3_BLUE      3

#define  LED2_RED       5
#define  LED2_GREEN     7
#define  LED2_BLUE      6

#define  LED1_RED       8
#define  LED1_GREEN     10
#define  LED1_BLUE      9

#define  SERVO1         11
#define  SERVO2         12
#define  SERVO3         13

#define  TOUCH_RECV     14
#define  TOUCH_SEND     15

#define  RELAY1         A0
#define  RELAY2         A1

#define  LIGHT_SENSOR   A2
#define  TEMP_SENSOR    A3

#define  BUTTON1        A6
#define  BUTTON2        A7
#define  BUTTON3        A8

#define  JOY_SWITCH     A9      // pulls line down when pressed
#define  JOY_nINT       A10     // active low interrupt input
#define  JOY_nRESET     A11     // active low reset output

Now it’s time to identify the actual accessory. Read my previous post on “Identifying Your Android USB Accessory “ for more information but you can see here that the demokit.pde file identifies itself as version 1.0 of the Google DemoKit accessory.

AndroidAccessory acc("Google, Inc.",
             "DemoKit",
             "DemoKit Arduino Board",
             "1.0",
             "http://www.android.com",
             "0000000012345678");

Now, all that’s left to do is initialize a few variables, setup the environment and then start the loop that will continuously run to evaluate the IO for the Arduion board.

// Define an array for the servos
Servo servos[3];

// Initiate the touch sensor
// 10M ohm resistor on demo shield
CapSense   touch_robot = CapSense(TOUCH_SEND, TOUCH_RECV);

// Run the initial setup on the board
void setup();

// Loop and check for IO 
void loop();

Initialization

The pinMode() method is used to initialize the input and output pins on the Android Demo Shield. It configures the specified pin to behave either as an INPUT or an OUTPUT. Arduino pins default to INPUT so the mode doesn’t need to be explicitly set but its usually a good idea to do it anyway so that your code is clear and understandable.

For example, the init_buttons function identifies the pins for BUTTON1, BUTTON2, BUTTON3 and JOY_SWITCH as input connections.

void init_buttons()
{

    pinMode(BUTTON1, INPUT);
    pinMode(BUTTON2, INPUT);
    pinMode(BUTTON3, INPUT);
    pinMode(JOY_SWITCH, INPUT);

To identify the state of the buttons, a pin configured as an INPUT can have a HIGH or LOW value. Writing a HIGH value with will enable an internal 20K pullup resistor. Writing LOW will disable the pullup. The pullup resistor acts as a known value when no other input is present (such as when pressing the button). Later you can use digitalRead() to check the value to determine if the button has been pressed or not.

    digitalWrite(BUTTON1, HIGH);
    digitalWrite(BUTTON2, HIGH);
    digitalWrite(BUTTON3, HIGH);
    digitalWrite(JOY_SWITCH, HIGH);
}

Output pins, such as the relays in init_relays() are also configured using the pinMode() function however no default value needs to be written to the relays because it is always told to be either on or off.

// Initializes the relays as outputs
void init_relays()
{
    pinMode(RELAY1, OUTPUT);
    pinMode(RELAY2, OUTPUT);
}

The digitalWrite() method can also take varying values as inputs. For example, you may want to write an integer between 1 and 255 to represent the brightness of an LED. The init_leds() function sets all the LED pins as outputs and presets their output value to 1 (or bright).

// Initialize the LED outputs
void init_leds()
{

    digitalWrite(LED1_RED, 1);
    digitalWrite(LED1_GREEN, 1);
    digitalWrite(LED1_BLUE, 1);

    pinMode(LED1_RED, OUTPUT);
    pinMode(LED1_GREEN, OUTPUT);
    pinMode(LED1_BLUE, OUTPUT);

    digitalWrite(LED2_RED, 1);
    digitalWrite(LED2_GREEN, 1);
    digitalWrite(LED2_BLUE, 1);

    pinMode(LED2_RED, OUTPUT);
    pinMode(LED2_GREEN, OUTPUT);
    pinMode(LED2_BLUE, OUTPUT);

    digitalWrite(LED3_RED, 1);
    digitalWrite(LED3_GREEN, 1);
    digitalWrite(LED3_BLUE, 1);

    pinMode(LED3_RED, OUTPUT);
    pinMode(LED3_GREEN, OUTPUT);
    pinMode(LED3_BLUE, OUTPUT);
}

The joystick controls are little tricker so I’m not going to go into it in this post. If you’re interested see the init_joystick() and related functions at the bottom of the demokit.pde file that comes with the kit.

void init_joystick(int threshold);

Setup

Now that all the necessary helper functions are defined we can look at the setup function. The setup() function begins serial communications with the device and then calls all the initialization methods you saw earlier.

// These are a few variables to hold the state of the buttons.
byte b1, b2, b3, b4, c;

// Setup the board
void setup()
{
    // Begin communications.
    Serial.begin(115200);
    Serial.print("\r\nStart");

    init_leds();
    init_relays();
    init_buttons();
    init_joystick( 5 );

Next, setup() calibrates the capacitive touch sensor and sets the servos to their initial positions of 90 degrees.

    // autocalibrate OFF
    touch_robot.set_CS_AutocaL_Millis(0xFFFFFFFF);

    servos[0].attach(SERVO1);
    servos[0].write(90);
    servos[1].attach(SERVO2);
    servos[1].write(90);
    servos[2].attach(SERVO3);
    servos[2].write(90);

Lastly, setup() assigns the current HIGH or LOW value of the buttons to b1, b2, b3 and b4. During the loop execution, these values will be compared to the values in the loop and used to determine if the button’s state has changed since the last loop.

    b1 = digitalRead(BUTTON1);
    b2 = digitalRead(BUTTON2);
    b3 = digitalRead(BUTTON3);
    b4 = digitalRead(JOY_SWITCH);
    c = 0;

Now the setup power’s on the accessory.

    acc.powerOn();
}

Loop

The loop() function is the heart beat of the Arduino Base Board. After creating and executing the setup() function, which is responsible for initializing the initial values, the loop begins it’s magic and loops consecutively, allowing the sketch to analyze and respond accordingly.

The loop in demokit.pde has two main responsibilities. First, if the device is connected, it will read any input and write output to the device as necessary. Second, if no device is connected it will reset all the initial values to await a new device connection.

void loop()
{
    byte err;
    byte idle;
    static byte count = 0;
    byte msg[3];
    long touchcount;

Here it looks for a connection.

    if (acc.isConnected()) {

        int len = acc.read(msg, sizeof(msg), 1);
        int i;
        byte b;
        uint16_t val;
        int x, y;
        char c0;

If the length of the input buffer from the attached Android device is greater than zero, the loop process the input command to determine what it should do.

        if (len > 0) {

The message format can be seen in the DemoKit Android App that also comes with the kit. If you take a look at the sendCommand() method in the com.google.android.DemoKit.DemoKitActivity class. You’ll see something like this:

...
buffer[0] = command;
buffer[1] = target;
buffer[2] = (byte) value; 
...

In the case of a LED or Servo command, the command‘s value is 2 (DemoKitActivity.LED_SERVO_COMMAND), followed by the target and the value to associate with the target.

For example, you can see in the following code that the red, green and blue pins for each LED are updated, but only when msg[0] is 2 (0x2). The LED pin to update is defined in msg[1] (0x0 thru 0x8 respectively) and the value is set using msg[2] and analogWrite().

In the case of the value for a LED, the lower the value the brighter the light (or the higher the value the more black and darker the light). The DemoKit app on the Android device sends 255 when it wants a full bright light so the value is subtracted from 255 to set the appropriate value for “bright”.

            // Assumes only one command per packet.
            if (msg[0] == 0x2) {
                if (msg[1] == 0x0)
                    analogWrite(LED1_RED, 255 - msg[2]);
                else if (msg[1] == 0x1)
                    analogWrite(LED1_GREEN, 255 - msg[2]);
                else if (msg[1] == 0x2)
                    analogWrite(LED1_BLUE, 255 - msg[2]);
                else if (msg[1] == 0x3)
                    analogWrite(LED2_RED, 255 - msg[2]);
                else if (msg[1] == 0x4)
                    analogWrite(LED2_GREEN, 255 - msg[2]);
                else if (msg[1] == 0x5)
                    analogWrite(LED2_BLUE, 255 - msg[2]);
                else if (msg[1] == 0x6)
                    analogWrite(LED3_RED, 255 - msg[2]);
                else if (msg[1] == 0x7)
                    analogWrite(LED3_GREEN, 255 - msg[2]);
                else if (msg[1] == 0x8)
                    analogWrite(LED3_BLUE, 255 - msg[2]);

The servo output uses the same command and is processed in the same if condition however setting the servo position is a little different. You can read more in the Servo library but the basics here are that the servo’s write() method takes an angle for the servo and the map() method is used to re-map the input value from one range (0-255) to another (0-180).

                else if (msg[1] == 0x10)
                    servos[0].write(map(msg[2], 0, 255, 0, 180));
                else if (msg[1] == 0x11)
                    servos[1].write(map(msg[2], 0, 255, 0, 180));
                else if (msg[1] == 0x12)
                    servos[2].write(map(msg[2], 0, 255, 0, 180));

            } else if (msg[0] == 0x3) {

For the two relays on the Android Demo Shield, msg[2] is simply compared for a HIGH or LOW value and the board is updated accordingly.

                if (msg[1] == 0x0)
                    digitalWrite(RELAY1, msg[2] ? HIGH : LOW);
                else if (msg[1] == 0x1)
                    digitalWrite(RELAY2, msg[2] ? HIGH : LOW);

            }

        }

At this point in the loop, all the input messages have been processed so the loop switches to checking all the output pins and sending any necessary messages to the device. The message type for output is set to 1 and each individual output is checked.

        msg[0] = 0x1;

For example, in the following code the state of BUTTON1 is read into b and compared to b1. Earlier you saw how the read value of the pin associated with BUTTON1 could be either HIGH or LOW. If the value of b differs from the value of b1 (defined in setup() or in the previous run of the loop) then the state of the button has changed and the appropriate message is sent back to the connected Android device. At the same time, b is assigned to b1 to indicate the new state for the next loop.

        b = digitalRead(BUTTON1);
        if (b != b1) {
            msg[1] = 0;
            msg[2] = b ? 0 : 1;
            acc.write(msg, 3);
            b1 = b;
        }

        // Check button 2
        b = digitalRead(BUTTON2);
        if (b != b2) {
            msg[1] = 1;
            msg[2] = b ? 0 : 1;
            acc.write(msg, 3);
            b2 = b;
        }

        // Check button 3
        b = digitalRead(BUTTON3);
        if (b != b3) {
            msg[1] = 2;
            msg[2] = b ? 0 : 1;
            acc.write(msg, 3);
            b3 = b;
        }

        // Check for a press on the joystick button.
        b = digitalRead(JOY_SWITCH);
        if (b != b4) {
            msg[1] = 4;
            msg[2] = b ? 0 : 1;
            acc.write(msg, 3);
            b4 = b;
        }

Once all the digital reads for the buttons have completed, the demokit uses an analogRead() to determine the current values of the temperature sensor, the light sensor, the joystick and the capacitive touch sensor. At first I was confused by the use of a switch statement here until I realized the expense of an analog read. It takes about 100 microseconds to read an analog input, so the maximum reading rate is 10,000 times a second. That’s pretty good but we don’t want to slow things down unnecessarily, especially when environmental variables such as temperature and ambient light are not changing dramatically at a rapid pace. The switch and count++ % 0x10 condition allows the loop to reduce the frequency of analog reads and only sample one analog read per loop.

        switch (count++ % 0x10) {
        case 0:
            val = analogRead(TEMP_SENSOR);
            msg[0] = 0x4;
            msg[1] = val >> 8;
            msg[2] = val & 0xff;
            acc.write(msg, 3);
            break;

        case 0x4:
            val = analogRead(LIGHT_SENSOR);
            msg[0] = 0x5;
            msg[1] = val >> 8;
            msg[2] = val & 0xff;
            acc.write(msg, 3);
            break;

        case 0x8:
            read_joystick(&x, &y);
            msg[0] = 0x6;
            msg[1] = constrain(x, -128, 127);
            msg[2] = constrain(y, -128, 127);
            acc.write(msg, 3);
            break;

        case 0xc:
            touchcount = touch_robot.capSense(5);

            c0 = touchcount > 750;

            if (c0 != c) {
                msg[0] = 0x1;
                msg[1] = 3;
                msg[2] = c0;
                acc.write(msg, 3);
                c = c0;
            }

            break;
        }
    } else {

As mentioned earlier, when a device is not connected (or was disconnected) the loop resets the outputs to the default values.

        analogWrite(LED1_RED, 255);
        analogWrite(LED1_GREEN, 255);
        analogWrite(LED1_BLUE, 255);
        analogWrite(LED2_RED, 255);
        analogWrite(LED2_GREEN, 255);
        analogWrite(LED2_BLUE, 255);
        analogWrite(LED3_RED, 255);
        analogWrite(LED3_GREEN, 255);
        analogWrite(LED3_BLUE, 255);
        servos[0].write(90);
        servos[0].write(90);
        servos[0].write(90);
        digitalWrite(RELAY1, LOW);
        digitalWrite(RELAY2, LOW);
    }

Then the loop ends by delaying for a few milliseconds.

    delay(10);
}

The remainder of the file deals with the IO of the joystick. You can just take it as is and I’ll leave it until another post.

Hopefully this was a little helpful getting you started with the ADK and the demokit example.

AndroidAccessory(const char *manufacturer,
                 const char *model,
                 const char *description,
                 const char *version,
                 const char *uri,
                 const char *serial);

For example, the DemoKit app that comes with the ADK identifies itself as version 1.0 of the Google DemoKit accessory:

AndroidAccessory acc("Google, Inc.",
                 "DemoKit",
                 "DemoKit Arduino Board",
                 "1.0",
                 "http://www.android.com",
                 "0000000012345678");

You’re own app might looks something like this:

AndroidAccessory acc("My App Company",
                 "CoolAccessory",
                 "CoolAccessory Arduino Board",
                 "1.0",
                 "http://www.example.com/CoolAccessory",
                 "0000000012345678");

The three key one’s you’ll need to remember are manufacturer, model and version as you’ll need to define these in you’re Android app so that the device can notify your app when your accessory is connected.

When you create your Android app, there’s a few steps you need to take. First, not every Android-powered device supports the USB accessory APIs. In fact, the Android Open Accessory ADK is only supported by Android OS 3.1 and 2.3.4 platforms. To identify that your app has USB features, you need to include a <uses-feature> element in your manifest to declare that your application uses the android.hardware.usb.accessory feature.

 <uses-feature android:name="android.hardware.usb.accessory" />

Next, if you’re using the add-on library, add a <uses-library> element with com.android.future.usb.accessory for the USB accessory library.

<uses-library android:name="com.android.future.usb.accessory" />

and set the minimum SDK of the application to API Level 10. If you’re using theandroid.hardware.usb package then the <uses-library> isn’t necessary and you only need to set the minimum SDK to 12 .

Lastly, you’ll want your application to be notified when your accessory is attached. Specify an <intent-filter> and <meta-data> element pair for the android.hardware.usb.action.USB_ACCESSORY_ATTACHED intent in your main activity. Overall your manifest should look something like this:

<manifest ...>
    <uses-feature android:name="android.hardware.usb.accessory" /> 
    <uses-sdk android:minSdkVersion="<version>" />
    ...
    <application>
        <uses-library android:name="com.android.future.usb.accessory" />
        <activity ...>
            ...
            <intent-filter>
                <action android:name="android.hardware.usb.action.USB_ACCESSORY_ATTACHED" />
            </intent-filter>
            <meta-data android:name="android.hardware.usb.action.USB_ACCESSORY_ATTACHED"
                android:resource="@xml/accessory_filter" />
        </activity>
    </application>
</manifest>

The <meta-data> element references an XML resource file that includes the manufacturer, model and version you defined earlier in your Arduino sketch. Create an accessory_filter.xml resource file in the res/xml/ directory with a <usb-accessory> element to identify your accessory.

<resources>
    <usb-accessory model="CoolAccessory" manufacturer="My App Company" version="1.0"/>
</resources>

Now, when you connect your accessory to the device android will send an intent to open an appropriate application. The best part is that more than one application can respond to a given intent so multiple apps could optionally respond for the same accessory.

A co-worker was lucky enough to be invited to Google IO this year to promote our Lozzal Android app. That went great but while there, he snagged me one of the Android Open Accessory API and Development Kits (ADK)! Though he got to keep the sweet, sweet tablet which kills my idea of a home automation panel on the kitchen wall.

I’m pretty excited about the Android ADK, especially since it’s based on one of the Maker’s favourite platform—Arduino. If you’re not sure why this is so awesome, I suggest reading the Makezine post on Why Google Choosing Arduino Matters. I looked into building external devices with iOS a few moths back but quickly discovered Apple requires special chipsets–which can’t be easily obtained by little indy hardware developers like myself. Now, with an easily accessible platform and relatively cheap hardware components, I have lots of projects I want to dive right into.

For those that didn’t get one, here’s a quick demo of what the Android ADK hardware includes (Sorry about the audio, didn’t have a mic):

Included in the kit:

• A USB micro-controller board that is based on the Arduino Mega2560
• Android Accessory demo Shield
  • Joystick
  • 3 Buttons
  • 3 RGB LEDs
  • Temperature Sensor
  • Light Sensor
  • Capacitive touch sensor
  • 2 relays (24 VOC, 1A max)
  • 2 servos (though the board has three connectors)
• AC Adapter
• USB cable

Before creating this demo video I only spent about 10 min installing and setting up the Arduino software, Android ADK components and the DemoKit app on the phone. The initial setup is quite easy and you can be playing in minutes.

My only complaint (if you can call it that) is it would have been awesome to have more IO sensors, maybe IR (tv remote!), sound, or NFC on there. I guess it’s time I investigate all the other great Arduino shields and see what else I can do.

After poking around I thought it might be fun to map out some of that infamous iPhone Location Tracking Data in the WebGL globe so I grabbed my consolidated.db file, exported the CellLocation table and ran it through this quick PHP script:

<?php

$data = explode("\n",file_get_contents("CellLocation.data"));

$magnitudes = array();

// Group like towers
$c = count($data);
for ($i = 0 ; $i < $c ; $i++) {
    $ll = $data[$i];
    list($lat,$lng) = explode('|',$ll);
    $key = round($lat,2) . ',' . round($lng,2);

    if (array_key_exists($key, $magnitudes)) {
        $magnitudes[$key]++;
    }   else {
        $magnitudes[$key] = 1;
    }   
}

$json = '';
while (list($ll,$count) = each($magnitudes)) {
    $json .= str_replace('|',',', $ll);
    $json .= ',';
    $json .= $count / 100;
    $json .= ',';
    $json .= 11;
    $json .= ',';
}

echo '['.trim($json,',').']';

Dropping the output of the script in the place of the search results json file presented me with this:

You can play with the live WebGL version here if you want. Now I just have to learn a little more WebGL to make the map zoom in and out.

UPDATE: Looking at the globe.js source, apparently you can zoom if you have a mouse with a wheel though it’s very pixelated.

I have a MacBook so I opened up the Terminal app and entered this:

ssh -l jsambells -L 3390:192.168.1.100:3389 example.dev.box cat -

Then all I had to do on my MacBook was enter localhost:3390 into Microsoft’s Remote Desktop Connection app and login to the Remote Desktop.

Huh?

This is what’s know as an SSH tunnel. Basically it creates a secure connection that forwards a port on one machine to another. My above command contains several components:

• 3390 is the local port on my MacBook that I’ll be using to connect to the Remote Desktop in the office. This could be any port above 1024 and below 32768. Doesn’t matter.
• 192.168.1.100 is the example IP address of the machine I want to access on the internal network. This IP must be accessible by the machine at example.dev.box.
• 3389 is the standard port number for Remote Desktop connections.
• example.dev.box is a publicly accessible machine that can also connect to the internal machine.
• cat - is a command that won’t finish so the connection stays alive.

The trick here is that I needed a machine that could connect both the the internet at large and to the internal company network (which I happen to have at example.dev.box). The command uses an SSH tunnel to forward the traffic between localhost:3390 and any connections to 192.168.1.100 on port 3389 of example.dev.box. Connecting locally at home to localhost:3390 is the same as connecting to 192.168.1.100:3389 from example.dev.box.

You can use similar techniques to secure any traffic, such as your email or bypass firewall restrictions.

Googling around I found several straight forward references for doing just that. The basic process is to modify your repo so that everything is in a sub-directory using this command:

git filter-branch --index-filter 'git ls-files -s | sed "s-\t-&newdir/-" |
    GIT_INDEX_FILE=$GIT_INDEX_FILE.new \
    git update-index --index-info &&
    mv $GIT_INDEX_FILE.new $GIT_INDEX_FILE' HEAD

and then merge the various sub directories into one project. Perfect. Just what I needed. However, I spent a few hours trying to do so and ran into a few problems which I thought I’d share.

First, I was using Mac OS X and unbeknownst to me the sed command doesn’t support \t from the command line so sed "s-\t-&newdir/-" in the above command was searching for a literal t instead of a tab. This messed up the new file paths in the git ls-files -s output so I had to find a workaround. Apparently the \t issue is due to posix or something and I tried several variations without luck so I moved to a Debian box that didn’t have this issue (I’d love to know how to fix it).

Second, the git repositories I’m working from were created from a large SVN import. In SVN, you can commit an empty directory to the repository so in several cases the commit in my repo didn’t have any files associated with it (this was always the case with the first commit that created the initial SVN repository). Git doesn’t allow you to commit empty directories—it must contain at least one file—so the above command’s mv portion failed when a file didn’t exists. I tried to remove or squash the offending commits several different ways but always ran into more problems with conflicts or strange trees. Sitting back and trying to see the big picture, I broke down the command and realized that I could just check if the file existed before it was moved. This made a lot more sense:

git filter-branch --index-filter 'git ls-files -s | sed "s-\t-&newdir/-" |
    GIT_INDEX_FILE=$GIT_INDEX_FILE.new \
    git update-index --index-info &&
    if test -f "$GIT_INDEX_FILE.new"; then mv $GIT_INDEX_FILE.new $GIT_INDEX_FILE; fi' HEAD

That did the trick and I could proceed with merging my repos as I pleased.

Like the iPhone, the iPad has only one primary button on the front of the device and a few buttons on the sides (for volume and on/off). The logistics of a kiosk mean people shouldn’t be allowed to randomly quit the app so you have to disable the iPad buttons by jailbreaking—and installing the appropriate software—or by disabling them physically (by covering them up). For physical barriers, there are a number of existing products such as the nice looking Beyond Kiosks, the more portable iBracket or simple DIY projects like this wooden kiosk stand. I’m not sure how the wooden kiosk stand would hold up to abuse but, hardware aside, it comes down to the software problems.

To run successfully as a kiosk, the kiosk app needs to be the only app running on the device without the ability to exit the app in any way (at least without removing the iPad from its enclosure). The iPad doesn’t offer an easy way to force an app to stay open but you can be sneaky and do things like launching the app again whenever it happens to close:

-(void)applicationWillTerminate:(UIApplication *)application {
    [application openURL:[NSURL URLWithString:@"mykioskapp://"]];
}

Note: Doing this would probably get an app rejected from the App Store.

Care must also be taken not to include any way for a user to accidentally jump into another application, such as the web browser or the email app. If someone gets out of the kiosk application they’ll probably be confused but, more importantly, they’ll be stuck with no way to get back because the only buttons that would return them to the kiosk application have been disabled or covered up.

The other software problem is dealing with the Apple App Store submission process. Running in a kiosk could initially be great since a kiosk app probably isn’t going to be distributed through the app store. Instead, it will be easily loaded on each kiosk directly. Both a development distribution or an over-the-air Ad-Hoc distribution would work but each come with their own problems. Anyone who has dealt with Ad-Hoc or development distributions knows that the certificate process isn’t fun and just when you think you have it sorted out, the provisioning profiles on the devices expire and you have to repeat the process. It would be great to bypass the burden of the Apple App Store rules and regulations but to do so someone will need to be on-site to update the app on a regular (monthly) basis as the development or Ad-Hoc distributions expire or the app itself needs updates.

The idea of an iPad kiosk is obviously possible and there are a few existing companies already using it for things such as ticket sales or product information. If I get any further into the project I’ll post some updates and let you know how it goes.

Release early, release often (sometimes abbreviated RERO) is a software development philosophy that emphasizes the importance of early and frequent releases in creating a tight feedback loop between developers and users.

— Wikipedia

To begin let me say that I’m both a web developer and a mobile application developer and I LOVE the “release early, release often” philosophy for web development. RERO allows me to make quick updates and improvements and add great new features for all my users. RERO is great. It’s awesome. It works and all the developers and users using the application are happy.

On the other hand, I loath RERO when it comes to SDK’s. It’s just a flawed and utterly terrible idea when there’s no clear and very accessible upgrade path for end users. As a web developer, I would not be happy if Microsoft decided to release IE9, IE10 and IE11 in the span of a year. My workload would more than triple, my user base would fragment and I’d be endlessly adding kludges for each new version. Unfortunately this is what’s starting to happen with the Android SDK and, as a mobile developer, I’m starting to get worried.

Android OS

To understand how RERO can harm adoption let’s take a look at the public Android SDK release schedule:

• API Level 2, Android 1.1 — February 2009
• API Level 3, Android 1.5 — April 2009
• API Level 4, Android 1.6 — September 2009
• API Level 5, Android 2.0 — October 2009
• • API Level 6, Android 2.01 — December 2009
• API Level 7, Android 2.1 — January 2009
• API Level 8, Android 2.2 — May 2009

Wow. In the past fifteen months (a little over a year) there have been seven public releases of different versions of the Android SDK. That doesn’t include carrier or manufacturer revisions with different user interfaces. It’s not that I’m not happy with the advancements of the SDK. They’re all wonderful and obviously the Android team is working really hard but there’s a problem. If we take a look at Google’s published Platform Versions stats and we can see where developers have a tough decision:

— Source

More than 50% of the Android install base is still using version 1.6 or less. As a developer what should I do? If I choose to take advantage of the latest and greatest SDK I get less than half of the devices! But still, the bigger problem is there is no clear and easy upgrade path for those bottom 50% to get the newer OS version. Neither of my Google supplied development phones (which are only a year old) can be upgraded without a lot of illicit hacking and deep developer knowledge.

The Android OS is in deep trouble until there’s an easy way to upgrade the OS on every device that runs it.

iPhone OS

Now contrast this situation with iPhone OS. Apple has been lambasted by developers for their tight control and strict NDA rules regarding beta releases but in comparison to the situation with Android isn’t it better? The NDA period allows the SDK to be flushed out, before it is “publicly” available so that there is one complete well oiled version that all developers can target across a large set of devices.

The public iPhone SDK release timeline is also much longer:

• SDK 1.0 – June 2007 (not public)
• SDK 2.0 – July 2008
• SDK 3.0 – June 2009
• • SDK 3.1 – September 2009
• • • SDK 3.1.2 – October 2009
• • • SDK 3.1.3 – February 2010
• SDK 3.2 – April 2010

Major iPhone releases are spaced a year apart (with a few minor releases in-between) allowing developers to actually develop and release an app before the SDK changes.

The iPhone has another big advantage and it solves the problem of distribution as I alluded to earlier. iPhone users use iTunes to sync their devices and add content. The process of syncing the device also checks for updates and allows all iPhone OS devices (iPhones, iPod Touches, iPads) to download the latests version of the OS. As a result the March 2010 iPhone Platform Versions stats look very developer friendly:

— Source

That’s only 5% of users who have NOT upgraded to at least 3.0 and 86% who are using one of the latest two (as of March) 3.1 minor versions. How great is that? Not only does 3.1 contain great features, I can actually use them and hit 86% of my users right away.

The Result

Recent trends are showing that Android OS based devices are passing Apple’s iPhone OS devices to be the No. 2 smartphone operating system in the U.S.—After RIM’s Blackberry OS:

• RIM’s BlackBerry OS at 36 percent;
• Android at 28 percent;
• Apple at 21 percent.

—source

I say as a developer I don’t care. The number of devices per OS is a great marketing number for Google and Apple to fight over but as a developer—who wants to get the most out of the SDK—I care about the version of the OS on the devices. If I want to use the latest and greatest SDK’s I’ll take Apple’s 80% of 21% over Google’s 30% of 28%.