Updated: 01/05/2003; 17:01:52.
Andrew Stopford's Weblog
Info and thoughts on .NET, Rotor, Mono, PHP and Flash MX


This is the personal BLOG of Andrew Stopford. All comments and views made here are my own and not in any way related to my employer.
        

17 April 2003

Flash Remoting. - [Jesse Ezell Blog]

Following the link John Dowell left in his great comments about PPT -> SWF conversion, I eventually stumbled upon this article about using remoting in Flash MX (for those who are not aware, you can actually use remoted J2EE and .NET components from the Flash player starting with MX). Turns out that the Macromedia community's interest in design patterns is increasing as well. The difference is that it is a really new thing in the Flash community, and you generally are dealing with simpler patterns, not enterprise level patterns (still pretty cool nonetheless).

In any case, I think any .NET developer who reads the article will quickly realize why the pure .NET value proposition (ASP.NET) beats the Flash hybrid (Flash+.NET remoting) approach hands down (for example, moving all your remoted object's fields into a dictionary and using that dictionary for your get and set operations kind of defeats the point of using objects in the first place, doesn't it?).

Jesse makes some good points here. A few things stand out though.


Multiple Languages Required
So, you solve the network latency issue, but now you have a matinence headache. The number of developers on the planet who are fluent in both C# / VB.NET and ActionScript is very small. Yes, ActionScript is just JavaScript inside of the flash player, but because it runs inside of the Flash player and not in an HTML page, there is a lot of stuff going on that the avg. C# / VB.NET developer isn't going to recognize / understand at first glance. Additionally, just about any developer can lay out some WebForms pages, add his even handlers, set some properties, do some databinding, etc. and have a complete app ready to go. Creating the equivilent app in Flash is a bit more involved. As a result, you are probably going to need a team of ActionScript gurus to do the UI layer and a team of .NET junkies on the back end. Not to bad as long as the worlds don't collide, but if the UI team has a problem with one of the .NET components, the two teams are going to have a hell of a time trying to communicate (can't just "send over the source code" on this one).

This is an age old problem and it one that faces a designer/developer team where the technology crosses over. Its a problem that Macromedia Generator faced and to some degree never overcame. The solution may be to level the playing field, find some way of getting designers and developers using the same language. SSAS for .NET, why not.

Multiple IDEs Required
In addition to needing to deal with multiple languages, you now have a project that is split across two entirely different IDEs. One of which has no Source Control support and doesn't exactly support team development. This, again, limits the ability of teams to communicate because of the same issues. Even if you're backend team did understand ActionScript enough to take a look at some source code, you can't just tell them take a look at "AccountDetails.aspx lines 20-50" or even send them the source file that is causing the problem, because if you send the FLA they can't read it unless they have Flash (and know how to use it... flash files are timeline based, not file based, so a VS.NET dev could have a boatload of fun trying to track down the line of code that the dev was referring him do), if you send the SWF file, it is like sending a DLL, it doesn't really do any good unless you really enjoy decompiling things.

If Macromedia could find a way to integrate Flash support into the VS.NET IDE, this would be very cool and eliminate a lot of issues.

I don't think this would work, Flash authoring would not fit well into the VS.NET IDE. How do you overcome this problem, well the above may help. You could also possibly allow for AS files to be external files (like JS for example) in this way you can have the UI and the code that sits behind it (which address's the point below).

ActionScript UI Layer
Creating your entire UI layer in ActionScript is like going back to ASP and COM+. Yah, you get to compile your business logic. Great, but you still have spagetti code all over the place because UI layer is a mess. Some support for something like ASP.NET's code behind would be great (put your logic in a C# dll on the server). I admit, this would probably be fairly difficult for the Flash team to accomplish, but it could at least provide a door into the .NET world and would be a very cool utility.


1:10:37 PM    comment []

© Copyright 2003 Andrew Stopford.
 
April 2003
Sun Mon Tue Wed Thu Fri Sat
    1 2 3 4 5
6 7 8 9 10 11 12
13 14 15 16 17 18 19
20 21 22 23 24 25 26
27 28 29 30      
Mar   May


Click here to visit the Radio UserLand website.

Subscribe to "Andrew Stopford's Weblog" in Radio UserLand.

Click to see the XML version of this web page.

Click here to send an email to the editor of this weblog.