Flash Lite 2 Development – Thoughts on the Google Calendar Aftermath

Now that the Flash Lite contest is officially over, and I’ve submitted my entry, I wanted to take some time to discuss my thoughts on the whole development process. The goals are to let others know what my current feelings are on the industry, on development for devices, and to hopefully provide context on if Flash Lite development really matters, and how, in the whole Flash Ecosystem.

My entry for the Flash Lite contest was a Google Calendar application. As the code base currently stands, it allows you to see your appointments as well as create new ones. The data comes from your Google Calendar data. If you have GMail, you have a Google Calendar. In the busy past 3 months, I’ve come to depend on Google Calendar to keep my life on track; there is so much going on right now that it really helps to keep me organized and set availability expectations to others. I’ve tried a variety of online calendar applications as well as Outlook’s built-in one for PC, and iCal (?) on my Mac. To me, Google Calendar is the best strictly because it’s accessible from anywhere, on any computer whether mine or someone else. I didn’t really get the chance truly battle test any of the other online offerings so I still haven’t settled on Google Calendar being the best, but you’d be surprised how much a “calendar” hyperlink in your web browser’s email window really sways your opinion.

I’ve used Gmail’s BlackBerry version which allows you to read your Gmail on a BlackBerry. BlackBerry’s in general are super hot, and for such a small device, have a pretty powerful & speedy web browser. I can read MXNA for example although not all blogs render the same, it’s still usable. I was immensely impressed with the application, and it “felt” like GMail did even though this was a tiny device with Cingular’s EDGE (which is good enough for this type of data application, regardless of what the iPhone critics say).

I saw someone blog a few months ago a Google Calendar application they created with Flash Lite 1.1. I was blown away. I had the idea 3 days before of building a calendar application on my phone, and was then investigating if any of the calendaring web applications had an API I could use. I found Google’s did, although, the documentation wasn’t in the API style I was used to. Amazon.com for example assumes you are a programmer, and shows you the methods, descriptions, parameters, and the responses. They even provide example code in multiple languages. Thanks, that’s what I was looking for.

Google’s, however, takes a more work flow approach and walks you through using 3 example scenarios such as getting your list of calendars and getting entries (aka events, appointments). There is a strong emphasis on how it works using the Java client API as well as expecting you to investigate their REST like HTTP protocol XML formats which are very disparate, spread out, and verbose. To me, this makes it extremely hard to get up and running quickly; you really have to get intimate with the GData format, and “care” about how it all works. I really don’t think this is necessarey, but they do. Frankly, that’s not how you document a public API. However, they compensate by having a very helpful email list. A lot of the guys on there answered my questions very well in a reasonable period of time.

I quickly gave up on their SMS gateway… I just didn’t get it. I saw the dudes who wrote the Flash Lite 1.1 used it heavily. To me, though, that broke the experience, and I refused to accept that as a viable way of doing things. The SMS stuff on my phone didn’t send SMS messages from the Flash Lite SWF; instead, it opened my phone’s text messaging app. Screw that. I wanted to create an all encompassing application; a self-contained, good experience. Breaking out to other apps for helper functionality was not what I wanted to do.

I started experimenting with hitting Google’s API directly from Flash. I had very positive results. Creating the XML by hand was a royal pain in the neck, but once I had reproducible test cases (basically a FLA specifically created to test one aspect of Google Calendar’s API), it was pretty easy to build upon that foundation.

Psyched, this was the motivation I need to have a valid need to create some Flash Lite 2 components. Over a year ago, I had tried to do this with Richard Leggett. I quickly lost interest, though, because at the time, non-device Flex & Flash work was (and still is mind you) in high demand. There was basically no way I saw to make any return on investment on what I coded. Even the community was then focused more so on Flex development, so there really wasn’t a large device developer audience. There still isn’t I don’t think.

Last summer, I had spent over 3 months in Detroit working at a design firm. We were “re-skinning” an extremely large, data-driven Flash website for a car company. The code was unusable based on our goals, so I proceeded to create a usable component framework. We couldn’t use the MX components, which I still love, because of file-size reasons. I knew I could create the same set, again from scratch, insanely faster than the first time, and target them for devices. I set out in November in my spare time to create a new version specifically made for Flash Lite 2. I named them “Shuriken“, based on their goals of being fast, lightweight, and providing many different components to help common developer needs.

About the same time, I started to really get tired of touting Flash & Flex integration. The number of companies flocking to using Flex was insane. While a wonderfully, positive sign, the majority of those companies either had no concept of what graphic designers, 3D, and video compositors brought to the table, the “Rich” in “Rich Internet Applications”, or just didn’t care. The level of control using CSS, skins, and the ways of skinning components using NJ’s article as your guide was apparently covering 90% of the use cases out there for mid to Enterprise size applications. I still think that some of the use cases are flawed, but that’s merely because the industry still needs to grow. For some, CSS and/or just skinning is fine. The same thing Microsoft wants to happen has to happen with the Adobe customers as well. Software companies bringing multimedia skill sets on board to augment, and thus complete their teams. Programmers alone cannot fully leverage the Flash Platform or WPF platforms without design talent. What we all think is cool now won’t be so in a year, and will be old hat. The fact that these long term, large & highly experienced development teams are integrating Flex into their work flows & projects vs. modifying their work flows & projects around Flex is a testament to how “right” Adobe was and is in creating Flex for that market.

With that said, as these companies start wrapping their head around Flex, what it offers their company, and come to the realization that Flex is used to create “applications”, not websites that hit back-end services, things will truly start moving forward. The 10% that either do get it, or just have valid design use cases, have been very keen on getting someone like me on their team because of design & Flex background as opposed to Enterprise Java development experience. This is a very positive thing for all the Flash Developers out there with similar backgrounds. We have a lot to offer these companies, and they us.

…that said, that 10% is small right now. Even worse, most of the start ups are still using Flash Player 8 because of player penetration numbers compared to Flash Player 9. So, I needed something to talk about at WebDU 2007, the Asia-Pacific conference down in Sydney, Australia. I was already speaking about Flash & Flex integration at 360 Flex, and was pretty tired of repeating the same thing, knowing that things will change in due time, just not fast enough for impatient-me. About the same time I started seeing Alessandro and others blogging about all of these new devices coming out with Flash Lite 2 capability. I still don’t know enough about Verizon’s BREW platform to really have an opinion, but I DO know that a lot of the mobile operators in the US were seriously struggling to capitalize monetarily on their data offerings for the average consumer. There were little to no incentives for the average Joe to utilize his Internet enabled phone, and these carrier’s are left wondering why? At least, that’s what the financial reporters seemed to think. Like any big company, usually the ladies & gents in the trenches do understand and somehow politics seems to sabotage the whole affair for some. Sometimes they do too good, like T-mobile who recently is thinking about preventing all 3rd party applications from accessing their data network.

The nail in the coffin, though, was my last day up in Detroit, at the larger design agency. I asked their Director of Engineering if they ever thought they’d do any Flash Lite work. He actually had a pretty neat history back in ’96 doing a lot of ahead-of-its-time device work, so I really valued his opinion. He said, “Come back in a year.” I was extremely surprised by his answer. I couldn’t believe that soon. I managed to sputter out, “How come a year?”. He proceeded to explain that the car company’s CEO wanted to see a picture of a car that was at a dealership. His daughter then sent him a picture to his phone she had gotten over the Internet. Apparently this was “ground breaking” technology to him. Additional corroborative data was the highest selling ring tone & wallpapers were of the car company’s premier car offering. People want to customize their phones, and they are willing to pay for brands they know and love. Those brands in turn want to further that relationship and provide offerings to not only make money off of the brand, but keep retention. Agencies naturally will use whatever technology to do so, and it seems later this year is ripe for that for more of that in the US. Frankly, I still think that’s Flash Lite 1.1 which I refuse to touch with a 10-ft. pole. Regardless, you know if engineering divisions at large design agencies are charging in, it’s only a matter of time before development firms get involved for more sophisticated offerings.

Suddenly, I knew what I was doing was relevant. Maybe not necessarily now, but it’d only get more relevant over time. As someone who loathes doing things that have no point, suddenly I had nothing holding me back. Even managing to talk to Dale Rankine at MAX 2006 and hearing an honest response that there really wasn’t a business market for what I was doing didn’t matter. While I greatly respect his opinion since he’s one of the few dudes I know actually making money off of Flash Lite, the signs were all there. They have been for years, in fact, so much so Macromedia and later Adobe pretty much deafened us with “It’s coming”. It eventually became extremely annoying and turned a few of us to perceive that as a cry wolf scenario. It was a pretty easy rebuttal: “Show me the money.” Oh… well… um… working with Operators… go to Japan… blah blah blah.

Regardless, I’m tired of waiting on the Enterprise to learn that they need Graphic Designers, Flash Designers, and/or someone to mediate the 2 groups in Flex work so figured this was something to occupy my time until things change. Besides, I like a challenge, and Flash Lite is f’ing hard. So much so, it became purely masochistic at some parts of development.

How hard? Well, as I started implementing some component tests around my early successes in talking with Google’s API in Flash, I quickly started running out of RAM and CPU. The script timeout error on a phone is “Problem with Content: 4”. You see that, you’re either using too much CPU or out of RAM. There is no way to check, either, other than running in the emulator, and then testing on your device. There were a plethora of culprits, but I was basically at my first crossroads. Do I use a pure Flash Lite solution, or do I get a middle-tier involved to reduce the amount of data I have to parse on the client, since parsing itself isn’t so straightforward on a phone? For example, if you thought XML.parseXML was bad, try looping through nodes when loops in general have a high propensity to make a stack overflow on your phone. You have to do the whole “parse over frames” bit if you want the code to scale at all. After realizing that I needed to ensure users didn’t have high data bills since T-mobile appears to be the only one currently offering unlimited data plans in the US, I realized a middle-tier to convert the data for me was a very prudent move. While Flash Lite is nice in that it doesn’t suffer from the security sandbox that desktop Flash does if it’s running in the Flash Player on the device, it didn’t really matter. I’d still have to use my server to make the app work. This is what motivated me to write about Flash Lite being a good presentation layer… because I failed to see how the hell it could be anything else if it couldn’t parse simple XML chunks AND show a few components. Apparently many others do just fine, so you can see how very little ActionScript they are using.

However, even smaller XML chunks still made it fail on a lot of the other areas. So, I then tried JSON. I had some initial successes since there were some pretty good JSON libraries for PHP and ActionScript 2. I quickly ran into the same problem, though. Any type of looping quickly taxed the already over burdened CPU, in this case, JSON parsing a string to objects. My second crossroads was to just ditch all XML and JSON, and use basically primitive url encoded variables. LoadVars ‘ decode method is pretty fast, and since it’s done in C inside the player, it’s wicked fast compared to manual ActionScript parsing of XML or JSON over frames.

This is also about the same time my programmer Ego as Branden Hall likes to call it started to take a nose dive. I started finding the more OOP I added (ARP framework, multiple base classes, copious invalidation methods), the less my application scaled. This is contrary to what I’ve learned the past 6 years. Basically, the precept of OOP is that the more object oriented you are, the more your application can scale, and be resistant to change. However, the overhead caused by OOP has a direct impact on the performance and RAM usage of your Flash Lite 2 application. For example, Flash Lite 2 is basically Flash Player 7. You can write in ActionScript 2, but it compiles down to ActionScript 1 prototype bytecode . So, classes are really just prototype objects in a chain. If you call a method that is not on the current class, the player has to walk up the prototype chain. This takes a lot of CPU. Furthermore, prototype classes actually exist as objects vs. traditional classes which are really just blueprints. Therefore, more classes means more RAM usage. Creating instances of these classes uses more RAM than smaller, less OOP versions. You thus are using more RAM with more OOP classes who they themselves use more RAM to actually instantiate, thus leaving you with far less RAM had you used a non-OOP approach. This was the first time I was ever punished by using OOP (well… not counting the time I tried to code nicely during an insane deadline in which I had no chance of winning, but death marches don’t count in this case).

I really started getting frustrated, and feared that over a month’s worth of work was for naught. I managed to see interest in Greg Burch from Adobe’s Mobile division. So, I gave him a call, and discussed my approaches, and asked for advice. It was a great series of conversations. He did, however, eat up my code and spit it out. I had basically taking the Flex 2 component invalidation model where you set a property, set a dirty flag, iterate through all dirty flags next frame, and then run the appropriate invalidation drawing methods. This ensures that you have no race conditions, and that you only draw once per Flash Player frame redraw. The problem? The invalidation framework took too much overhead, and actually detracted from performance rather than shield developers from the complexity of the Flash Player rendering engine. For 80% of the properties of a class, it had an associated dirty flag. While I could potentially not set their default value to false and delete them once validating without even having to change my if then statements, thus saving RAM, their creation during invalidation added to much still. The getter / setters also had overhead. While a wonderfully clean way of accessing components, they themselves added 10 milliseconds of execution time: 5 for the setter, 5 for the automatically called getter. This cascaded on down to other components used in composition.

So, I let Greg take a crack at optimizing my framework. He pretty much deleted all of my dirty flags, and basically gave invalidation an afterthought relying instead one the developer not to set a property 50 times in the same frame. While this significantly reduces approachability… he technically was right about the use case scenario. Most people coding AS2 for phones knew what they were doing. If not, they weren’t doing a lot of coding anyway, and thus wouldn’t have code scalability issues. We debated & discussed various invalidation strategies, and I just settled on the old MX one of calling invalidate. Simple, straightforward.

I tagged the branch in SVN, kissed it goodbye till Flash Lite 3, and proceeded to spend the next 2 weeks re-factoring the entire code base, both the Shuriken component framework, and the Google Calendar code. Upon finally reaching a point where I could compile again and run code, I found my RAM usage was greatly reduced, and I could put more components on stage at one time. During this time I even managed to talk to some developers in the in the Flash agency world to see how they were coding. To my surprise, a lot of the old ways of coding still thrived in the AS2 world, so over another week, I quickly dropped more of my ego and really didn’t mind typing my_txt._width vs. my_txt.width. That underscore may not appear as a big deal, but… well, trust me, it is. It’s really really hard to go back to the old ways of coding when you’ve been taught the hard way how much it screws you over in code scalability & flexibility. In Flash Lite, you don’t have a choice.

This whole time, I’m in way over my head in PHP. I don’t “do” server-side development. I can code Perl, PHP, and Ruby, but they are not my strengths, and I have no intention of improving them. Yet, I didn’t have anyone to make a server-side API for me. Upon searching Google, there were a few code snippets in PHP written to talk to Google Calendar, but none created as an API; most were for use by HTML developers. The majority of PHP out there written for use by HTML devs is typically the integrated kind, meaning tags in HTML; functions being integrated into your display markup. To me, I’m an avid MVC guy, and that stuff is nasty. Ruby on Rails has the sme crap and I hate it. So, I basically had to create my own PHP API to Google Calendar. That itself was wrought with problems that is out of scope of this already verbose blog entry. Suffice it to say I still don’t like server-side development, but I wouldn’t be here today if it weren’t for PHP.

Both angles, on the server, and the client, taught me way too much about time codes, dates, time formats, and other weirdness dealing with time it is relative to “where” you are in the world.

The last bit was just getting the application design down. I had her majesty design me an initial comp based off of my wire frames. We’ve done at least 3 interations since using an application on a small phone screen via your thumbs is totally different than a mouse & keyboard on the large desktop one. I really miss the layout tools that Flex has; doing layout & colors by hand in code sucks and is time consuming to get “just right”. The code is also frustrating since making a base class just for design purposes actually has too much RAM overhead.

One great selling point of Flex Data Services was the error handling the Flex team had put in there for returning nice server-side Java exceptions to the Flex client. Without FDS, you have to code those yourselves. I am having the same problem with PHP. There are 10 billion things that can go wrong, and trying to provide something meaningful to the Flash client so it can respond is really really hard. Furthermore, Flash Lite has errors that I can’t even catch, like “Data failed to load”. No clue why this happens, it just does intermittently and I have to pray the user clicks “Continue” on the soft key instead of “Abort”. Making reproducible test cases for bug fixing is a royal pain too, because debugging on a phone is nigh impossible; even a debugger text field to report debug data is hard because you already are pressed for screen real-estate and system resources. I did my best to handle errors, but a lot of it is faith based; you handle as many errors in the Delegates (using ARP, it’s like Cairngorm) and pray you got 90% of them. Lame, but it’s what we have.

Now I’m done, the first version is off to the contest. I really hope I win in the applications category. Just because it took me 4 months to build a component framework, an application, and a back-end Google Calendar API doesn’t necessarily mean my application is easy to use, looks good, works, and performs well. It doesn’t really matter, though. While I’m all about winning in life, I learned a ton in the past 4 months, and since I got bored of Flex for awhile, it was a nice diversion. I don’t think there is a career yet in Flash Lite 2 development for me. Not so much in deployment since those content networks are improving all the time (Moket, Handango, Verizon’s Brew), and not so much work since I’ve actually seen 2 contract jobs come up for Flash Lite dev work in the past 6 months. Rather, the skill sets expected by the industry right now isn’t up to par with what you typically see in Flex & Flash Development. That translates to lower hourly rates. Bottom line, it’s hard for me to get clients to pay Flex Developer consulting rates for Flash Lite work.

Hopefully that’ll change since the work has the potential be really fun if the scopes of the projects aren’t much larger than your atypical conference app, or my Google Calendar. I don’t see the actual development industry reaching a level of relevance until Flex can output for Flash Lite 3, though. The same reason Adobe made Flex is the same reason there aren’t many Flash Devs specializing in Flash Lite 2 development, never mind the lack of a market to deploy your content too. Even though the market for Flash wallpapers, screen savers, and games is in fact profitable outside of Japan, the portal site market is only slightly growing to relevance, but you don’t need a developer for those types of content. The application market just isn’t there at all yet.

Like I keep telling all of these recruiters & hiring managers, the amount of qualified Flex Developers will increase with time, so things will get better soon. I think the same can be said with Flash Lite applicability. Even if we are sick of hearing the marketing bs, there is no denying more phones are shipping with Flash Lite 2 capabilities, the distribution networks are making great strides in creating partnerships that can give us developers good opportunities to sell content, and that Adobe is fully behind getting Flash on devices. The first part is important to Flash Developers because we can transfer our same skill sets to work on phones, and that’s just rad. There are challenges, yes, but most Flash Devs I know fear nothing and love the challenge. Seeing a SWF run is enough positive reinforcement to justify it.