A Java Perspective

I got a lot out of this thread. It’s nothing earth shattering, new, but it does point out a consolidated list of, what I’ve come to think of as a typical web Java developer’s issues with the Flash family. The point isn’t my stereotypical/not-so-accurate classification, but Macromedia’s reaction to the points in the email that I’ve managed to see over the years. He even echoes the server-side dependency, though, to the multiple tiers, I say get another developer and to the server, I say just upload the SWF’s.

The last sentence just made me laugh out loud. Yeah, I coulda’ lol’d, but it just deserved the written out phrase.

“Why Macromedia needed Action Script and not addopted Java instead to develop the Flash Player … or maybe I’m missing something…”

I wanna yell while still laughing, “Where the heck were you at Flash 5?”, but then I remember things for the RIA world were pretty underground then, and I still refused to use that crappy program called Flash because Director ruled the known world, and I was learning to own Director. You know, that doesn’t do it justice, I can’t really summarize the swath of ironic and non thoughts I get all up in my head from reading that; the one thing I do know is it still makes me laugh.

Anyway, blogging here since the list is more for answering questions, not for chatting, and carrying the same crowd, at least for now, to Flashlounge doesn’t seem reasonable/realistic.

Central ‘esque Methods for Flash’ & Flex’s ProgressBar

For those of you in Central withdrawl, like me, here is a conversion of the 2 methods that Central uses for it’s Shell to control the progress bar it has at the bottom. Flash and Flex have a ProgressBar component, where the label is underneath the progress animation itself. However, I really liked the elegance of the methods, so converted for a project I am using. They are merely a simple wrapper around Flash’/Flex’ ProgressBar component to act like Central’s built in one. You can still use the indeterminate and label getter/settters as well as the setProgress method, but this way just felt more encapsulated to me.

progress_pb.mode = "manual";

function setStatus(str:String):Void
{
        progress_pb.label = str;
}

function setProgress(val:Number):Void
{
        if(val < 0)
        {
                progress_pb.indeterminate = true;
        }
        else if(val == 0)
        {
                progress_pb.indeterminate = false;
                progress_pb.setProgress(0, 100);
        }
        else
        {
                progress_pb.indeterminate = false;
                progress_pb.setProgress(val, 100);
        }
}

I’ve been using it mainly for web service calls, like so:

// starting the call
setStatus("Calling remote method...");
setProgress(-1);

// in my result handler
setStatus("Method returned: " + result);
setProgress(0);

// in my fault handler
setStatus("Method failed to return: " + status);
setProgress(0);

// obviously, you can do the old-skool
// half-way done
setProgress(50);

Why Flash Developers Should Care About Flex

Many have questioned the validity of Flex as a platform, and wondered why I like it and use it. I believe for many this is to understand if it is worth investigating, and to shed more light onto where it fits in our future. I will attempt to explain now why I like it, my inferences on where Macromedia see’s Flash & Flex going, and where I see Flash Developer’s within that path.

Why I Like Flex

I like Flex for a number of reasons. What drew me to Flex in the first place was I was bored with Flash. I have reached a point in Flash where I have little to learn in the Flash development world worth learning. I have plenty of things to learn in the programming world, such as additional design patterns, application of them in real world scenarios, and more advanced OOP concepts. There are a plethora of other technologies that would help my career by learning, such as Java and .NET.

A GUI guy by trade, I’m all about the V in MVC (model view controller). Some of my co-workers at work are all about model, and together this makes a good team. Therefore, it is very difficult to find interest in learning additional, model based languages such as Java, .NET, and PHP. While those languages & technologies can do GUI development as well, there is a self-explanatory reason why Flash fits into this equation. So, 8Ball (Flash 8) isn’t out yet, Flex was the next logical step.

Flex’ components are far advanced compared to Flash 7’s. The V2 architecture has been significantly improved upon, there is more fine grained control if you want it, but so much has been easily abstracted that you don’t need to really worry about it.

Flex does a significant amount of busy work that Flash does not. Not only does Flex separate your GUI layout from your code cleanly with the option of merging to various degrees if you need, it also separates the actual design of that GUI. By doing what XUL does best, your JavaScript is the code, the XUL/HTML is your presentation, and the CSS styles your presentation without being merged to it. Same with Flex. Your MXML pages display your form elements, your ActionScript is your code, and the CSS styles your MXML forms. It’s a wonderful separation that is clean, and Flash does not currently do with ease. Not to mention the fact that Flex Builder, the IDE that is basically Dreamweaver with improvements, with which you author MXML pages & code ActionScript, integrates all 3 of these technologies very well. Flash does not.

Now, I don’t really give a flip about the fact that MXML is text based vs. the binary based FLA’s, but for many using source control systems, this is a must and supports diff’ing your code.

Finally, Flex is where the action & improvements are. All the components look better than the Flash 7 ones, their designs have been improved, they work smoother and faster (at least they feel that way), and the coding API is much more matured. A lot of Macromedia employee’s in charge of Flex and not are currently on the list, as are talented coders. The traffic is low, and that sense of “wonder” around a new product is there. You can tell not only does Flex have a future, but Macromedia has a clear vision for it, but they are also taking feedback from the community to help shape it.

Where Flash and Flex is Going

I don’t feel that for Flash at all. They have clearly stated that the next version of Flash will be mainly for designers, and there will still be stuff added for developers, but that is not the focus. The lists are about the same problems that new people have, and while I love meeting new people and helping usher them to a more adept state, I’d like to learn something too. I am not sure of Flash’ future beyond device development, which until devices (phones, PDA’s, etc.) get Flash 7, I’m not interested. You couldn’t pay me enough to code in Flash 4 or 5 ‘esque ActionScript. The introduction of JSFL, while an extremely awesome addition, does more to prove to me that they are leaving Flash in better hands for future development, just like Director Xtra’s; the community. If we need something, with just a few additions to JSFL, and most plug-ins and features can be coded by us. While the concept is fantastic, I would much rather build things using a tool vs. building a tool to build things. I enjoy JSFL & tool development for Flash, but I would much rather spend my time developing those as simple, helpful widgets vs. full blown plug-ins to compensate for a need in the community.

I do believe Flash will be around a lot longer. Just like how Director’s still around today, although, I think Flash will still have a more central role because there are nitty gritty details of development you currently cannot do in Flex as easily. As Nigel pointed out in his article, there will still be a tight coupling of Flash Developer and Flex Developer in teams, but I think that only applies to bigger companies. For smaller ones, it’ll be like usual; the Flash Developer does both the Flex work, plus the production art, plus the Flash work. Same as usual, only instead of Flash being the final authoring tool, it’s Flex.

Yes, I can honestly say that I feel Flex will be used in a normal production environment, my conclusion at the bottom of this article non-withstanding. Although I like to think of myself as a hybrid, I’m really just a Flash Developer, tried and true. That, in itself, showcases a wide array of disciplines brought together under that title, but a lot are more understandings than actual applications. For example, I understand good design, usability, user testing, PSD to PNG conversion and why it’s important in a workflow, video compression, etc. That doesn’t mean however that I actually do interface design, wire frames, user testing, production work (well, I always do this), or video editing. If the need arises, I can, but typically in a multimedia team, I’m the guy that brings everything together, puts it together, and makes it work.

With all of that said, I’ve still done one, clear path: I’ve changed from a designer to a developer. Period. I no longer “design”, I “code”. I’m a developer, not a designer. While most Flash Developers are quick to point out that they can design, and some actually do, I don’t. I’d say that too, only I know that the truth that I hardly ever come close at designing, and probably never will considering my career path. That said, Flash is not the optimal solution for a developer. Flex is close. The mere fact that I am a developer who not only exists using Flash as a development tool, but learned the majority of my development prowess through it (the first 20% in Director), says that I’m a different kind, which leads to a sub-classification: Front-end developer. I would think front-end developers are comfortable with HTML, CSS, Flash, and converting PSD files to usable, optimized graphics. I’d think they’d be comfortable navigating ASP/PHP code mixed in with their HTML, working with designer templates to code the necessary JavaScript, and obviously utilizing Flash for whatever need arises.

Therefore, for a front-end developer, I believe Flex is the optimal solution. Frankly, though, I have a hard time seeing someone only using Flex, whilst another uses only Flash. I’m sure that’s what Nigel meant, but in my opinion, back-end developers should stay the heck out of Flex, and in their respective back-end sandbox, just like I should never touch Java or CF or any of the back-end services. That said, it’s truly an idealistic statement. In the real world, a pragmatic, business orientated one, people wear many hats. Therefore, I could see how I could be coding the Java service via OpenAMF, the Flex, and any necessary Flash. The same holds true for many of the talented people I’m seeing on the lists; ColdFusion and Java gals and guys coding both the back-end and the front-end. Although the waters may appear murky, I think the intention is for front-end developers, but because the barrier of entry is so low, approaching GUI has never been easier for even back-end developers, and a good looking, awesome potential GUI at that.

Another point to add is that history is repeating itself. Director 5 implements Lingo, Flash 5 implements ActionScript. Director 8 implements ground breaking new feature of 3D, Flash 8 implements ground breaking feature of bitmap blitting. Director lives on as a Flash support product. Flash, for developers, will live on as a Flex supporter product. The device gang probably disagrees on that last point, I bet.

So where am I again?

For Flash Developers, I see Flex as another tool to add to the Flash Developer repertoire, only this one has the effect of potentially changing one’s title. Flash Developers in many small companies, will be doing Flash and Flex development in tandem; back-end developers will have little if anything affected on their end. For those things that do change, probably for the better and both sides positive about the changes. Flash Developers will being using Flash and Flex in their daily jobs, and compiling the majority of their actual applications in Flex, whilst their supporting components and sub-movies/smaller applications in Flash. Other companies who were using Flash, for example ColdFusion/Java shops will instead move to Flex as the approachability for those types of back-end developers will be extremely appealing, and the expectations will be more easily met. Flash developers will be contracted out for component development, expected to make custom SWC’s to use within an ongoing Flex application, or for additional Flex coding work.

The same will hold true for bigger companies; again, I have a hard time seeing what Nigel describes as how a Flash developer could NOT know and utilize Flex and a back-end developer could stand to spend half their time in Flex. It just doesn’t click for me. It seems like a gross negligence of responsibility appointment. Instead, I think Flash developers will be replaced with Flex developers, only it’s the same person, and they know Flex and Flash instead of just Flash.

“But Jesse, Flash 8 will still have tools for developers. I mean, we helped bring Flash where it is today.”

Oh really? Devices will be taking another 2 years to mature in player version to where serious developers want them. Why should Macromedia enhance anything currently for that initiative; from what I’ve seen, especially with PocketPC which supports 7 already, Flash does that well already.

David Mendels, EVP and GM at Macromedia, has recently stated on the Flexcoders list in response to a Flash Developer asking if any of the Flex changes to the V2 architecture would make it into 8Ball, or perhaps a DRK, “…Either way, to set expectations, we do not expect any major changes to the components prior to the next major release(s)…”.

The ideal many had of Flash, Central, and Flex all having 1, global SWC file which contained the entire framework (as Flex now currently does) is dashed upon the rocks violently. Many of us were frustrated and wanted the same components for all 3 products. If Macromedia updated 1, all 3 products would get updated, and all 3 would look the same to end users. From a designers’ standpoint, this sucks, but from a developers’, it rocks. Well, it would of…

Without any uncertain terms, your future is not in Flash, only with it and Flex. Abandon all hope your future as a Flash Developer is strictly within Flash, and Flash alone. The RIA revolution is here, and this year promises additional big projects, but Flash will not have all of that pie. If you want the same amount you used to have, and perhaps more, learn Flex. Change your title to include Flex in it. It’s ok if you hardly ever do Flex development, just be darned familiar with the program. I’m sure once you see what it has and Flash does not, you’ll be more inclined to do Flex projects vs. Flash ones anyway, thus keeping your skills up to date.

Again, I don’t think this is another Flash Remoting, or Flashcom… Flex to me is the forerunner, with the most potential for growth and innovation in terms of RIA and application development. It has better components and will still have better components when Flash 8 comes out, and it’s compiler spanks Flash’s in terms of feedback and debugging capabilities. The application allows adjustment of fine grained application details such as script timeout and recursion limits, something one can only do in Flash using ActionScript Viewer, a 3rd party application. To me, Macromedia has clearly shown that most of its resources are aimed at making Flex more kick ass than it already is. If your impressed with Flash Player 8’s improvements, so am I, but Flex gets those too (as does Central, Breeze, etc.).

Conclusion

Without further ado, let me remove all validity from the above, because I can. What confuses me about the above to no end, and brings doubt to most everything I’ve said specifically about Flex’ place in my and your future, is the Flex pricing.

The main reason my company isn’t using Flex right now is pricing. I have no qualms about my ability to convince everyone in my company to switch to Flex vs. Flash as the primarily development, whilst still keeping Flash around because it is without a doubt still necessary.

I don’t, though, why? Because my company knows that our customers cannot justify the cost increase in our software offerings. Increasing our price 6 to 12k for something I could do in Flash is an impossible sell. I love Flex and I know it has a ton of things Flash doesn’t, and will never have. Those things, however, will not allow it to gain a foothold.

My only hope is when Flex’ server licensing model comes out. It certainly made Flashcom an approachable solution for projects vs. XMLSocket. Although XMLSocket is powerful, I’d much rather use Flashcom. I couldn’t, however, until Flashcom server hosting became reasonable, which now it is. My guess is, once Flex does, it may offset barrier of entry resulting from price.

Let’s all hope so. I would much rather love a future where my title of this entry should of been “use” instead of “care”.

Flex Chronicles #5: Alert Drama

There’s a known issue with Alert’s in Flex, using the application level alert, or Alert.show. When you do:

function initApp()
{
        ref = Alert.show("test",
              "",
              Alert.OK,
              this,
              Delegate.create(this, onAlertClose),
              null,
              Alert.OK);
}

function onAlertClose()
{
        ref.deletePopUp();
}

The Alert’s background will stay around. In my investigations, he’s an mc in a very low negative depth. Removing him forcely messed up my app. Matt Chotin then recommended using a doLater. Upon doing so, it fixed my problem. I guess the invalidation routines co-chillin’ deep in the depths of UIObject remove the rect. ::shrugs::

At any rate, if you do this instead:

function onAlertClose()
{
        doLater(this, "killPopup");
}

function killPopup()
{
        ref.deletePopUp();
}

It works good.

Took me 3 days to work through that mess; here’s to you not having to do so.