Flash Lite 2 is a Presentation Layer

It may seem like an obvious statement, but it’s not. Flash Player has been a presentation layer for years. The difference? Nowadays, even without a backend, you can create some all encompassing applications. Utilizing the stateful client aspect, you can parse data, and show that parsed data. You can really push visualizations driven by data.

Flash Lite 2 has major limits to the above. For example, for and while loops; dangerous, will most likely crash. Think on that; could you live without for and while loops in your code? Your only recompense is using an onEnterFrame loop handler. A setInterval doesn’t count because it can fire multiple times in one frame, thus either overflowing the stack, or making your insanely low scriptTimeout limit to take too long. Can you do loops? Yes. In real world applications that you are used to in Flash? No. So far, the only surviving one I have is in re-drawing a List component’s children.

Data parsing. Data parsing, like sifting through XML, or converting strings, uses a lot of the above. Additionally, it has “a lot of data”. A lot of anything pre-Flash Player 9 is bad. Since Flash Lite 2 is basically 7, you have to not only keep that in mind, but also that you have about 2 megs of RAM. This makes even GETTING the data into Flash a challenge. For example, I’m learning to parse XML in PHP currently because Flash can’t do it reliably. It’s a good excuse to learn, but… dammit, 4 years of study, no longer applicable. Yes, yes, knowledge transfer will help in PHP, no doubt, but still, frustrating I have these insane powers that are now useless.

Communication. I spent 2 days messing around with Google’s Calendar API. The amount of header finagling, and HTTP Status response tweaking is insane. It certainly makes you appreciate companies like Yahoo who expose standard middle-tier API’s that you can call… and they… say it with me… “WORK!”. To be fair, there is this dude on the Google help forum who is a champ. I think he’s one of the dudes writing it too. Problem is, Flash & AS2, even with Fiddler, ServiceCapture, and Ethereal installed on my comp don’t fix the whack ass errors I’m getting. Instead, I search Google and find a plethora of PHP API’s for it. And after 10 minutes of tweaking someone else’s code into my own, walla, I’m up and running. I’m sure someone with something to prove could get it to work, but fuggit… Flash displays stuff well; let it do that. PHP is doing just fine getting data, handing Google happy headers, and sending the appropriate data to Flash. Since I used ARP, it wasn’t that big of a deal to change my Flash Lite AS2 code.

Since Flash Player 9 can JIT to ARM (phone processors), I really question if the above really will become obselete or not assuming Flash Lite 3 is some sort of Flash Player 9 build (at least gets the new AVM if not Flash Player 8’s display capabilities). Since ActionScript compiled to machine code is just that more lightning fast, does it really remove my loop barriers? Can I continue using XML DOM parsing (which is faster than E4X) once AVM+ comes alone? Flash Player 8’s new garbage colletor I’m sure might help, but frankly I’ve been seriously impressed with Flash Lite 2’s ability to reclaim memory after I destroy stuff. As usual, my biggest bottleneck is the phone’s slow arse processor, and my next to nothing sequestered RAM food tablet for the day. Does insane speed fix these problems?

I think not. 5 milliseconds vs. 15 seconds to use too much RAM is just a shorter time to use too much RAM. XML parsing would be nice to have back; I can rip out the data I need, and kill the XML reference, hoping that the GC removes it quickly. Even so, the amount of XML cannot be helped; some RSS / Atom feeds which are used in lieu of a lot of XML-RPC interfaces nowadays are pretty verbose. When a lot of these API’s are aimed at Java developers… well, I’m at the short end of the totem pole, and thus request the help of a middle-tier to do some of the heavy lifting; in this case, PHP parsing XML and making pretty headers.

Anyway, summary: If anyone tells you Flash Lite 2 can be used to make apps, they are incorrect without including some other part that does the heavy lifting like some middle-tier, or if the SWF is embedded in a Java / C shell on the phone / device. My definition of app is an application you’d make on the desktop, only for the phone. For example, her majesty’s blackberry has a Java app that Google makes that allows you to check your GMail. It’s pretty slick, works, and is a great app. Nothing complicated compared the actual web interface of GMail.

This is the 3rd time I’ve had both swords unsheathed, and charged full steam ahead, letting loose my nordish battle cry. All with a gung ho attitude at creating something cool with Flash Lite 2. Each time, I’ve hit a brick wall when it comes to data parsing and anything to do with loops.

It’s all good, it’s still a very valid presentation layer, and middle-tiers abound with heavy lifting & parsing abilities. Besides, ARP works just fine in Flash Lite 2, and I’ve got enough UI components to be dangerous. My advice; plan in advance to have a backend along with your Flash Lite 2 front-end.

9 Replies to “Flash Lite 2 is a Presentation Layer”

  1. Hi Jesse,

    Did you really mean: but frankly I’ve been seriously impressed with Flash Lite 2’s ability to reclaim memory after I destroy stuff. Or the opposite?

    You’ve also got me a little worried about an XML thing I am doing, the reliability stuff you mention thats just a loops and no of records thing isn’t it? Did you find there were any other issues?

    Cheers

    Nick

  2. Yeah, I really meant that. The fact that alot of components can be created and destroyed and still have enough RAM for doing other things is really neat.

    XML parsing, though is hit or miss. Since most use for loops and while loops to go through nodes, once she gets a little too revved up… boom. The parseXML, as you know, is the bane of every Flash Developers existence, and isn’t any friendlier on the phone.

    I say, parse in Ruby / PHP / CF / ASP, and send Flash some tiny strings you can parse via comma or pipe deliniation; make sense?

  3. Jesse,

    That was a terrific post. Flash Lite 2 is a pretty amazing presentation layer, and as you noted, the logic layer is evolving as well. Sure it is lacking compared to it’s desktop cousin. And it is still under powered compared to J2ME/C on a device, but it’s not as old/mature as those either. I hope to see the VM improvements included and optimized for the device processors as well. When that happens, writing applications like the GMail app will be possible, but even then it will be important to use a backend for optimizing for mobile bandwidth and other platform constraints. My biggie is seeing Remoting included in the future for small and agile data transfer.

    Great post. Great points.
    — Mike

  4. yeah agreed on the parsing front, even if its just for pure bandwidth purposes it makes sense to pre-prepare it and then send it down.

    The XML I am doing is local so its not gonna change without me testing it first. So no worries there.

    I guess on the memory front, yeah code does get cleaned up pretty well, but I am not so sure about other stuff such as audio, images etc… I think that side of memory could be better. Anyway, its a great presentation layer …so quick to do stuff, especially as you build up librarys and techniques.

    Cheers

    nick

  5. Fun topic! Just to note – I’ve had pretty reasonable success building a Flash Lite 2 application that uses AMFPHP remoting. It’s a simple application that allows a login, registration, and viewing users as a list. This was made possible by wrapping it in Zinc. The main issues were with the application layer design, such as on-screen buttons that a finger can press rather than a stylus. I can still see an argument against stand alone applications vs. web pages…..uh gotta go…take care

  6. Great article, thanks for sharing your real world experiences with the community. It’s good for developers to understand what’s possible and the workarounds necessary to create different types of applications.

  7. Hey Jesse,

    Great post.

    Ali Mills and I have been working on a distributed desktop client to Google apis in Flash Player 9 and ran into the same header problems that you described. As it turned out, we had to completely rebuild the HTTP client in ActionScript 3 using a socket connection. The problem isn’t with Google’s service, the problem is that the Flash Player doesn’t actually implement HTTP 1.1, and the features that it does implmeent, aren’t implemented correctly. The player will just automatically change your HTTP method, and doestn’t support PUT or DELETE. Hopefully Adobe will address this in future versions as this will impact our ability to integrate with many modern Rails apps as well.

Comments are closed.