Those of you that know me very well might remember that one of my hobbies is amateur radio. There are many facets to the ham radio hobby and one of them that I’ve been involved with over the last few years combines radios and GPS data into a real-time position reporting system called Automatic Position Reporting System (APRS). To make a long story short, people equipped to use this system have specialized radios in their vehicles that read positional data from GPS units and transmit it out over certain frequencies periodically. Usually, these information packets eventually find their way to a series of servers that forward the data to connected clients for display on whatever mapping system the client has available locally.

This weekend, I spent some time creating an Adobe AIR application written in HTML and Javascript that connects to one of these servers and plots the position reports on a Google map. I haven’t had a chance to do much development with AIR up to now so I thought this would be a good exercise to see if I could create a usable solution.

The first hurdle was to create some method of translating the raw packet of information (which is a variable length string of text) into its component parts that I could then use. Below is an example of an APRS position report packet.

KI4TDG-9>APT407,WIDE1-1,WIDE2-2,qAR,N5AAA-1:!3546.23N/08654.00W>069/000/A=000800

This looks like a bunch of gibberish I know, but the data formats (there are multiple different types of packets that can be transmitted over the APRS system) are well documented. I wound up creating a Javascript object called APRSPacketParser.js (original name I know, but it works) that had a method called parse() that accepted a raw APRS packet like the one above. This method then used other methods such as extractCall(), extractTimeStamp(), extractPosition() and so on to reduce the raw string into a series of values that I stored in another Javascript object called APRSPositionReport.js. That took about 3 hours or so to write up. Because of the many different types of packet formats, the parser object still needs a lot of work, but for now it works on the 3 most common forms of position reports.

Once that was complete and tested, I created a regular HTML page to get my head around integrating with the Google maps javascript API. Within no time, I was able to have a Google map in my HTML page, centered on my location with a custom zoom level set. Once the map was there, I began experimenting with parsing sample packets I had hard-coded into the page and using the location data stored in the resulting APRSPositionReport object to insert markers on the Google map. So far so good and my total time so far was less than 4 hours worth of work. At this point I decided to quit for the night and try to tackle the AIR bits the next day.

Up to this point, all I’d really accomplished was proving that I could follow the instructions for using the Google maps API and that I could parse some sample packets into position reports. I still had to make all that work inside AIR. Upon creating a new AIR project, I put the HTML and javascript code that I’d been working on into the project and ran it, expecting to see a Google map pop up. Nope! All I got was a blank screen and a message saying that the variable “google” was undefined.

After a couple hours of head scratching and research, I found out about AIR security sandboxes and found some example code on how to successfully use assets in your AIR application that are not part of the project itself. The examples showed how to use the ParentSandboxBridge and ChildSandboxBridge objects to essentially create an “API” between pages to allow data to be shared between two sandboxes with different security levels. At this point, I had my empty Google map displaying inside my AIR application. With a little bit of bug fixing, the javascript code that I had used to create the markers on the map was working and I had 4 sample APRS packets parsed and plotted on the Google map. Total time to this point was somewhere around 7 hours.

Obviously, to be useful, the hard-coded position reports had to go and be replaced with a real-time stream of data from one of the APRS servers. This part was probably the easiest thing I did all weekend. The socket class in AIR makes it absolutely simple to create a TCP socket connection to a server. To create a socket object, I used the following code. The first line creates the object and the remaining lines assign methods to listen to various events that happen with the socket connection.

//Set up socket object that we'll use later when the connect/disconnect 
//buttons are clicked
socket = new air.Socket();
socket.addEventListener(air.Event.CLOSE, closeHandler);
socket.addEventListener(air.Event.CONNECT, connectHandler);
socket.addEventListener(air.IOErrorEvent.IO_ERROR, ioErrorHandler);
socket.addEventListener(air.SecurityErrorEvent.SECURITY_ERROR, securityErrorHandler);
socket.addEventListener(air.ProgressEvent.SOCKET_DATA, socketDataHandler);

I then created a button labeled “Connect” and set the onClick action to run the javascript method named connect(). The code for that method looked like this:

function connect(){
  if (socket.connected == false) {
    socket.connect("second.aprs.net", 20157);
    writeln("user NOCALL pass -1 vers AirPRS 0.01 filter r/35.625/-86.9847/150");
  }			
}

In my case I needed to connect to the server named “second.aprs.net” on port 20157. The last line of that method uses the writeln() method to send a string of configuration data to the server over the socket connection telling it about the kind of data I want it to send me. The server sends a new line of data across the socket connection each time it receives a position report from an amateur station. At this point, all I had to do was fill in the body of the socketDataHandler() listener method to forward each packet to another method I created that uses the parser to parse the incoming string and dispatch a message to the map to create a marker with the information contained in the APRSPositionReport javascript object created from the raw packet. Total time to this point was about 9 hours.

I spent another 3 or 4 hours adding error trapping and a “console” area to the application that got updated each time a new packet came in from the server so that I could see data flowing into the application.

All in all, I had around 12 hours or so of actual development time in creating a functional, though not very feature rich, application based on the Adobe AIR platform. If you care to take a look at what I’ve done or run the application, I’ve made the application and the source code available for download.

Here’s a screenshot of what the application looks like after it’s been running for a bit to pull in some position reports (click on the image for the full-sized view).

I already have a list of things that I want to add to this such as a preferences pane so that you can set your own center map point, control the radius around the center that you want reports for and so on. I want to use the built-in SQLite functions to store those values which will provide me with another learning opportunity with a different feature of AIR.

One of the ways of simplifying this that gained some traction among various developers prior to the release of ColdFusion 9 was to “var” a single variable at the top of the function as an empty structure then store any additional variables needed in the function inside it. Many folks, myself included, named this structure “local” so that it would be readily apparent that the values inside were local to that function. This approach worked fine and dandy on ColdFusion 8 and below.

I recently migrated one of my clients to ColdFusion 9 and not long after the client started getting isolated reports from his people having javascript errors in a data management application that uses AJAX-driven forms talking to CFCs. At first these were very isolated and we weren’t able to reproduce the error, but, as time went on, the reports became more widespread. As I was troubleshooting this over the weekend, I discovered that we were getting javascript errors when trying to interact with this RemoteFacade CFC about 40% of the time.

Using Firebug, I was able to watch the results come back from ColdFusion and noticed a very odd trend. Approximately 60% of the time, the JSON returned from the remote CFC call was as expected. In the other 40%, one of the main data structure names was an arbitrary, machine-generated name instead of the name we had specified in the code.

Here is an example of what we were expecting in the JSON returned from the RemoteFacade.cfc method:

{"DATA":{"CANEDIT":true,"RECORDDATA":{"Field1":"value1"} } }

This is an example of what we would get back from the same request when we would see the javascript errors

{"___IMPLICITARRYSTRUCTVAR5":{"CANEDIT":true,"RECORDDATA":{"Field1":"value1"} } }

See the difference? Our “DATA” key was named completely differently which caused javascript to throw some error saying that variableName.DATA did not exist.

After looking over the ColdFusion code for quite a while and doing some step debugging with FusionDebug I had an idea. I changed all the function-specific structures I had been using from:

<cfset var local = structNew() />
   ....
<cfreturn local />

to:

<cfset var ret = structNew() />
   ....
<cfreturn ret />

Once I changed those throughout the code base and reinitialized my application, all the javascript errors that we’d been experiencing across multiple request types went completely away.

I have an unconfirmed theory that in using the name “local” for my structure, ColdFusion was sometimes getting “confused” on what to return–ColdFusion’s built-in local scope or the method-specific variable I had named local. I don’t really have any way to prove that beyond a shadow of a doubt, but when I made the change, all my errors went away, so I decided chalk it up as a lesson learned for future development and move on to the next problem. Needless to say the client was happy that the issue was fixed and I can say I learned something that day.

As soon as I put the cfUniform code into the page, I started getting javascript errors in the console pane of Firebug. The error would state something similar to “$(document) not a function” or “$ not a function”. Now, I’ve not had a ton of experience with jQuery, but I have used several pre-built jQuery plugins in sites before and I had seen errors similar to this. Normally this error is caused by one of two issues. Either a) you’ve forgotten to include the script block to load the jQuery library or b) your code is loading the jQuery library twice.

I was able to use Firebug to verify that I was indeed loading it and loading it only once but couldn’t for the life of me figure out why I was getting an error. Obviously cfUniform wasn’t really at fault (the error pointed to a line in one of the cfUniform javascript files) so I knew it had to be something on my side. I did some searching on the phrase and found some discussions around jQuery’s noConflict() feature that allows you to reference jQuery with a notation other than using the familiar “$”.

After reading for a while, I opened the custom.js file that came with the site template and found the code below:

1
2
3
4

jQuery.noConflict();
jQuery(document).ready(function(){
   //contents snipped
}

Since I’m not using any other javascript libraries in this application that might conflict with using the “$” to access jQuery, I removed the noConflict() line, but that didn’t fix my problem. On a hunch I did a search/replace through the custom.js file replacing “jQuery(” with “$(” so that references to the jQuery library in this file would be accessed with the same syntax as in all the other javascript files. Lo and behold, all my errors in Firebug’s console went away and CFUniform began behaving as expected.

While I don’t understand all the underpinnings of why this worked, I’ll take it as my “lesson for the day” that in the future I need to always make sure that all the various jQuery plugins and code that is used in my applications need to reference the jQuery library with the same syntax.

NiftyPlayer is a free, open source Flash file that you can embed into your page and play MP3 files without worrying about what audio player is installed on the visitor’s machine. The best part for my situation is that the player is completely controllable through Javascript. That means that I could completely “hide” the UI provided by the Flash file by setting the height and width of the Flash object to zero and use custom javascript methods to craft my page to do exactly what I wanted it to do.

Having a Javascript API to the Flash player object means that you can simply added the following code toplay a track:

<a href="#"
  onClick="niftyPlayer('previewPlayer').loadAndPlay('fileName.mp3')">
      Play
</a>

NiftyPlayer also provides a way to register different types of events and pass a reference to a custom block of Javascript code to be run with that event fires. For example, you can register the “onPlay” event to change the source of an image on the page when a track starts playing and then register the “onStop” and/or “onSongOver” event to change it back when the track is either stopped manually or runs to completion.

Having this ability to completely hide the UI of the Flash object and control it with Javascript code was key for us as it allowed us to use NiftyPlayer in a design that had been created by an outside design firm without having to dive into the .fla file and update the colors, fonts etc originally used by the author. Using the Javascript API, I was able to control the source of an image (play and stop images) as well as update the CSS class of the div containing the currently playing track while it was playing and reset it back to its previous state when the user pressed the stop button or when the track finished playing.

Because of Flash’s near-ubiquitous install base, NiftyPlayer is a great option to easily add MP3 playback capability to your web application and know that it’ll “just work”.