AIR API changes still challenging

I recently cracked open my MAX ‘INPSIRE session’ app code to update it to Ribbit’s Beta2 API. The application, if you recall, was called Ribbit AIR Filter. It used AIR features including the HTML control and script-bridging to load in a web page (I used a Y! local page for the demo). Then by clicking a button, I used a regular expression to scan through the DOM of the web page with ActionScript and replace each phone number (matching pattern: ‘/(\(\s*\d{3}\s*\)|(\d{3}\s*-?))?\s*\d{3}\s*-?\s*\d{4}/g‘) found with a colorful button showing that same number. That feature in itself was actually pretty easy and effective to code. When that new button was clicked, a panel slid out to reveal some Ribbit functionality; login to the service, call the number clicked (again from within the web page), and even add that number to your Ribbit contacts.

So, upon cracking it open and adding the recent Ribbit API (Beta2.01), I was met with a few, simple and expected issues. I had to change the namespace to com.ribbit.api.* as well as change the contacts call (from getAllContactsIds) to the new, more search oriented getContacts. That was it… except upon fixing those, a number of problems popped up in FlexBuilder.

It seems that the original technique of script-bridging I used was no longer supported in the latest AIR beta3 release. I had coded the app just before MAX on a pre-release of Beta2, so I was expecting some changes, but certainly nothing as complex as what I found. Do to some API name changes — some undocumented API changes — I was left feeling around to get the app to working order.

1. The property htmlControl of the HTML control instance was changed to htmlLoader. I guess that it was the right change.

2. The event domInitialize of the HTML control instance was changed to htmlDOMInitialize. I guessed on that one as well and it worked.

3. The property javaScriptWindow of the HTML control instance was gone. I found a new property called domWindow, tried that out and the debug called me out. It didn’t like that. So I spent the next hour trying different properties (and variations of properties) looking to restore the very important technique of retrieving the entire DOM (string) of the loaded HTML page. It was especially frustrating that while scanning the variable output in debug mode, I couldn’t find any clue to retrieving this value. I expanded my search for a solution and started digging into the forums. I finally pieced a couple of examples together and discovered the answer.

The previous working:?
HTMLControlInstance.javaScriptWindow.document.body.innerHTML

was now:
HTMLControlInstance.htmlLoader.window.document.body.innerHTML

Not the most logical re-mapping of functionality, but once it was working, I seemed to forgive the annoying change and move on. A few more simple steps and the app was back to full working order, breathing again for the first time since October.

Here’s how the app looks and works:


1) The web page first loads in AIR…


2) Each number is replaced with a button which is populated with that number…


3) Upon clicking the new number button, a panel slides out so you can call with Ribbit!

After a little more polishing, I am happily going to release the full code. For now, you can download the Ribbit AIR Filter app here: http://developer.ribbit.com/projects/RibbitAIRFilter/. A Ribbit developer account is required.

?