Flash Remoting.com
Home Book Examples Blog Resources About
Search

You are using an out-of-date browser so the pages will not display properly. Please update your browser.

Random thoughts on Flash Remoting:

This is where I get to ramble when I feel like it. Kind of like a blog, but it's not a blog. This is a blog. ;-).

6 posts in March 2003.

[ALL] 1/06 | 9/05 | 8/05 | 7/05 | 10/04 | 8/04 | 7/04 | 6/04 | 4/04 | 3/04 | 2/04 | 1/04 | 12/03 | 11/03 | 10/03 | 9/03 | 8/03 | 7/03 | 6/03 | 5/03 | 4/03 | 3/03 | 1/03 | 12/02 | 11/02

1-5 | 6-6

New updater for ColdFusion MX and Flash Remoting

Thursday, March 20, 2003 2:16:32 PM

ColdFusion MX Updater 3 was released yesterday, which also includes the Flash Remoting Updater 1. Anyone running CF MX should run the updater, available here:
http://www.macromedia.com/software/coldfusion/special/updater/faq/

Make sure you follow the installation instructions, especially if you are using IIS with CF MX.

The fixed issues in CF MX are listed here:
http://www.macromedia.com/support/coldfusion/releasenotes/mx/releasenotes_mx_updater01.html

The one big change that may affect your Flash Remoting web services is the fact that access to web services through the Flash Gateway is now DISABLED by default, which is a good thing, because it deals with the problem I discussed here. Unfortunately, there is still no way to individually enable services, but this is a step in the right direction.

If you are accessing web services, you'll need to manually enable the services once again by changing the WEB-INF\web.xml file. The <init-param> entry DISABLE_CFWS_ADAPTERS needs to be set to false -- it is true by default:

<init-param>
  <param-name>DISABLE_CFWS_ADAPTERS</param-name>
  <param-value>false</param-value>
  <description>When set to true, this setting disables the ColdFusion WebServices Adapters in the gateway.</description>
</init-param>

Also, one other change is the way that exceptions are handled from the Flash Gateway to Flash: they now have the same format in the Macromedia Flash client. The exception fields are Details, Description, Code, Type, RootCause.

Add comment (0)
View comments

Problems with Objects in Flash Remoting

Thursday, March 13, 2003 8:00:13 AM

When building a Flash Remoting application using OOP concepts, sometimes you can't encapsulate the logic as you want. There seems to be a problem with building objects that contain a Flash Remoting service as a property, such as in this code:

MyObject.prototype.init = function (myGateway_conn, myUrl) {
  this.service = myGateway_conn.getService(myUrl, this);
}

This is one way to encapsulate the functionality of MyObject, but if you try to send the object to the remote service, the call will fail. There are several workarounds, but none of them are really good. The way I've been doing it is to create a service outside of the object and pass the service to each method:

MyObject.prototype.myMethod = function(service) {
  service.myMethod(new Responder(), this);
}

Another way (utilized in Pet Market) is to copy the properties of the object into a new object (this code from Pet Market):

var userCopy = new Object();
var fld;
var useroid = this.userData["useroid"];
for(fld in this.userData) {
  userCopy[fld] = this.userData[fld];
}

The comments in Pet Market don't elaborate on this however, they merely say "TRICKY: apparently need to copy the userdata to a new object before sending."

Add comment (1)
View comments

Changes in Flash Remoting class code

Tuesday, March 11, 2003 1:31:11 PM

On March 10, 2003, Macromedia released the Flash Remoting Components Updater 1. The updater fixes many issues, which can be found at http://www.macromedia.com/support/flash_remoting/releasenotes/mx/releasenotes_updater.html. I was curious as to what actually changed in the ActionScript classes, so I ran Windiff on the Configuration > Include folder. I found out the following:

Overview

Most of the changes in the ActionScript code in the Flash Remoting classes involved setting up a variable to act as the loop end comparison, which improves the speed of the loop. According to the Macromedia site:

"The NetServices.as library's performance was boosted by improving the way in which an array's length is calculated in loop conditions."

For example, this statement:

var rcount = this.getLength();
for(var i = 0; i < rcount; i++) {
  // do something
}

is faster than this statement:

for(var i = 0; i < this.getLength();; i++) {
  // do something
}

The second looks more concise, but ActionScript evaluates this.getLength() each time through the loop. On a large loop, timesavings can be big.

Files Changed:

DataGlue.as

Minor syntax change to speed up a loop (line 41)

NetDebugEvents.as

Minor syntax change to speed up a loop (line 125)

NetDebugHelpers.as

Minor syntax change in two places to speed up loops (lines 217, 225)

NetDebugImpl.as

Minor syntax change in two places to speed up a loop (lines 25, 54)

NetDebugLocalConnection.as

Minor syntax change to speed up a loop (lines 96)

NetDebugNetConnection.as

Logic error change (lines 42, 72, 85)

Minor syntax change to speed up a loop (lines 211)

NetServices.as

Method added to NetConnection: AppendToGatewayUrl (lines 167-180 of new NetService.as file)

Section removed that deals with removing the host name and port from a URL passed to the Flash movie (removed lines 213-216 and 226-253 from original NetServices.as file). According to the Macromedia site:

"NetServices.as no longer modifies the defaultGatewayURL to match the serving SWF's server:port. The Flash Security Sandbox restricts movies from loading data outside the serving SWF's domain, not machine. The previous workaround was to always to provide either the URL directly in the createGatewayConnection method, or use the OBJECT/EMBED tags to provide gatewayURL parameter via HTML. This is no longer necessary."

RecordSet.as

Minor syntax change in three places to speed up a loop (lines 286, 425, 442)

Location change on a section of code that deals with getItemAt() method of client-side recordsets. (line 236)

RSDataProviderClass.as

The sort() method was not passing the correct information to updateView(). This has been fixed (line 116)

Minor syntax change to speed up a loop (line 125)

Documentation updates:

There are also numerous documentation updates too numerous to list here. I know there were a LOT of documentation errors in the first Flash Remoting Components help system. According to the Macromedia site:

"The HTML help files available within the Flash Remoting MX development environment now match the Using Flash Remoting MX document."

Well, I hope they fixed the errors as well. ;-)

Add comment (7)
View comments

Flash Remoting Updater Release 1

Tuesday, March 11, 2003 8:22:57 AM

Finally we have a Flash Remoting updater for all versions (CF, Java, ASP.NET)! There appear to be substantial bug fixes, but I have not tried it as yet. The URL is:

http://www.macromedia.com/support/flash_remoting/updaters.html

http://www.macromedia.com/support/flash_remoting/releasenotes/mx/releasenotes_updater.html

The major news is the disconnected RowSets in Java can now be serialized into RecordSets on the client. This was perhaps the biggest problem with Flash Remoting for J2EE. Without the use of a RecordSet, there was not a huge advantage to using Flash Remoting.

Be sure to read the installation instructions at http://www.macromedia.com/support/flash_remoting/updaters/release_1/installation.html

Add comment (1)
View comments

New Macromedia site

Thursday, March 06, 2003 6:48:16 PM

By now everyone has seen the new Macromedia site. This could have been a huge shot in the arm for Flash Remoting, but I think that the site is not really living up to the promises of Rich Internet Applications. For one thing, the navigation between pages is confusing at best, and many key links are hidden or buried where they are hard to find (such as the Exchange link buried on the Downloads page.)

The real problem with it is that it does NOT promote the technology that it is using. . .it simply makes it look bad. I know from my own experience how fast and powerful a Flash site can be using the Flash Remoting technology with a ColdFusion back end. The Macromedia site does not take advantage of any of it. There are way too many pages that load in separate applications. The whole concept of Flash Remoting is that you can create an interface that remains in the user's browser -- you should not have to load in a separate application each time you switch to another page. The AMF packets that Flash Remoting utilizes to pass information back and forth are tiny -- something like 1/4 the size of a similar XML packet.

The best example I've seen yet of a Flash Remoting application is the Pet Market app. This app really demonstrates what is cool about Flash Remoting. The MM site shows us everything that is wrong with Flash. I really want MM to succeed with Flash Remoting and I would love to see HTML become ancient history, but it needs to be promoted in such a way that people will want to use it. . .not shy away from it.

The Exchange is actually a complete FR application, and it has some great new features that make it better than the old Exchange. . .but that really isn't saying much because the old Exchange was absolutely horrible. I remember searches that took minutes and uploads that had to be done 5-10 times because of timeouts. There are still problems though:

All in all, I think they need to go back to the drawing board on this one. Sure, it has some really cool functionality, but on the whole it's not a good experience. I really wanted this to be the killer site that would bring Flash Remoting into the limelight, but as it stands I think it is doing the technology a huge disservice.

Add comment (0)
View comments

1-5 | 6-6