portable. For some, that's an important consideration, and for some,
it's not.
Depends on how you look at "portable". At the end of the day a Flash app
can only access a server resource if it resides on the same server as
the published SWF file or if crossdomain.xml allows it. If you have
access to the server it really only makes sense to take advantage of the
Remoting performance boost. Remember Remoting works with SOAP but the
deserialization occurs on the server not the client so the issue of SOAP
vs Remoting really isn't there.
2. Not all browsers support Flash Remoting. Last time I checked,
Mozilla and Opera were not compatible. Hopefully that's changed by now
(anyone know?), but there are always legacy browsers to consider.
Works in my firebird mozilla browser. Always has.
3. I have found Flash Remoting and AMF to be more robust than the web
service implementations I have used. I have forced myself to use web
services in newer projects rather than Flash Remoting just to get the
experience, and I have found bugs in both the Flash implementation and
in Apache Axis which caused a lot of frustration and would have been
avoided if I had used Flash Remoting. So far, I have not run into any
significant bugs with Flash Remoting that I can recall.
Very true.
The bottom line is, as always, there is no single answer that is right
for everyone. I think it's a decision that has to be made on a project
by project basis. The only absolute I can offer is to encapsulate the
communication mechanism enough to allow you to change your mind later
on down the road.
This is the best advice. Create a service delegate in actionscript to
hide the implementation-- then it doesn't matter if you choose Remoting,
SOAP, LoadVars or even just fudging the data until the backend is
complete.
[Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
