Google Nexus One

The Flurry analytics baked into RipChord have yielded another oddity. Besides people using the Blackberry 8230 to run Android apps, somebody with a Google Nexus One - the new Google phone, has installed RipChord! I was all set to sound the alarm "I know the name of the new Google phone" ...but quickly realized somebody beat me to it. Either way, it's nice to know it's being used at by somebody at Google.

Android on a Blackberry !?!

I was looking over the Flurry data from RipChord, and found something fascinating: 2 people that are running RipChord are doing it on a Blackberry 8230! Also, it looks like there are some people out there that have Android versions 2.0.1 and 2.1 already.

All About RipChord

Now that RipChord has been released, it's a good time to spill the beans on exactly what it does and how it works. I'm going to assume you know about music & chords already.

RipChord is meant to solve one problem - and solve the hell out of it! You've learned all the standard chord forms, but they're meant for standard tuning. If you're in a different tuning, all those chord forms change. RipChord can figure out how to play any chord in any tuning, at any position on the fretboard. But it throws in something extra. It determines every possible way to play that chord, including all inversions (which can be disabled in the Settings screen). For instance, in standard tuning at open position, there are 63 ways to play C Major, but in open C (CGCGCE), there are 141.

Right now, there are 27 chords and 16 tunings supported in RipChord Deluxe. Adding new ones is a quick process on our end, so if ever you need a tuning or chord that's not listed, let us know with an email or a comment, and we'll add it right away.

Currently, there are two versions of RipChord available on the Android Market: RipChord and RipChord Deluxe. RipChord Deluxe has the full set of 27 chords and 16 tunings and costs $1.99. RipChord has 2 chords and 4 tunings and is available for free. I hope that if you try out RipChord and find it useful, you'll upgrade to RipChord Deluxe. That will allow me to add new features that I've been thinking of, such as swipe to play and bookmarking chords.

Creating a boot-loading, always-on service

Let's say you've got an app that you'd like to run in the background. You'd like it to get started as soon as possible, and stay on whenever the device is powered on. It's an achievable goal, with one caveat. After installing the app from the Android Market or wherever, the user will need to run it at least once to give you a chance to execute some code that puts your foot in the door. Of course, once your app starts up, you're free to set up the system to make sure that your code is always running. There are really two parts to the issue: running the service, and turning the service on at startup. For today, let's talk about startup. If you poke around in the Android developer docs enough, you'll probably encounter the BroadcastReceiver class. The OS supports the idea of broadcast events, which can be caught by subclasses of BroadcastReceiver. Setting up that subclass is fairly simple - just extend BroadcastReceiver and override onReceive(), like this:

public class ServiceLauncher extends BroadcastReceiver {

@Override
public void onReceive(Context context, Intent intent) {

        // Start the service here
        return;
}

}

It's possible for a BroadcastReceiver to pull extra duty by listening for several types of broadcasts. If that's what you want to do, open up the Intent passed to onReceive() and check for the proper Action. Now, that's only half of the story. At this point, we have a class ready and able to listen, but the OS doesn't know that. To make the final connection, we need to add this snippet inside the application tag of AndroidManifest.xml:

<receiver android:enabled="true" android:exported="true" android:name="your.package.ServiceLauncher"> <intent-filter> <action android:name="android.intent.action.BOOT_COMPLETED"/> <category android:name="android.intent.category.LAUNCHER" /> </intent-filter> </receiver>

There seems to be a lot going on here, but when you really look at it, it's just an intent and an action, which you've most likely seen before, wrapped in this new receiver tag. All this is really saying is "We've got a class called ServiceLauncher, and it's going to get fired when the system boots." To sum up, there are two small parts, and that's all we need:

• Create a subclass BroadcastReceiver and override onReceive().
• Add a receiver tag for your subclass.

I hope this is helpful, and I'd be happy to take requests or questions about particular topics.