Aral Balkan

Towards the end of last year, I was contacted by Macromedia to write an article for the February 2005 issue of their Macromedia Edge magazine. As the topic, I chose "Migrating from Flash to Flex" -- something that is made very simple when you architect your Flash applications with a clear separation of presentation and business logic and using the V2 components, the event model and a form-based approach. I saw the Edge article as a teaser for a longer DevNet article but things were not to be. At the last moment, I was informed that the title of my article had been changed from "An Introduction to Migrating Flash applications to Flex" to "Tips for Using Flash Assets in Flex Applications". The only reason I can give for this is that the article ran contrary to how Macromedia was trying to place the relationship between Flash and Flex at the time: Basically, that Flash and Flex were very different (partly to justify the huge price difference) and that Flash could be used to create assets for Flex. This is also why Macromedia was trying so hard to push Flex as a server when myself and several others (notably Darron Schall) had publicly stated from the very beginning that there was no reason for Flex to be a server. (All this was a tactic to lure J2EE programmers by creating an *expensive* nail to fit the hammers that Java folk carry.)

I've always believed that Flex 1 was an exercise in short-sightedness by Macromedia: We had a chance to really plant Flex as the primary technology for web application development but might have blown it while chasing some high-paying Enterprise accounts. What did Flex lose in the process? Developers. Flex beat Microsoft to market but you wouldn't know it by the number of Flex developers that exist today. What a wasted chance. I'm glad to see that Macromedia has realized this and is opening up Flex 2 to a much wider group of developers by radically altering the pricing. I just hope it's not too little, too late. This is a question of short-term profit versus long-term survival and with Flex 1, Macromedia favored the former at the expense of practically guaranteeing itself the latter. It remains to be seen what the dominant technology for web applications will be.

In any case, this morning I received an email thanking me for my Macromedia Edge article: "Please pass on our thanks to him for such a neat and concise overview of what will be involved in our migration. It has taken us some time to find any resources that contain practical suggestions, his article was like a breath of fresh air!" (Thanks for the kind words!) Furthermore, the email was inquiring as to where they could find the longer version of the article that's stated as being on DevNet. Unfortunately, there is no such article on DevNet. I had actually forgotten about it, while waiting for the go ahead for the article to go up on DevNet and have been sitting on it for a quite a while so now is probably a good a time as any to release it. I've cleaned it up a bit (removed instructions to the DevNet production team, etc.) and made it into FlashPaper and PDF versions which you can download from FlashAnt.

Flash to Flex migration is a very real issue for a lot of people and will, no doubt, become an even bigger one as time goes on and most (if not all) application development for the Flash Platform moves to Flex.

Read the paper:

Migrating a Flash Application to Flex (PDF)

Comments

• Hi Aral,
  
  Thanks for posting this article. It will definitely come in handy when I will throw myself on Flex2 and want to migrate my MVC projects to Flex2. I am really looking for a solution where I can keep my current structure/separation of concerns, while benefitting from AS3.
  
  I was so happy when Flex 1 came out, because it fitted me perfectly as a developer, until I saw the price tag. It made me completely ignore Flex until recently when MM announced the labs and the Flex 2 price tag.
  
  I am still trying to understand though if I can use openAMF with AS3 as I have done until now with AS2.

  by Kim hansen on 2005-10-28 13:08:19

• I have a question. What do you use to easily create your Java services; XDoclet, Hibernate or other technology?

  by Kim Hansen on 2005-10-28 13:11:39

• Currently, on a Flex/J2EE project, we're using OpenAMF, our own lightweight J2EE framework with simple DAOs, etc. I'm not hung up on buzzwords all that much: Hibernate is cool but what we really need is transparent object persistence, not object-to-relational mapping which, imho, moves the code to another section of the app (not that I don't think it's great -- I just want more dammit!) :)
  
  Flash remoting makes it easy to use a very lightweight architecture server-side that compliments our lightweight client-side architecture in ARP.
  
  Note, btw, that my article was written long before Flex 2 and, although the concepts are the same, there is the additional AS2 -> AS3 conversion step -- at least until AS3 is available for Flash projects.

  by Aral Balkan on 2005-10-28 13:30:16

• 
  Thank you very much. This is going to be really helpful. I think it's great what you and others like you have been doing for the Flash/Flex community. I want to follow your example and contribute in any way I can.

  by murk on 2005-10-29 11:44:05

• Aral:
  
  Thanks for the article. I'm a Flex newbie, just starting to explore it now with the release of the 2.0 alpha. Your suggestion to subclass mx.core.Application makes a lot of sense to me, with the aim of maintaining traditional class files and so on. I'm having a hard time implementing this effectively in my own experiments however. I've been through a couple of iterations exploring this so far.
  
  My problem seems to stem from the fact that Flex compiles mxml Application files by generating a class that subclasses mx.core.Application, containing the specific properties and "methods" defined in one's mxml file. That's pretty cool, but there are a couple of consequences of this I haven't figured out how to work around:
  
  1. If I pass a reference of the mxml generated instance to another class ( a Controller for instance), I can't type the reference specifically. I can type it as mx.core.Application, but that will prevent the Controller from calling any subclass methods on the instance. And even knowing the name of the generated subclass, I haven't been able to successfully get the compiler to resolve the specific type.
  2. If I designate a custom subclass of mx.core.Application as the mxml's root container, it is still a generated subclass of that custom subclass that is instantiated. So any UI properties that I reference in my custom subclass don't exist there (even if I declare them), because I am declaring them in the mxml file, and thus in the generated subclass of my custom class.
  
  I tried rewriting your Flex 1.5 bug example from February (Fundamental bug in Flex Builder 1.5?), and couldn't get it to work because of the second reason -- neither aButton or aTextInput exist in the scope of ApplicationSubclass. Rather they exist in the generated subclass of ApplicationSubclass (in my case named FlexBuilderBug).
  
  So as far as I can tell at this point the best I can do is to define my custom subclass just within the mxml (using an included script file to be tidy), and accept the fact I can't specifically type it in any class I pass it as a reference to.
  
  Am I overlooking something basic here? Based on your tutorial and your February post it seems like Flex 1.5 behaved differently. Or maybe that was just a consequence of AS2.0 being less strict in some regards compared to AS3.0 -- like allowing identical (UI) properties to be declared in both a super and sub-class? I'm very curious if you have any insight into this, since I would really like to structure my code in the manner you suggest. I've omitted specific code examples in the interests of brevity, but would be happy to supply those if would help clarify my description of the issue.
  
  Thank you!
  

  by wruth on 2005-11-13 20:15:12