Blog

  • FlashVNC by Darron Schall

    Schweet… he finally released it. You can get the down low here, but basically Darron wrote a VNC client in Flash; it connects to the TightVNC server.

    In spite of the Flashcom pricing insanity discussions currently going on, this proves 1 thing to me:

    You can create a multiuser, video enabled application in Flash without using Flashcom. Snap, crackle, pop, bee-otch!

    $10 bucks says this doesn’t make it to Slashdot, and does to Digg.

    Will some *nix g33k hurry the f’up, go work for Macromedia, and port the Flash Player 8 to Linux, please? They are still hiring. Thank you!

  • XMLHttpRequest vs. XML vs. URLLoader: API Comparisons

    Trying to go for the jugular here. AJAX utilizes XMLHttpRequest class for its asyncronous communication, Flash Player 5 – 8 use XML class, and Flash Player 8.5 utilizes URLLoader (and friends). Let’s compare the things that are different. Request headers, for example, are very similiar for all 3.

    Aborting the Call

    XMLHttpRequest has abort. XML does not. URLLoader has close which effectively does the same thing.

    Syncronous & Asyncronous (everyone freeze vs. I’ll get back to you)

    XMLHttpRequest has the ability to be syncronous or asyncronous. XML & URRLoader do not, they are always asyncronous.

    Event Handling

    XMLHttpRequest has a onReadyStateChange event that fires when the loading state of the object has changed, at which point the developer will check the readyState property to determine which of those 5 different states it has changed to (uninitialized, loading, loaded, interactive, complete).

    XML has 2 events, onData and onLoad. XML, if created as an instance, is always initialized. XML is either loading XML to and from the server, or it’s not, via the loaded property.

    URLLoader has 7 events for various states & times of the loading operation.

    Return Data

    XMLHttpRequest gets its text response data in the responseText property.

    XML gets its text response data as the first parameter to the onData event, at which point you handle it, or parse it, set loaded to true, and call onLoad with a true as the first parameter.

    XMLHttpRequest gets its xml response data as the responseXML property.

    XML, as it is an XML-DOM object already, is ready to be accessed by DOM methods as soon as the onLoad method fires with a true as the first parameter, meaning the data was successfully downloaded & parsed.

    XMLHttpRequest gets browser responses via the status property.

    XML doesn’t; you have to parse them from onData. There are some common return values found in the XML.status property.

    URLLoader gets an httpStatus event.

    URLLoader’s complete event is complex, however, in that different requests could of been made (a simple HTTP request, a binary stream you intend to parse, a GET/POST action that will have URL encoded variables attached, or waiting to get raw XML). Each request operation has a class to handle the common operations for each.

    Conclusions

    The fact that both XMLHttpRequest & URLLoader have abort functionality makes them much better than XML. Not being able to abort requests wastes bandwidth, as well as server-processing. Additionally, I have yet to see a conclusive report on how much bandwidth is being saved/added to a web application from going to a many small requests/responses with fewer page refreshes model vs. a few large request/responses with more page refreshes model.

    While I peronally cannot see a reason why you would ever want to intentionally have code block, thus locking not only your script running, but also your GUI, I do know a lot of developers who do. XMLHttpRequest scores a high mark via this boilerplate aspect in the ability be syncronous or not.

    XMLHttpRequest & URLLoader both score high marks in having the ability to see the http status code, where you can’t (natively anyway) with XML.

    URLLoader I think wins here merely from the fact that you know what the heck is going on. The myriad of events, with the information each event object contains, gives you a lot more context to what is happening with your request. Knowing when it’s done downloading, when you’ve got a piece of data that’s started to download, being notified of an http status code, getting an ioError when she blows up, getting an open event when the data has started to download (after the data you have sent is done sending), getting more than 1 progress event for longer loads with a current and total amount of bytes, if known. No one wants to know about securityErrors, but they are there.

    XMLHttpRequest has you continually check a property on each status change; that in itself doesn’t really give much context as to what is going on, and you must investigate this yourself with code vs. being told.

    XML? It either works or it doesn’t, and you have sparse tools to know what really happened.

    If I had a choice, I’d choose to use URLLoader to do asyncronous loading of data on the web.

    Sources

  • Job: Macromedia Flex Developer

    Title: Macromedia Flex Developer

    Business solution firm is looking for Macromedia Flex Developers.

    Mandatory Skills:

    Macromedia Flex, Cold Fusion, Oracle and SQL, Strong Java, and Web Services/XML would be definite assets.

    *EXPERIENCE WITH MACROMEDIA FLEX IS MUST*

    Please apply with updated resumes with desired rates and contact details at vsrivastav@lintas.com. Descriptions of your previous Flex work and Flex projects are required in your application.

  • Jonathan Boutelle on Flash & AJAX

    Nice to see people speaking about their development experiences, ecspecially when using AJAX & Flash together, something that makes absolutely no frikin’ sense to me. This gives a great insight into how people who are not Flash devs expect to use Flash, and how they expect it to work in their project flow. Fascinating stuff.

    Since I’m a Flasher at heart, I must respond to his points.

    Sockets: XMLSocket is an alternative to Flashcom. It’s been in Flash since 5, and like AJAX’s XMLHTTPRequest, both send and receive XML strings, except XMLSocket in Flash is a persistent socket and allows for server-push instead of the simple request/response. There are a lot of free & professional socket servers out there for this, EXTREMELY cheaper than Flashcom, ecspecially Flashcom 2 since that pricing model doesn’t really facilitate data-only applications anymore.

    Additionally, Flash Player 8.5 has binary sockets built-in; expect existing binary socket servers to see a re-surgence in use, and new ones built just for Flash server alternatives.

    Rapid Development: “if your code needs to change quickly, or if it needs to be ready in a few weeks, Flash is a poor choice.” Huh? I’m obviously subjective because I’ve been a Flash developer for years, and my HTML skills languish. As such, doing things in Flash, to me is quick, easy, and flexible, whereas me doing HTML & JavaScript goes a lot slower.

    I will agree, though, that Flash has it’s code too tightly meshed to the GUI; Flex is indeed faster for prototyping form based applications, and the flexbility has increased 10 fold since your code is not tied to how you lay out your GUI.

    Text handling: While I agree text usability in Flash blows, mainly from an integration standpoint, it’s rendering rocks. If you use device fonts, it is extremely readable, even at lower font sizes (14 and below). Unfortunately, the IDE’s default behavior is to use embedded fonts, which has lead to the “Flash shows blurry fonts” impression, which unfortunately is the fault of developers, not the technology. Additionally Flash Player 8’s font rendering engine rivals that of PDF, even with small font sizes.

    Again, it’s really great to read these types of articles; both from the AJAX dev comparisons to getting insight into how developers use the tools & their expectations of them.

    Flash: what is it good for? (absolutely something!)