Go ahead. Dump your wallet out on your desk and filter through your receipts and frequent-diner cards trying to find that one business card with that one phone number. Then proceed to pick up that phone and take on the monumental task of manually dialing each and every grueling digit. Pshhhh. That’s so last year.

Introducing SpeedDial. Run the app and click on a Google contact with a phone number. Your phone will ring. You pick up. The contact’s phone will ring. They pick up. Done. Want to call them again? Click their name. Done. Again? Click their name. Done.

Found a phone number on the web for ordering a late-night pizza? Ugh, the agony of lifting the phone and punching in each and every digit! Copy text, open SpeedDial, hit the call button. Done.

Sit back and enjoy the demo:

You will need to be on a phone system with a PBX (like a workplace) for the application to function. See the juicy details below for more info.

The juicy details

Calls are made using a simple RESTful API made available by a PBX (generally Asterisk-based). Once the PBX is in place and you’ve discovered the REST API used to make calls, you can pass the URL into SpeedDial as an argument. For example, let’s say I pass in this URL as an argument to SpeedDial:

https://phones.mydomain.com/api?cmd=call&dial_first={extension}&dial_second={destination}&password={pin}

When placing the call, SpeedDial will use the URL but replace {extension} with the user’s extension, {destination} with the phone number the user is calling, and {pin} with the user’s phone PIN. An HTTP request will then be made to the URL and the PBX takes it from there. By passing in the URL to the app in this manner, you can configure SpeedDial to your specific workplace without modifying the code and creating a new build.

As for other juicy details, SpeedDial stores credentials using an AIR encrypted local store and contacts are loaded using the Google ClientLogin API. The app uses Flex 4 and Robotlegs. The full source can be found here.

Before we get too far, be aware that these JavaUtils are currently for Windows only. Macs have their own version of the JRE that’s deployed through the Software Update feature so the process of detecting and installing the JRE is very different and is left for another day.

The Short Story

To get started with the utilities, first download the source by checking out the git repository or installing the sample application. If you choose to install the sample application, run the app and right-click on the stage to view the source.

The utilities include two executables:

1. whereis.exe – This is used internally by the tools. See the juicy details below if you care to learn more about this.
2. jre-blah-blah-blah.exe – This is the Windows JRE online installer found here: http://www.java.com/en/download/manual.jsp. This is the installer that is used to install a JRE of your choice if the user’s system does not have an adequate JRE already installed. Because it’s the “online” installer, it’s lightweight and lets you avoid bundling an entire JRE with your AIR app.

There are two main utility classes:

1. JavaValidationUtil – This is used to determine if the user has an adequate JRE installed. Call validate() and it will dispatch an event letting you know if the user has a JRE installed and if the version is sufficient.
2. JavaInstallUtil – This is used to install the JRE if needed. Call install() and it will dispatch an event letting you know when the installation is complete.

The Juicy Details

Let’s dig into the details of how this works. Support for running other executables as described below comes from the new NativeProcess in AIR 2.0.

Validation. The first chore is to validate whether the user has a JRE installed and, if so, whether the JRE is sufficient for the application’s needs. The developer provides the validation utility with a minimum acceptable version broken into four segments: major, minor, revision, and update.

Now we need to find the version of the installed JRE to compare. But first we need to find out where the JRE is installed if one exists. On Windows there’s an environment variable called PATH which contains several directories that should be searched to find an application when a command is executed in the command shell. When you open up cmd, for example, you can type “notepad” and hit enter. The fact that it’s able to open notepad isn’t magic. Windows simply searches the PATH directories for notepad.exe and then executes it.

We need to do the same thing to find the java executable (java.exe). On *nix operating systems this is pretty easy. There’s a simple tool called whereis that comes with the operating system that searches the paths to find a given executable. On Windows, not so much. Luckily, our friends over at Synesis have released a similar tool for Windows that allows us to do the same thing. We bundle whereis.exe with our AIR application.

We execute whereis.exe, passing in name of the executable we’d like to find (java.exe) as an argument. If we don’t find java.exe, the user doesn’t have a JRE installed–at least not in the PATH paths. And if a JRE does exist that’s not in those paths it could take a long time to find and we probably don’t want to mess with it anyway. If java.exe is found, we then execute it passing in the -version argument. Java will then output the version in a specified format that we can then parse. After we parse the version, we compare with the minimum acceptable version and dispatch appropriate events.

Installation. If no JRE is installed or the one installed isn’t adequate, the application would then generally notify the user they need a newer JRE and ask if they’d like to proceed with the installation.

If the user chooses to proceed, it’s time to execute the installer. But there’s a catch. In Windows, installer applications require “elevated privileges” before executing which means Windows nags the user asking for permission to install the JRE. If I were to double-click the installer when it was on the desktop, it would appropriately nag. However, if I execute the installer using AIR’s NativeProcess, nothing happens. No error, no output, no nagging, no installing, nothing. Is this a bug in AIR? Eight ball says signs point to yes, but who knows, maybe Windows is to blame.

In my search for a workaround I found that by executing the installer from the command shell, Windows again appropriately nagged. So then I tried executing cmd from AIR and having cmd execute the JRE installer by passing the path of the installer into cmd as an argument. What do you know–Windows nagged appropriately and off goes the installation as planned. When presenting this problem on the Adobe AIR forums, not receiving a response, then proposing the workaround, a member of the AIR engineering team seemed to think it was a good trick–nay, a great trick–so I guess that’s just the way we have to do things for now.

So first we use our trusty whereis.exe to find the location to cmd.exe. Then we use cmd.exe to execute our Java installer by passing the installer path into cmd as an argument. Windows prompts the user for permission and after permission is granted the installation proceeds as expected. After the installation is complete, we dispatch an appropriate event. Of course we also stay aware of fringe cases (like if the user cancels the installation) and likewise dispatch appropriate events.

Hopefully that’ll give you some good direction as you start your journey pairing your AIR app with Java. Now go make something freaking fetching awesome.

What is it?

RedLiteGreenLite is a small, simple app that allows a group of people to communicate the status of something. The status can be either red or green and the subject can be whatever. That may sound a bit general, but that’s the point. It can be used for whatever purpose your crazy mind can come up with. I’ll get you started:

1. At work, we have a single shower and a lot of shweaty guys after soccer. So we know when the shower’s available, someone can turn the status red when he enters the shower and turn it green when he exits. This way nobody has to keep stopping by the shower to see if it’s available. When it’s green, it’s available. When it’s red, it’s not.
2. At a call center, representatives are split into groups. When one group is on break, no other group is allowed to go on break. Again, when the status is red, a group is on break and other groups must continue attending the phones. When the lite is green, the next group is free to take a break.

The process is pretty simple: join a group. Other people join the same group. When others in the group change the status, you’ll be notified. When you change the status, others in the group will be notified. The status of the group will be persisted across sessions. In other words, if everyone logs out and then logs back in a week later, the status will remain as it was the last time it was set.

There’s no need to explicitly create a group. When you attempt to join a group, the group will automatically be created if it does not already exist.

The app is free. As in free free.

What technologies are used?

RedLiteGreenLite has a client portion and a server portion.

The client is the app users download and install on their computers. It’s built in Flex and published for AIR. It uses the RobotLegs MVCS framework and makes use of AMF remoting and messaging.

The server portion is built in Java using BlazeDS and is hosted on Google Apps Engine.

Ooh, that’s simply juicy. Tell me more.

Don’t mind if I do. First of all, BlazeDS is an open source implementation of AMF-based remoting and messaging. Natively it’s not compatible with Google Apps Engine, but I wanted to use GAE because it’s extremely scalable, it’s free (let’s be honest–I’m cheap like that–this is the main reason), and I wanted the challenge.

To get BlazeDS working on GAE, I recommend following Martin Zoldano’s blog post. Not only does he outline the steps you’ll need to take but he provides a critical patch to flex-messaging-core.jar as well. While you can find this patch re-distributed elsewhere, I recommend posting a comment requesting that he email you the patched jar. That’s how he seems to want to distribute his patch and I respect that. He’s really helpful and quick to respond so it shouldn’t be much trouble.

Once BlazeDS was set up and configured, I started to plan the architecture. First of all, I needed one client in the group to be able to send a message to the rest of the clients in the group. This could be achieved through the messaging service BlazeDS provides. However, messaging doesn’t store state; it just redistributes messages to clients. I needed the group’s status to be persisted to storage so (1) when a new client joins a group it can retrieve the group’s current status and (2) the group’s status can be retained even when no clients are connected.

By default, BlazeDS’s messaging configuration uses ActionScriptAdapter to receive and distribute messages between clients. It doesn’t persist messages. To do so, I extend ActionScriptAdapter and persist the status to Google Storage before sending the message out to the other clients. When clients connect to BlazeDS, they use remoting (not messaging) to retrieve the most recently persisted status for the group. After the initial status is retrieved, the client talks to other clients using the messaging service. You can see how this is set up in messaging-config.xml and PersistentASAdapter.java in the server code.

While GAE has been really nice to get the app up and running, it does have its downsides. To send messages between clients, BlazeDS can use a few different techniques:

• Simple polling. The client, at a standard interval, simply asks the server if there is any new information. The server responds to the request immediately regardless of whether there is new information.
• Long polling. The client sends a request to the server. The server holds onto the request until it has something useful to tell the client at which time it sends back the response.
• Streaming. The client opens an HTTP connection and the connection remains open. The server shoots messages down the connection whenever it has something to say. It’s an “infinate response”.

While each approach has its pros and cons, simple polling leaves a lot to be desired as it creates a lot of HTTP traffic. Unfortunately, from my testing and research, GAE doesn’t seem to support either of the other two methods. But hey, it’s free. If any of you have a java environment and would like to host RedLiteGreenLite so we can step up our game, let me know.

Last but not least, RedLiteGreenLite is open source. I’d love for you to fork the project and do something cool with it.

Now go have fun! Install the client using the badge at the top of the post or fork the project using the link below.

A while back, Guitar Hero hit the gaming industry by storm and kids flocked to learning the guitar. Sure, it wasn’t a real guitar, but it was still an instrument of sorts and kids were still learning hand-eye-ear coordination, rhythm, and other music essentials. The game was a huge success, bringing in over $1 billion in sales in the first 26 months and set an industry record.

Why such a difference in my experience learning how to play the piano years ago and kids learning the pseudo-guitar with Guitar Hero? Guitar Hero provides objectivity, benchmarking, competition, and addiction. You can play with your friends in a fun atmosphere. Piano Marvel takes these concepts and applies them to learning the piano. Students play along to accompaniment, see exactly which notes they hit and when they hit them, and earn trophies as they complete increasingly difficult exercises. They can practice whenever they choose and can even battle it out with their piano-playing comrades.

Now to the gushy technical stuff.

First, Piano Marvel is built using Adobe AIR and Java. Adobe AIR provides the high level of interactivity needed for such an application. Java provides the ability to communicate with a MIDI keyboard. Both are bridged using Transmission–AIR talks to Java, Java talks to AIR. All are deployed onto the user’s desktop with a single installer. Both Windows and Mac are supported.

Second, all the exercise content can be easily managed by the administrator. Let’s say the administrator wants to add an exercise. He plays a little ditty in Finale using his keyboard, saves the musical notation as a MusicXML file, saves the accompaniment in MIDI format, and uploads both files using an online admin panel. The next time students log in, they have a new exercise to conquer.

Third, all music notation is dynamic. In other words, an exercise is not just a big graphic of sheet music. Instead, MusicXML is loaded from the server at runtime. The XML is immediately parsed and notes, accidentals, lines, dots, and all notation the user sees is drawn to the screen at that moment. Resize the window and the music is redrawn, not simply scaled, to fit into the available space in the most elegant and readable way possible. Because the MusicXML is very comprehensive in describing a musical piece, we can also use the XML to determine pitch and timing for evaluating a user’s performance.

Fourth, the user can tweak the tempo, only play a portion of an exercise, toggle accompaniment and metronome sounds, get note hints, watch tutorial videos, and more.

Fifth, the application was recently nominated as an Adobe Max 2009 Awards finalist in the education category. Yeah, we’re kind of a big deal.

If that isn’t enough, you can watch my ugly cakehole yack about Piano Marvel below:

You can use a free demo account to get hooked then pay a low monthly fee after your trial period is over. If you check it out using this link you’ll only pay $12/month if you choose to sign up. That’s less than the gas you’d pay for to visit a piano teacher. All you need is a MIDI keyboard and a MIDI-to-USB adapter to get started.

Here are several screenshots of the app and its features. Props go out to Nate Ross for letting me steal his screenshots and captions.

Create a rich interactive music notation engine.

Display immediate feedback on all correct and incorrect notes that were played.

Have the ability to specify tempo, make music selections, and toggle fun accompaniment and metronome playback.

Create an environment that makes playing the piano addictive and entertaining