views:

472

answers:

10

I have a large codebase that targetted Flash 7, with a lot of AS2 classes. I'm hoping that I'll be able to use Flex for any new projects, but a lot of new stuff in our roadmap is additions to the old code.

The syntax for AS2 and AS3 is generally the same, so I'm starting to wonder how hard it would be to port the current codebase to Flex/AS3. I know all the UI-related stuff would be iffy (currently the UI is generated at runtime with a lot of createEmptyMovieClip() and attachMovie() stuff), but the UI and controller/model stuff is mostly separated.

Has anyone tried porting a large codebase of AS2 code to AS3? How difficult is it? What kinds of pitfalls did you run into? Any recommendations for approaches to doing this kind of project?

+5  A: 

Some notable problems I saw when attempting to convert a large number of AS2 classes to AS3:

Package naming

class your.package.YourClass
{
}

becomes

package your.package
{
    class YourClass
    {
    }
}

Imports are required

You must explicitly import any outside classes used -- referring to them by their fully qualified name is no longer enough.

Interface methods can't be labelled 'public'

This makes total sense, but AS2 will let you do it so if you have any they'll need to be removed.

Explicit 'override' keyword

Any functions that override a parent class function must be declared with the override keyword, much like C#. Along the same lines, if you have interfaces that extend other interfaces and redeclare functions, those overrides must be removed (again, as with public, this notation didn't make sense anyway but AS2 let you do it).

All the Flash builtin stuff changed

You alluded to this above, but it's now flash.display.MovieClip instead of just MovieClip, for example. There are a lot of specifics in this category, and I didn't get far enough to find them all, but there's going to be a lot of annoyance here.

Conclusion

I didn't get to work on this conversion to the point of success, but I was able in a matter of hours to write a quick C# tool that handled every aspect of this except the override keyword. Automating the imports can be tricky -- in my case the packages we use all start with a few root-level packages so they're easy to detect.

lilserf
A: 

@lilserf

For the Flash built-in stuff. Does it still generally work the same, just the packages changed? For instance, would it be possible to do a phased approach, where I first convert all the code, but leave the UI stuff using dynamically generated/attached MovieClips, then once that's working redoing the UI properly? I kind of figured the way I'm doing the UI wouldn't really work anymore, but if it would then that could make porting it easier, as I could get something working much sooner.

Herms
you should have made this a comment, not an answer. misusing answers as comments clutters up the display, and it makes it confusing to read later (since the order of answers can change)
davr
Comments didn't exist when I added this. :)
Herms
A: 

@Herms

I think a lot of it works the same, but there are probably key areas you will have to change (attachMovie, createEmptyMovieClip etc). Unfortunately I don't have a lot of info in this area -- I ran out of time dealing with the earlier issues and didn't get to see many of the API incompatibilities.

lilserf
A: 

@Herms - I'm pretty sure that you cannot do a phased approach.

Once you set the main SWF to use AS3, everything in that SWF has to use AS3. If you are loading in external SWFs, you technically could still use AS2 for those - but you can't interact with them or control them, so they are really just glorified images at that point. Also, loading in AS2 SWFs can cause a ton of headaches - so I would not recommend doing it unless you really have to.

EDIT: @Herms I did misunderstand that. You still might run into some problems generating the UI, but it's worth a shot. You'll propably have to take it on a case by case basis and plug the holes as they come.

You'll definitely run into issues with loading the v7 SWFs. I beat my head against the wall several times with a site I was working on last year. Some of the loaded modules still don't work properly.

81bronco
A: 

@81bronco:

I think you slightly misunderstood my "phased approach". In phase 1 I would still convert the AS2 code to AS3 so that it's an AS3 SWF, it would just stick with generating the UI programatically using MovieClips, just tweaked to do it however it's done in AS3. Then, phase 2 would be to implement the UI in MXML using real components, and remove the MovieClip stuff.

Unfortunately, I'll have to deal with loading old Flash 7 SWFs regardless, but I think having my code in Flex will actually make dealing with it a bit easier, since there will be an extra bit of sandboxing around the Flash 7 SWF (it does some annoying global stuff when it's loaded. Don't get me started...). But that's not really relevant. :)

Herms
+1  A: 

First off, I hope you're not using eval() in your projects, since there is no equivalent in AS3.

One of the things I would do is go through Adobe's migration guide (which is basically just an itemized list of what has changed) item by item and try to figure out if each item can be changed via a simple search and replace operation (possibly using a regex) or whether it's easier to just manually edit the occurrences to correspond to AS3. Probably in a lot of cases (especially if, as you said, the amount of code to be migrated is quite high) you'll be best off scripting the changes (i.e. using regex search & replace) and manually fixing any border cases where the automated changes have failed.

Be prepared to set some time aside for a bit of debugging and running through some test cases as well.

Also, as others have already mentioned, trying to combine AS2 SWFs with AS3 SWFs is not a good idea and doesn't really even work, so you'll definitely have to migrate all of the code in one project at once.

hasseg
A: 

Migrating a bigger project like this from as2 will be more than a simple search and replace. The new syntax is fairly similar and simple to adapt (as lilserf mentioned) but if nothing else the fact that as3 is more strict and the new event model will mostly likely cause a lot of problems. You'll probably be better off by more or less rewriting almost everything from scratch, possibly using the old code as a guide.

Migrating from as2 -> as3 in terms of knowledge is fairly simple though. If you know object oriented as2, moving on to as3 won't be a problem at all.

You still don't have to use mxml for your UI unless you specifically want to. Mxml just provides a quick way to build the UI (etc) but if you want to do it yourself with actionscript there's nothing stopping you (this would also probably be easier if you already have that UI in as2 code). Flex (Builder) is just a quick way to do stuff you may not want to do yourself, such as building the UI and binding data but essentially it's just creating a part of the .swf for you -- there's no magic to it ;)

Antti
+1  A: 

Here are some additional references for moving from AS2 to AS3:

Grant Skinners Introductory AS3 Workshop slidedeck http://gskinner.com/talks/as3workshop/

Lee Brimelow : 6 Reasons to learn ActionScript 3 http://www.adobe.com/devnet/actionscript/articles/six_reasons_as3.html

Colin Moock : Essential ActionScript 3 (considered the "bible" for ActionScript developers): http://www.amazon.com/Essential-ActionScript-3-0/dp/0596526946

mike chambers

[email protected]

mikechambers
+1  A: 

My experience has been that the best way to migrate to AS3 is in two phases - first structurally, and second syntactically.

First, do rounds of refactoring where you stay in AS2, but get as close to AS3 architecture as you can. Naturally this includes moving all your frame scripts and #include scripts into packages and classes, but you can do more subtle things like changing all your event listeners and dispatchers to follow the AS3 flow (using static class properties for event types, and registering by method rather than by object). You'll also want to get rid of all your "built-in" events (such as onEnterFrame), and you'll want to take a close look at nontrivial mouse interaction (such as dragging) and keyboard interaction (such as detecting whether a key is pressed). This phase can be done incrementally.

The second phase is to convert from AS2 to AS3 - changing "_x" to "x", and all the APIs, and so on. This can't be done incrementally, you have to just do as much as you can in one fell swoop and then start fixing all the compile errors. For this reason, the more you can do in the first phase, the more pain you avoid in the second phase.

This process has worked for me on a reasonably large project, but I should note that the first phase requires a solid understanding of how AS3 is structured. If you're new to AS3, then you'll probably need to try building some of the functionality you'll need to be porting. For example, if your legacy code uses dragging and drop targets, you'll want to try implementing that in AS3 to understand how your code will have to change structurally. If you then refactor your AS2 with that in mind, the final syntax changes should go smoothly.

The biggest pitfalls for me were the parts that involved a lot of attaching, duplicating and moving MovieClips, changing their depths, and so on. All that stuff can't really be rearchitected to look like AS3; you have to just mash it all into the newer way of thinking and then start fixing the bugs.

One final note - I really wouldn't worry about stuff like import and override statements, at least not to the point of automating it. If you miss any, it will be caught by the compiler. But if you miss structural problems, you'll have a lot more pain.

fenomas
A: 

Whatever you do, PLEASE make the change from AS2 to AS3 and don't try to maintain a Flash 7 / AS2 code base. It's old and wrong, and it's only going to get older and wronger.

Iain