Last year there was a big catalyst for change in my life. I decided it was time to move on from the the company I helped start and pursue a career in mobile technologies. This has been a wonderful change and the new start I need to make more change. To help even further, I’m making my resolutions public so that failure is not an option.

So, here’s my resolutions and the tools I’m using to achieve them. For now I’ll just tell you what the tools are and I’ll post later about how they help and how they’re working out:

1. Live a healthy lifestyle

I purposely didn’t choose “lose weight” or “exercise” as my ultimate goal isn’t a specific measurement. I just want to have more energy, be healthier, live longer and have more fun. My kids are really active and I find I’m often out of breath just playing with them for a few minutes in the living room. It’s time to really do something about it with the help of a Jawbone UP, Loseit and Fleety. I already know where I’ve been going wrong in the past but a weekly summary will be very helpful to keeping goals in check and make sure everything is going as planned.

2. Keep a daily journal

I’ve always wanted to keep a journal and I’ve tried. In the past my goals have always been to high. I felt the need to write something inspiring and important every day–which is not feasible–so I just ended up overwhelmed and abandoning the project. Instead, I’m starting out small by using Day One to jot down a few interesting notes. I’ll just write something every day and see where it goes from there.

3. Take a picture a day

This one’s easy, I just have to remember to do it. The Everyday app is going to do most of the work and if I achieve my first goal then this will be a great way to actually see the progress throughout the year.

4. Fill my family photo stream

I really want to spend more time documenting the lives of my kids. They’re great subjects but every Christmas my wife and I go to do a photo album for the Grandparents and realize we only have a handful of photos for the year. We miss dozens of great opportunities. At the same time I don’t want to live the year through a camera so my iPhone 4S is going to be my documentation device of choice. It’s always in my pocket so I don’t have an excuse not to snap a few shots.

To make it more fun I’m going to grab some Olloclip lenses and I’ve loaded the iPhone up with some great apps like Instagram, TimeLaps, Photosynth, Snapseed, iMovie and Camera+. Along with a Glif, a Gorillapod and my earphones I should be set.

5. Write one decent post every Monday

One well written post every Monday, created on my iPad, with others as I find time. Something related to mobile/iOS/Android or something I think you’ll find interesting. This will require research and a lot of reading and writing so Reeder, Penultimate, Phraseology, Instapaper, and WordPress and going to come in very handy.

6. Relax and Have Fun

The rest of the time I’m going to relax and have fun with the family. Without my phone.

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.

The basic idea is that you’ll share your desktop’s internet connection with your mobile device and then watch any traffic you want from your desktop. This involves a few simple steps:

1. Share your desktop’s internet connection.
2. Use the shared connection from your mobile device.
3. Sniff your traffic.

Sharing your desktop internet connection with your mobile device

In a Mac environment this is easy (and you should be able to do something similar in Windows). The only requirement is that you’ll need a wireless card (comes built-in to all modern Macs) and you’ll need a second internet connection such as the ethernet port (since your wireless card will be occupied sharing your connection). Once you have these, simply go to:

Apple Menu > System Preferences… > Sharing (under Internet & Wireless)

In this pane, click on the “Internet Sharing” text but don’t check the box yet. Select Ethernet from “Share your connection from” and then check the box next to AirPort in “To computers using”. Now check the box next to “Internet Sharing” on the left. It should look something like this:

This tells your mac to take the incoming Internet connection on your Ethernet port and send it out to other connected devices on your wireless AirPort port. If everything went well you’ll also notice the icon for your AirPort connection looks like a little arrow pointing up:

.

NOTE: This creates an OPEN network without a password that anyone can connect to. If you’re in an area where you would rather have a private network, select the “AirPort Options…” button in the sharing pane and adjust settings as necessary before you start up your shared connection.

Connecting to the your shared connection from your mobile device.

Now you can connect any Wi-Fi device to your shared network including other computers, iPhones, iPads, Android phones, whatever.

For an iOS device, simple go to:

Settings.app > Wi-Fi

and select your shared network (in my case “Jeffrey Sambells’s MacBook Pro”).

For Android you can find similar settings in Settings > Wireless & Networks > Wi-Fi Settings.

Once you’re connected to your shared Wi-Fi your mobile device will act as usual but all it’s traffic will be routing through your desktop computer–perfect for sniffing.

TIP: I find it’s often a good idea to enable Airplane mode on your mobile device so that you can be sure the requests will go over Wi-Fi instead of the cell network. To do this, just turn on Airplane mode in settings and then enable just Wi-Fi to connect to your shared connection.

Sniffing your mobile traffic.

Now comes the fun part. Since all the traffic from your device is now routing through your shared network, you can watch that network and see what’s going on.

I’ve found the easiest way to do this is using an app like HTTPScoop. If you set HTTPScoop watch your AirPort interface and then hit Scoop you’ll get a list of all the HTTP connections that occur to and from the mobile device:

and you can inspect each request for headers, raw data and the content of the request:

This is very useful for debugging you app’s requests and response as well as poking to see how other apps (including Apple’s built in apps) communicate with the network. Every wonder how map tiles load into the Maps.app? Or maybe you’re curious what info all your installed apps are sending out about you. Know you can find out.

If you need deeper details about the network traffic, there’s a number of other apps you can use that provide more details packet analysis.

Enjoy.

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.

With the new iPhone iOS 4, you can distribute apps wirelessly without iTunes intervention. You still need to collect the appropriate devices id’s and create the appropriate provisioning profiles but if you already have those sending out files is easy.

First, select “Build and Archive” from your XCode build menu. Your archived project will be stored in the “Archived Applications” section of the the XCode organizer (Window > Organizer).

Next, select the archive you want to distribute in the XCode organizer and select “Share Application…” at the bottom of the window. Pick the appropriate provisioning profile and then “Distribute for Enterprise”.

In the distribution window, enter the title and the full url to the ipa file (where you plan to host your app) for example, http://jeffreysambells.com/example.ipa.

Along with the generated .plist and the .ipa files, you’ll need the provisioning profile and a simple index file, for example:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
        "http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<title>My Cool app</title>
</head>
<body>
<ul>
    <li><a href="http://jeffreysambells.com/example.mobileprovision">
                Install Example Provisioning File</a></li>
    <li><a href="itms-services://?action=download-manifest&url=http://jeffreysambells.com/example.plist">
                Install Example Application</a></li>
</ul>
</body>
</html>

With these all uploaded to your server all you need to do is point people at the index file and they can select the links to install the provisioning profile and app directly from mobile safari on their iOS devices. A much nicer experience compared to installing through the iTunes sync process.

UPDATE

After re-publishing updates to my apps several times, I was finding it a little tedious to re-type the full url into the XCode tool—plus I could never remember what I named the damn files—so I came up with this quick and dirty index.php script to do the grunt work for me:

<?php

$ipas = glob('*.ipa');
$provisioningProfiles = glob('*.mobileprovision');
$plists = glob('*.plist');

$sr = stristr( $_SERVER['SCRIPT_URI'], '.php' ) === false ? 
    $_SERVER['SCRIPT_URI'] : dirname($_SERVER['SCRIPT_URI']) . '/';
$provisioningProfile = $sr . $provisioningProfiles[0];
$ipa = $sr . $ipas[0];
$itmsUrl = urlencode( $sr . 'index.php?plist=' . str_replace( '.plist', '', $plists[0] ) );


if ($_GET['plist']) {
    $plist = file_get_contents( dirname(__FILE__) 
        . DIRECTORY_SEPARATOR 
        . preg_replace( '/![A-Za-z0-9-_]/i', '', $_GET['plist']) . '.plist' );
    $plist = str_replace('_URL_', $ipa, $plist);
    header('content-type: application/xml');
    echo $plist;
    die();
}


?><!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
        "http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<title>Install iOS App</title>
<style type="text/css">

li {
    padding: 1em;
}

</style>
</head>
<body>
<ul>
    <li><a href="<? echo $provisioningProfile; ?>">Install Team Provisioning File</a></li>
    <li><a href="itms-services://?action=download-manifest&url=<? echo $itmsUrl; ?>">
         Install Application</a></li>
</ul>
</body>
</html>

It’s nothing fancy so you’ll probably want to spiff it up but to use it (you’ll need PHP), just create a folder and drop in the index.php along with the .mobileprovision file, the exported .ipa and the exported .plist. To make things easy just enter _URL_ (uppercase url with underscores) as the “url” in XCode and the script will automatically fill in the proper URL as necessary. It doesn’t matter what the file names are as long as there is only one .moblieprovision, .ipa and .plist.

 }wjiGtdpcNrAlBJZ

into a nice GeoPoint array list:

private List<GeoPoint> decodePoly(String encoded) {

    List<GeoPoint> poly = new ArrayList<GeoPoint>();
    int index = 0, len = encoded.length();
    int lat = 0, lng = 0;

    while (index < len) {
        int b, shift = 0, result = 0;
        do {
            b = encoded.charAt(index++) - 63;
            result |= (b & 0x1f) << shift;
            shift += 5;
        } while (b >= 0x20);
        int dlat = ((result & 1) != 0 ? ~(result >> 1) : (result >> 1));
        lat += dlat;

        shift = 0;
        result = 0;
        do {
            b = encoded.charAt(index++) - 63;
            result |= (b & 0x1f) << shift;
            shift += 5;
        } while (b >= 0x20);
        int dlng = ((result & 1) != 0 ? ~(result >> 1) : (result >> 1));
        lng += dlng;

        GeoPoint p = new GeoPoint((int) (((double) lat / 1E5) * 1E6),
             (int) (((double) lng / 1E5) * 1E6));
        poly.add(p);
    }

    return poly;
}

If you need an encoder (or other decoders) check out Mark McClure’s page here.

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%.

One of the biggest hurdles with UiTextInput is that you don’t get the benefit of the great UI work that Apple has put in their core iPhone text inputs. There’s no text selection, magnification loops, copy/paste or any of those other things we take for granted when we use the default inputs. If you want advanced editing features you have to implement them all yourself—and it’s a lot harder than it looks.

Text selection, for example, is something that you’re probably familiar with if you’ve used an iPhone or iPad but have you ever stopped to actually look what’s going on? The subtleties of the touch interaction are very intuitive but may not be what you expect when you think about it. For example, here are few things you may not have noticed when editing text in something like the default notepad.

• When you quickly single tap, the carat is placed in the text where you tapped but it’s position is based on word boundaries. A mouse click in a word processor places the carat at the point where you clicked but a tap in iPhone OS places it in front of or after the word, depending on which end of the word was nearest the tap.

• Holding on a word will reveal a magnifying loop that gives you fine grained control over the selection. This is the only way you can place the carat within a word.

• The select/select all/paste menu will appear if you long-tap. As a result it will always appear after the loop is shown but could also appear if you touch and release just before the loop shows (of course you’ll be selecting and pasting on a word boundary in the latter case).

• The “select” option in the menu always starts by selecting a full word. Which word depends on where the carat is placed. If the carat is in a word then that word will be selected. If the carat is at the beginning of a word, between the space and the first letter, then the word following the carat is selected. If the carat is at the end of a word, before the following space, then the word preceding the carat is selected.

• Double tapping a word will immediately select it. If you hold and drag on the second tap you can select a larger range based on where you drag. Interestingly, the range selection also has a magnifying loop—but with a different shape—so you can have fine grained control at the end of the selection.

These are just a few of the subtle interactions that most iPhone users just do without thinking about. If you’re going to implement your own UITextInput be sure to closely look at the existing text inputs and how you typically interact with them as you’ll need to implement yours the way users will expect it to work.

When you have a large project, there’s often a lot of code that is very generic—an XML parser, network connection manager, location manager—that could be placed in their own shared libraries to use across different projects. This separation of code vastly increases the cleanliness of each individual project but also has other advantages including:

• Clear boundaries for business logic, api requirements, and unit testing.
• Less overlap in a single project when multiple developers are working together.

Moving the code to a library also removes it from the project with the “business logic”, allowing you to focus on the task at hand and prevent you from “tweaking” libraries just to accommodate the business logic of one particular project.

The iPhone SDK doesn’t support custom frameworks or dynamic libraries so you may not have thought it was possible but iPhone OS does does support static libraries and therefore allows you to write re-useable code—with a few caveats. This is how libraries such as Flurry or Google Mobile Analytics work.

The only disadvantage is that if you include other frameworks or libraries in your library you still need to include them ALL in your final project. Adding MapKit to a static library means you also need to add MapKit directly to the main project (which is why you need to add the SQL lib with Google analytics).

Creating your own library requires a few steps but it boils down to:

1. Create an XCode project to contain all the code for a specific library.
2. Create a static library target with the appropriate configuration.
3. Create a project that will use the library.
4. Import your static library project into your main project.
5. Link in the static library.

To simplify steps one and two even further, I’ve created an iPhone OS Static Library Project template for XCode. Download it and feel free to suggest any changes you’d like to see.

Usage instructions and a quick “How To” are available on the project page.

Enjoy.

Now all I have to do is call setFitTextToBox(true) on the TextFitTextView after allocation. Enjoy!

public class TextFitTextView extends TextView {

    static final String TAG = "TextFitTextView";
    boolean fit = false;

    public TextFitTextView(Context context) {
        super(context);
    }

    public TextFitTextView(Context context, AttributeSet attrs) {
        super(context, attrs);
    }

    public TextFitTextView(Context context, AttributeSet attrs, int defStyle) {
        super(context, attrs, defStyle);
    }

    public void setFitTextToBox( Boolean fit ) {
        this.fit = fit;
    }

    protected void onDraw (Canvas canvas) {
        super.onDraw(canvas);
        if (fit) _shrinkToFit();
    }

    protected void _shrinkToFit() {

        int height = this.getHeight();
        int lines = this.getLineCount();
        Rect r = new Rect();
        int y1 = this.getLineBounds(0, r);
        int y2 = this.getLineBounds(lines-1, r);

        float size = this.getTextSize();
        if (y2 > height && size >= 8.0f) {
            this.setTextSize(size - 2.0f);
            _shrinkToFit();
        }

    }
}