Attention: We have retired the ASP.NET Community Blogs. Learn more >

Flash Remoting

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?).

Network Latency
When using remoting in any environment, this quickly becomes an issue. It can be bad enough when you are remoting within the confines of your own server room, but remoting across the web brings an entirely new set of latency issues. The solution here would be to build an actionscript based facade (NOT a Cold Fusion based facade like the article suggests), but that could be quite a bit of extra work. Additionally, ECMAScript isn't exactly a true OO language, so that brings its own issues.

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).

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.

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.

Limitations of Flash
No nead to go over these again, but we are definately spoiled with all the power that the .NET framework gives us, suffice to say you can find plenty of discussion about this in previous posts on this blog.

Anyone know if Macromedia is doing anything do address any of these issues? John?

6 Comments

  • Regarding your last point, that's the value of the SharpVectors project. To let you do something like Flash remoting without having to learn more than .Net and XML (which is really required to truely understand .Net). SVG is just a specific XML namespace just like XHTML, no more no less, and SharpVectors lets you leverage that on the .Net platform.





    DonXML

  • Sounds really cool. What is the state of support right now? Like, if I were to use SVG, how many of my users would need upgrades and what would the typical SVG based web site require client side?

  • <i>"Anyone know if Macromedia is doing anything do address any of these issues? John?"</i>





    Sorry, Jesse, it's a full moon and I can't guarantee I can zoom in on the topic.... ;-)





    Is part of this "I'd like to make SWF apps in a text-based IDE"? If so, that's not possible now, although folks at Macromedia have been looking at various approaches to this problem for awhile. (UI components are a big step, for instance.)





    But I have the feeling I missed the core here...?





    jd/mm

  • I've found the best way to organize team development in Flash is to use MVC ActionScript. That allows developers to maintain their roles (db vs. UI). Refactoring leads to the establishment of components, which make life easier. It's a lot simpler for a developer to instruct a UI developer to create a method to answer a broadcast from said Model than it is to have one person doing all the ActionScript/Flash work. As for developing in the IDE, most serious Flash coders use a text editor and include their ActionScript files; you aren't trapped in the Flash IDE, but you do need it to test.

  • Some .NET Developers who read your article might believe the pure .NET value proposition (ASP.NET) beats the Flash hybrid (Flash+.NET remoting) approach hands down. However, any decent Software Engineer worth their weight would prefer to use the right tool for the job... whether that means ASP.NET, Java, or even (gasp!) Flash.





    Your prospective is equivalent to building a home using tools from a single manufacturer. Or maybe even limited to a single tool from this manufacturer (RE: Multiple Languages Required).





    My perspective understands that no one manufacturer will ever provide the best tools for each project I take on. And I'd be an idiot if I tried to build a house using only a Power Drill.





    Re: Network Latency... Depending on the project, I think Flash can actually shine here. AMF--the protocol used from Flash Remoting--is a binary format. The pipe into my datacenter is quite a bit more capable than that of the average household or business. The latency I'm most worried about is the last mile, and that's where AMF pays off.





    Flash is far from perfect. .NET is far from perfect as well. Next time you're at a project kick-off meeting, consider which tool or tools best meet the users' needs rather than trying to force on them a tool that might not make as much sense for their needs.

  • I really liked the article, and the very cool blog

Comments have been disabled for this content.