Just a reminder, the AIR Bus Tour is in Atlanta at the Fox Theater Tuesday. It’s a free, all day event to learn about AIR, the Adobe Integrated Runtime. I won’t be attending, but I hear there are a ton of people going.
Category: Flex
-
2007 a Different Economy Than 2006, Flex & Flash Still In It
March this year was high in the need for contractors, consultants, and full-time employee’s in the ways of Flex and Flash. It died June and July. It’s back up again in August. My inbox is full with emails I don’t have time to answer from recruiters and company employers. The majority want Flex. Some want Flash. Some think they want one, but may need the other.
The differences compared to the late summer of 2006 are as follows.
First, some of the start ups have money now. Instead of “We’re so awesome, you’ll want to work for equity because you’ll be so cool in 6 months to have even been associated with us” it’s now, “We’re still cool, and now we can pay you a salary, and company benefits if that’s your thing.”
Second, the recruiters are finally giving in to referral bonuses. This apparently was usually in the realm of bigger companies, placing management type positions, etc. That, or you just had to ask to imply it, and thus get it. I’m somewhat selective on who I send out my contractor list to. If I get 5 emails from various recruiters for the exact same job opportunity, typically the “first in, best English” email gets the list. If the recruiter is really cool, and like… actually cares, I’ll even give my spiel on those contractors I know stuff about. I’ve even seen the same particular jobs pop-up for the past 8 months. While this could be for a number of reasons (talent shortage, toxic client, etc.), the bottom line is that the recruiters are using leverage in the form of referral bonuses to draw out more contacts from people since there aren’t many like me who throw around a pre-sorted list with optional commentary.
Third, the work is still unpredictable. I was hoping for some common themes 5 years into this, but apparently not. Who am I kidding, I love it. While it is challenging to summarize the the type of work since some of the recruiters are not in this country, do not accept incoming phone calls, or simply don’t know enough about the position they are placing candidates for, I have a pretty good idea. That said, the work in the Flash realm is pretty predictable:
– Custom/branded video players. People want something that accentuates their entertainment budget they’ve already spent millions on. Having a YouTube or Brightcove branded player detracts from that.
– WidgetsThe interesting thing about widgets is that it’s currently about half and half with Flex. Some of the widgets are design driven; those use Flash. The others are multi-purpose, used inside existing websites or on other platforms; those use Flex. Really random.
The Flex stuff is impossible to categorize. While debates still rage about when to use what technology, when, and where, a lot of companies already know, and are hiring talent for those endeavors. For those that don’t, they hire competent Flash Developers, and they then morph into full-time Flex Developers, usually by accident.
Fourth, remote work is offered without having to ask. Y-gen‘s like me who are all about living the Digital Bedouin
work stylelifestyle, this is a must. It’s pretty easy to end conversations with recruiters over the phone/email:“Do they support remote work / telecommuting?”
“No, they do not.”
“Not interested. Thanks! Bye.” :: click ::
Now, I’m getting emails, more so from employers directly, offering remote work for projects if it’s needed. Not encouraged, but accepted. Awesome.
Just because the Flex momentum has died down now that 2 has been out awhile, everyone is enamored with Flex 3 beta & AIR, and Flash CS3 has allowed the Flash Developers to start using AS3 the employment scene in this industry is still strong. Talent is still in short supply. Existing programmers are still picking up and running with Flex very easily. Sometimes (not all unfortunately) this results in them needing help on the design front, usually resulting in trying to find Flash Developers or Flex peeps with a Flash / Design background.
If you have a job, it sucks, and you know how to code in Flash or Flex, it’s not too late to jet for greener pastures with opportunity. If you are not on my contractor list, and want to be, lemme know what type of work you like and send me an email. I send this list to employers and recruiters who are looking for Flash / Flex talent.
-
Flash Player 9 Unacceptable JPEG’s from phpThumb
Using phpThumb at work. You upload a video file, and the server generates a thumbnail from the video via phpThumb. Here’s the bad news: The thumbnail doesn’t work in IE6 and IE7 on Windows in Flash Player 9. Everything else works (Firefox, Windows Safari (sometimes), Opera, and everything works on Mac). Flash Player 8 works, but AS1/AS2 Flash Player 9 (compiled by Flash CS3) does not.
So, something changed in Flash Player 9 that affects the JPEG rendering because the JPEG’s work fine in everything else. It’s only a big deal because the biggest feature of Flash Player is backwards compatibility; aka, Flash Player 1 content should work as intended in Flash Player 9. Naturally everyone and their mom will blame phpThumb doing something different with headers, etc. “Enterprise company with a 10 year-old rendering engine vs. an open source image generator… um… yeah.”
As soon as we get our code pushed to production, I’ll make a few test cases for the Adobe engineers, but in the meantime, anyone else experienced this? If so, and you are reading this blog from a Google search, hopefully we’ve posted a solution in the comments, hehe. As of today, the server guys got it working somehow (aka modifying phpThumb’s base code, something about headers :: shrugs ::). Really really frikin’ hard to test with caching, etc. so it’s been long and bloody.
-
10 Tips For Working With Cairngorm
These apply to Flex 2.0.1 with any version of Cairngorm. Since people’s programming background varies in Flex, these are not facts, just my opinions based on my experiences using ARP & Cairngorm for over 2 years. Furthermore, there are alternatives to Cairngorm, I just cannot try them as much as I like. Now that I’m doing product work, I can’t just “try this framework on this new project”. I live in the same code base longer supporting existing clients, and can’t do dramatic re-factoring without getting fired.
1. If Cairngorm looks complicated, don’t worry, it is, and you’re not alone
“Bunch of code on _root vs. all of these classes and conventions? This’ll take forever!”. It takes getting used to. I felt “comfortable with Cairngorm” on my 4th project with it. To this day, I still mod it though, and try different things. As more people come into Flex, there are more cool ideas and techniques floating around.
2. If it feels like it’s taking a long time just to do something in Cairngorm, it does.
“OMFG… 3 classes just to execute what would take me 1 line in Flash? Lamesauce!”. Code gen can help here, at least at the beginning of the project.
3. Only Commands set data on the Model; you can break this, just don’t if you can help it.
In Model View Controller, only the Controller sets data on the Model. In this case, the Commands are the Controller (usually), and as such, setting ModelLocator data is their job, and their job alone. If data is getting f’d up, you immediately know it’s in the Command. You never have to question “who’s setting my data, where, and when?”.
4. Delegates make the server call and parse the data (sometimes in a Factory)
This has only happened once in my career: I was hitting PHP for the back-end, parsing XML, and in the middle of the project, we switched to OpenAMF and Java where I had to parse objects. Using Delegates means you only have to re-code your Delegates, not the rest of your app. The Commands still get the same data.
The only reason I use Factories is because A) parsing can be a lot of code and you don’t want to make your Delegates look more complicated than they are and B) you can share parsing routines easily in the same Factory class.
5. If you see a Command parsing data, it’s coded wrong.
Parsing is differently from filtering, modifying, and assembling. IE, making Value Objects from XML should be done in the Delegate, not the Command. Making associations between ArrayCollections, injecting default values are both ok. Remember, the key here is if the Command is touching raw server data, you’re either not using Delegates correctly, or have AMFPHP/FDS/WebOrb working correctly, hehe.
6. There are 3 ways to use Commands & Delegates. I prefer A because it’s consistent, leads to short class files, and is very explicit.
A) For every use case, you make 1 Command and 1 Event. This can sometimes also mean 1 Delegate. (ie, LoginEvent, LoginCommand, LoginDelegate)
B) For every use case that’s related, you can consolidate them into a package path. So, Login, ChangePassword, and ForgotPassword would all be in the same class. You’d then use constants to determine which one to run. (ie, LoginEvent has LOGIN, CHANGE_PASSWORD, and FORGOT_PASSWORD as String constants. Your LoginCommand has a switch statement which determines which one to run. Your LoginDelegate has 3 methods; login, changePassword, and forgotPassword that your Command can use.
C) Variances on B. Maybe 1 Event and 1 Command, but multiple Delegates. This is not a cop-out bullet item, rather, I’ve seem many derivatives that can all be traced back to “B with mods”.
7. ViewLocators are considered bad practice.
That said, there are developers who still love and use them. The use case, however, is valid: Having a View “know” when something in a Command has occurred. I use callbacks, some set data on the Model to trigger callbacks on the Views (maybe via a setter function), and some use addEventListener in tandem with CairngormEventDispatcher.
8. ViewHelpers are considered bad practice.
That said, there are developers who love the idea of “code behind”. I’ve yet to see a consistent theme on the blogs and mailing lists. There are 2 reasons that are common:
A) They don’t like mixing ActionScript & MXML.
B) They want to separate their View’s from their “View controller code”
Some use the script tag to point to an external file (lame in my opinion; you have to define your controls as member variables and you end up with twice as many View classes). Some use inheritance where you extend your GUI MXML. Others take the reverse, and have the GUI MXML extend the ActionScript ViewHelper. Some will even take the Composition over extending MovieClip approach I’ve seen a lot of coders do in Flash. Instead of their ViewHelper extending a view class, it’ll instead take a UIComponent as a parameter, say in an init method, and use that UIComponent via composition.
To me, you’ll get over it as you get more comfortable with Flex. Code your components in MXML with code up top in a script tag. If you really need efficiency, or start doing some really low-level, abstract type classes, then you can start coding your components in ActionScript. If you want to get stuff done today, use MXML.
9. Don’t use flash.net.Responder, use mx.rpc.Responder instead.
Yes, it’s frustrating because Flex 2.0.1 doesn’t give you the source, but in my opinion, Flex Builder doesn’t handle same-named classes very well. Just go with what Flex uses, and call it a day. If someone requires flash.net.Responder, code a wrapper to bring him into Flex land. “Sir… you need a tie to get into this restaurant. We have one in the back, one moment.”
10.Try not to have View’s use CairngormEventDispatcher (or Events that extend CairngormEvent use event.disaptch()).
Instead, have those deeply nested views dispatch events. Either bubble them up so a master controller View can then fire off Cairngorm events, or bucket-brigade them up. The most common scenario is itemRenderers that are a custom class in DataGrids.
You:
– make the itemRenderer class. If you have something in it that is clickable, dispatch a custom click event. Make it bubble.
– extend the DataGrid that uses your custom itemRenderer, and put the custom event in the metadata up top. Otherwise, the class that houses the DataGrid will only be allowed to subscribe to the event via MXML, only ActionScript. If you use MXML, it’ll fail to compile because the DataGrid doesn’t have that event in it’s source code.
It may feel cool at first to have a LoginForm for example dispatch the LoginEvent, but if you need to use it for a different purpose elsewhere, you’re screwed; it’s hard-coded to use a specific CairngormEvent. This applies to all components. Encapsulate your components and do your best to do what BT does: “bubble it up”.