Quality Reads

Saturday, June 30, 2007

Execution Times in Apollo vs. Flash

I just wrapped up a 12hrs. coding session at work. We're creating an application that provides ROI (return on investment) calculations to prospective technology clients. Its standard practice these days to sell software based on value even though selling on features is a heck of a lot more fun, which is where the ROI calc. comes in handy.

Behind the calculator's UI, there are a plethora of events being generated to update the key benefits used by the buyer. As we've continued to work on larger calculators (more benefits), the processing time in AIR has lagged even when the Flex seems to run unhindered. So tonight I did a little testing to see how significant the difference was, I was shocked to learn that AIR executed the same functions as the Flex application at a speed ~ 54% slower. The "native" application is running slower?!? Even more bizarre, the execution time goes back to normal when I load a secondary SWF inside the AIR application to handle the calculations. Very weird and disheartening to say the least. I don't have the tests at home otherwise I'd post them but if anyone has a reason for this discrepancy. Do tell.

You can expect the source for my tests tomorrow. Until then, you might want to think about creating a wrapper for calling functions w/in a SWFLoader. Here's a useful article about how to make calls from the child app. to the parent.


Thursday, June 21, 2007

Living in Boston...

I guess I haven't taken the time to make mention of my new job (or write a post for that matter). I packed up my bags about a week ago and made the long haul up to Boston, actually it was three short hauls. Besides the psycho that yelled at me for "borrowing" her parking space while I moved my furniture into my apartment, everyone I've met has been great. A trend I'm sure can't last forever but I'm enjoying it for now.

My new company, Pier Inc., creates Rich Internet Applications using Flash (Flex, AIR). We've got an impressive list of Fortune five clients and skunkworks to boot! I've got to get back to work for now but you can expect some great Flex/AIR tutorials to follow.


Thursday, June 07, 2007

Managing Markers in Google Maps

I just spent the last four hours trying to coerce Firefox into properly displaying 600 markers on Google Maps (using GMarkerManager). In the end, I came up with the same response "too much recursion", FF's words not mine.

My original process was to create the map, so users have something to look at, then make an XHR call for all the markers I wanted to place on it. Logical, I thought at the time. For some reason, making the XHR call after the map is instantiated seems to freeze up my computer (dual-core Mac). A very bad sign considering the average user doesn't have the power setup that I do. I tweaked a couple functions to improve performance but nothing seemed to work.

Then I found this web page (and demo) which provides a VERY simple solution. Load the data up front then initialize the map. Presto, GMarkerManager kicks in and everything works perfectly. If you don't feel this answer is satisfying...I hear you. Frankly, it doesn't sit well with me either but it works and the load time isn't horrible.

Hopefully, someone will see this post and avoid getting brutalized like I did.


Wednesday, June 06, 2007

Is Google Expanding Too Quickly?

I want to say no. Really.
I want to believe that Google is the company of the future. Nimble, smart, and opportunistic. Shifting resources on a dime to push whatever technology is on the horizon.
Then I get a reality check:
You'll notice something strange in the top left corner of the page. Yep, thats some Javascript for their Google Analytics account. Upon further inspection, I discovered they forgot the closing script tag. Pretty sloppy. I'm not saying I haven't thrown pages up before they were ready or that I don't make mistakes. But come on. Someone should have QC'ed the page and noticed that.
I guess the future isn't today.

Friday, June 01, 2007

Updated: Custom Event System for Prototype

After using my original Event System for a little while I realize that I structured the original Classes all wrong. For some reason, I though it was a good idea to pass the event dispatching responsibilities off on the Event object itself. Bad idea. So I updated the code, all 2K of it.

Here's the update:

* @author toddcullen
CustomEvent = {};
CustomEvent.Events = {};
CustomEvent.Events.Base = Class.create();
CustomEvent.Events.Base.prototype = {
initialize : function(){
this.type = "CustomEvent.Events.Base";
CustomEvent.EventController = Class.create();
CustomEvent.EventController.prototype = {
initialize: function(){
this.listeners = $A([]);
addEventListener: function(n, f){
this.listeners.push({name: n, callback: f});
removeEventListener: function(n, f){
this.listeners = this.listeners.without({name: n, callback: f});
dispatchEvent: function(n, e){
for(var x=0; x<this.listeners.length; x++){
if(this.listeners[x].name == n){
var EventController = new CustomEvent.EventController();

You can create any type of Event you'd like. Its just an object you pass from the event target to the listener. Here's an example usage where I created a DataEvent Event Class:

* Data Event
CustomEvent.Events.DataEvent = Class.create();
CustomEvent.Events.DataEvent.prototype = {
initialize : function(data){
this.type = "CustomEvent.Events.DataEvent";
this.data = $H(data);

Event.observe(window, "load", function(){
EventController.addEventListener("BasicEvent", testListener);
EventController.addEventListener("DataEvent", testListener);

Event.observe('basic', 'click', dispatchBasic);
Event.observe('data', 'click', dispatchData);

function dispatchBasic(){
var event = new CustomEvent.Events.Base();
EventController.dispatchEvent("BasicEvent", event);
function dispatchData(){
var event = new CustomEvent.Events.DataEvent({info : 'HELLO WORLD!'});
EventController.dispatchEvent("DataEvent", event);
function testListener(event){
alert("event type:"+event.type);
if(event.type == "CustomEvent.Events.DataEvent"){
alert('event data: ' + event.data.inspect());

The HTML is simply an anchor with an id of "data" and an anchor with an idea of "basic". This system is really useful for an HTML UI that has to be flexible. Minimize/eliminates the need for objects to know about each other. They only need to "know" about the EventController.

Snag the full demo here.


Apollo/Gears Integration

Check out this press release on Apollo/Gears integration.

Gotta run!

Seriously, I have to leave this time.

Gears is Great for Bandwidth

Real quick post, I'm on my way into the office.

Most people are aware of the growing bandwidth issue facing ISP's. With high def videos and full scale web applications, people are using more bandwidth today per capita than every before.

Enter Google Gears, reduce the amount of bandwidth needed for large scale web apps by downloading it once and serving the static files locally.


::I'm working on a versioning system right now, so applications will know when to update themselves to the latest version::(Its apart of the API)