Part-time Recruiter, Breakneck Flex, & WebDU 2007

I get a lot of emails regarding Flex & Flash opportunities, most on-site with no telecommuting options. These usually come in on average 1 every day. Some days I’ll get 4, 2 for the same job, and some days none. As I started exploring employment opportunities back in November, it didn’t really take long for the recruiter emails to start rolling in. Combine that with my own 2 email blasts to everyone I know work wise, everyone connected to me on LinkedIn, updating my resume on job sites, and my own volleys of cold-emailing jobs at FlexJobs and other various avenues… and well, it’s more insane than 2003 was. The projects are longer term, and they want more experience.

Same problem, though. Not enough qualified individuals. The difference between now and 2003 is that I keep telling those employers and recruiters who I end up hunting for that time is on their side. I mistakenly predicted that Flash devs would flood the marker and 2005 would be the year it all ended. Not so; even today there is still a lot of Flash work. Flex, on the other hand, is different. I see programmers from all walks of life diving in with the only learning curves being associated to learning a new language, not a new tool. Big difference which effectively means lower learning curve. I’m also hearing more of the, “…we/they got so frustrated by the lack of qualified talent, they just sent their in-house .NET / Java team to training for a week, and apparently are doing fine.”

Good for them. Good for Flex.

The downside is, there are too many emails to respond to. Too many software specifications to read, digest, and make bids on. Too many opportunities to quickly and easily recognize what is worthwhile, and what isn’t. The good thing is, this really makes you focus clearly on what you want, and shoot for that. I’ve just never been good at saying no, so it’s rough. Some are time-sensitive too, so it’s challenging to keep on top of those. My compensating factor is becoming a part-time, not paid, recruiter.

For example, for those jobs that are on-site in some state, city, and county not within 30 feet of my house, I’ll usually try to suggest qualified candidates that have the skill set they are looking for, in the same locality, and follow up with an email that contains the contact information of those individuals. From meeting many people offline and off, I have a decent network across the planet; enough to have a 50/50 chance of even helping international positions. This goes hand in hand with contract work that I usually don’t have the bandwidth for. I’ll shoot to my list, and order said list by client complimented contractors, those who requested work recently, and those who fit the skill set the client is looking for.

To add to that, I’ve had this weird desire to look at other people’s resumes and tear them apart. Her majesty has ripped into mine for the past 6 years, so combined with the plethora of stuff I learned from and in college, on interviews, and from online research, it’s really nice to give advice (heeded or not) to peers so their resumes’ stand out and effectively sell them to prospective employers.

Now, seems to me those above 2 paragraphs are the jobs of recruiters or job placement agencies; not some programmer. But… I like it in a hobby type of way. Both recruiters and potential employers have been really appreciative of me sending them employee leads, so even if a job interview / contract doesn’t work out, we part on good grounds and open up the door for reference checks (“Yeah, I know the guy, he’s legit.”). Holy fish, though… man, it’s a lot of time and effort! I can see why people get paid full-time to do this stuff. I’ve still got 5 resumes of friends to go on top of the starred 52 (last Friday’s 48 didn’t go so well…).

Bottom line, if you know Flex, or are learning it, and you don’t have a gig / job (or are not in process of interviews)… wtf? If you are under-appreciated, there are plenty of people out there who will love you!

In Flex news, I’m on an extremely fast and hard deadline project. I like the git-r-done ones vs. the drawn out, too-afraid-to-test-early-builds-on-users ones. It reminds me of Flash projects… only with cooler components. I’ve been pulling 16 hour days for like 2+ weeks… I think, maybe 11, I don’t know, it’s all a blur. I’m having a blast. Those types of projects you just really don’t care; if it’s fun, it’s not work, and if it’s not work, you code till you drop with no anger. Those types of projects you find sneaky ways to pump more features into the final product (ensuring it works of course) instead of whining like a little ho in meetings when management wants some modifications and additions. Totally different world. I wish every project could be like this. “There’s the hill, soldier. You need to take it by nightfall. Failure is not an option, and you only have 1 machine gunner with you. Good luck!” Hell to the yeah.

Technically, I’ve learned too much about mx.containers.Container. It’s really rad, though, because now I can make my own panels with impunity. This is important because I can allow other developers to use them as containers in MXML, and that is just so frikin ‘ cool. Additionally, if I ever work with a designer again (I will dang it), they won’t be constrained by the Flex Panel. “You design it, I’ll code it.” …Except masking blurs…wtf . Works in Flash, not so great in Flex. The lack of easy use of pixel fonts is kind of shame too. I saw Grant blogged a solution today, but I haven’t had to time to try it myself. Some of our charts that shrink really small have un-readable text. If I could shove some of my pixel fonts in there, they’d look really good. The more design stuff I am responsible for, the more I hate layout constraints and box models. I’m starting to just feel like if I want everything laid out the way I want it with an easy ability to animate it, it’s gotta be in a Canvas with x and y positions. Everything else is just a nightmare. It’s worth it, though, because she (they, as in apps) look hot.

I also like impossible odds. In this current project (due tomorrow), I have 2 3rd party vendor components, 1 back-end, 1 front end, that are both brand spanking new. Alpha code is t3h fun! Both of those vendors already have a ton on their plate, so they can’t just lolly gag on the phone/IM with me all day if I have questions and don’t feel like reading the docs. I have a list of bugs, features, and clean up tasks a mile long. Naturally my defiant response is, “You got nuthin’!” Grit my teeth, have faith my wing man’s got my back, and pump updates to HQ on status. Oh crap… 53 emails to respond to. I’m sure if I prioritized things around my deadline, getting my taxes done, and responding to job / contract related emails, it’d just be a clean looking list that was uber long. Just code and don’t look back!

Speaking of code, I’ll be speaking about code in Australia next week at the WebDU 2007 conference. Her majesty will be speaking too about Usability. I’ll be flying from Atlanta, Georgia to that stupidly designed airport, LAX (Los Angeles) on a 5 1/2 hour, and then hitting the 14 hour to Sydney. I have mad books that friends have recommended to me as well as some I own. To top that off, I have to document my Flash Lite 2 component set called “Shuriken” which is what I’m speaking on. In my experience, good docs make a great product. Frankly I don’t see a future of Flash Lite for me for another 2 years, but you never know. I’m a programmer, not a futurist. I’ll have to pack on Saturday I reckon since no time tomorrow.

Speaking of tomorrow, I hope they announce the winners of the Flash Lite contest. I keep telling myself that I’m not excited, and don’t really care about the results, but I think that’s just my way of emotionally compensating for if I lose. I hate losing, and live to win, thus I secretly want to own. We’ll see. Even if my PHP tanked on me, and my app didn’t make the grade, at least I got some phat components out of it.

Got a new phone, too, a Razor something or other. Her majesty is Nokia prejudiced; she digs Motorola. Since it’s Cingular specific, it’s locked (as opposed to my Asian Nokia 6680), and even has 2 buttons just for them ON the phone. I love how these operators in the US work, man. I remember bitching to Michael Hagel about how pathetic it is trying to make money on mobile stuff using my existing skill sets. He retorted about how they (operators) refuse to do what some of the telecoms did, and basically build a bunch of communication infrastructure (aka the Internet) and not make any money off of it. The operators like Cingular and Verizon on the other hand charge you out the yang for everything, and give you hardware they control. I may not like it, but I respect their ability to monetize every stupid little, irrelevant thing. That’s just rad that it costs $70 a month for unlimited, modem speed internet access on my phone (it’s not $20 Nahuel, I looked, you Californians must have better deals or you just got extremely f’ing lucky) when I get unlimited broadband from BellSouth (now AT&T) for $30. Then again, AT&T merged back together for a reason. $1.60 to make roaming calls in Oz. I could call Robin Hilliard, and ask him random business questions… or a party line for $2 a minute. Robin bequeathing knowledge… Candy relaying praise… hrmm … anyway, they sure shove these phones full of useless stuff. It’s like when you buy a computer from Best Buy, or some other media outlet that sells eMachines . It comes with a bunch of pre-installed software you don’t want, don’t need, and slows down your comp. Instead, you get a raw box, and go from there. Apparently the same is becoming true with phones. However, to her credit, the phone DOES look stylish, has a nice looking screen with a fast interface, AND isn’t Nokia software. My last Nokia backup utility actually deleted my entire phone book. Here’s to hoping Motorola perceives that as “unfashionable”.

Anyone want a job of answering my emails? You basically go:

recruiter: “Contact this guy; he’s a good Flex candidate for on-site work.”

client: “This project will cost $X, and take X amount of time.”

homeskillet: “Search for ‘states’ in the Flex docs and join Flexcoders.”

big company: “Contact Universal Mind.”

employer: “Here’s my resume and links of my work. SWF 4 t3h w1n!”

See? It’s easy!

:: reloads :: It’ll be light soon, and I got a hill p@wn.

360Flex Schedule Flash Lite 2 App

For an up to date conference schedule on your phone / device, I’ve created this Flash Lite 2 app. It’s better than the paper they gave you because it updates from this XML file. Therefore, if there are any changes in the schedule, we can update the XML file, and the he app will have the most up to date schedule. I’m a little cracked out from Denny’s-the-morning-after, so bear with me. I also left my good pixel fonts at home, so am waiting for new, better ones to arrive in my inbox. For updates, check the bottom of this blog entry; don’t forget to refresh your browser.

Here’s the SWF.

Don’t have a Flash Lite 2 enabled phone? No worries! Just keep this page open in a browser tab next to Twitter.

For Nokia, Windows Mobile, and PSP devices, go here and click the downloads tab to get Flash Lite.

*** Update: Changed download SWF to Flash Lite 2.1, site SWF to Flash 7.

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. 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.

Flash Lite 2 Component Framework Questions to the Community

After yesterday’s frustrations with the technical limitations I’m running into, I thought I’d put out some questions to the community to see what they feel is important to them in a Flash Lite 2 component framework. This will help me focus my efforts and deliver something useful to the developer community by the Ides of March.

Last fall, I set out to create a Flash Lite 2 component framework, called Shuriken, that made developing Flash Lite 2 applications not only capable (no UIComponent…wtf!?), but also pleasurable since nothing exists currently in that realm for Flash Lite 2. Adobe has provided Flash Lite 1.1 components that do not utilize ActionScript 2, nor any of the Flash Player 7 features. Their emulators, however, are top notch.

The goals, in order of priority for the set, are:

  1. work on the lowest common denominator; if it can run Flash Lite 2, the component framework should work.
  2. provide commonly required GUI components & utility classes while being easy for developers to extend.
  3. no styling or skinning code; developer / designer is responsible for decorating and/or changing base skin symbols. No assumptions are made in code.

I’m having problems meeting those goals, namely in regards to scalability. I cannot take all the RAM & CPU in the framework, but the more I take, the easier it is for the developer. I’m having serious challenges meeting both the desire to provide developers with a clean, useful API that hits most common use cases, but also is efficient enough to run on devices in a scalable way. These are bipolar goals, and meeting in the middle is starting to become impossible. I believe everything is possible, but I want to get to the most useful result, so am hoping you all can help me focus on that result.

Onto the questions:

  1. Are those goals accurate? Agree? Disagree? See a different order? Different priorities?
  2. Would you rather have a clean ActionScript 2 API, or a lightweight one that doesn’t have much functionality, but does a lot of the grunt work? You have to choose one or the other, not both.
  3. How do you prefer to write events among the 4 options:
    1. child MovieClip calls a method on the parent via _parent.onEvent
    2. using built-in Flash Player 6 callbacks, like myClip.onPress = function
    3. using Flash MX callback mechanisms, like myBtn.setPressCallback ( scope, functionToCall )
    4. EventDispatcher
  4. With regards to #2, would you prefer to have more GUI controls, or less controls that are more efficient?

Thanks for your time in answering these. It is appreciated, and will help provide a useful component framework for the Flash Lite community!

“Et tu Flash Lite Community? Then fall walled gardens.”