AppendToGatewayUrl

June 22nd, 2009 by Rob

If you’re using BlazeDS and seeing an error involving a callback called “AppendToGatewayUrl” this might help.

AppendToGatewayUrl modifies the gateway of a NetConnection object with the session id (in this case “jsessionid”) of the current session. If you reconnect with this value appended to the gateway URL, your session can be identified, even on clients that do not use cookies.

There are two ways to handle this:

  • set NetConnection.client to an object that implements the AppendToGatewayUrl function, or;
  • subclass NetConnection to implement it (since NetConnection.client points to the NetConnection instance by default, you can not reassign the client field if you want this method to work).

There’s one caveat to both approaches, though. It has been my experience that if you call NetConnection.connect while you are receiving a response to bundled remote methods, the data may be lost or a “Client.Data.UnderFlow” error thrown. This occurs because AppendToGatewayUrl gets called after the first result, and the immediate call to NetConnection.connect aborts the rest of the transfer.

Here’s a sample implementation of option A:

public class Sample{

  private var conn : NetConnection;

  public function Sample(){
    conn = new NetConnection();
    conn .client = this;
    conn .connect(‘http://localhost/gateway’);
  }

  public function AppendToGatewayUrl(extra:String):void{
    conn .connect(conn.uri + extra);
  }

  public function load():void{
    conn .call(’service.load’,new Responder(loadResult,error));
  }

  private function loadResult(value:*):void{
    trace(‘value’,value);
  }

  private function error(err:*):void{
    trace(‘error’,err.message);
  }

}

To get around the problem with bundled calls, you could save the session id in a field and reconnect before the next call.

Posted in ActionScript, BlazeDS, FLEX, Flash | Comments Closed

Why Does Flash Delete your Timeline Code?

June 15th, 2009 by Rob

If you’ve tried to load one swf into another and found that the loaded clip’s timeline code has disappeared, you’re not alone. Fortunately, the explanation is simple.

Usually what happens is, you’ve tried to cast the reference to the loaded swf to its document type, like so:

var page : MyDocumentClass = loader.content as MyDocumentClass;
page.doSomeMethod();

If doSomeMethod, for example, plays an animation on the timeline that you have governed with “stop” commands, or that calls methods in the document class, you’ll find that it doesn’t work.

Why? Because you’ve embedded the class definition in the parent movie, and it doesn’t know about the timeline code. Think about it: adding timeline code to a movie effectively makes that movie a subclass of its document class. When you embed a reference to the document class in the parent, the version associated with the child movie (with the timeline code) isn’t used.

An associated problem is that you’ve defeated some of the key reasons for modularizing your sites – to make updates easier, and load code only when it’s needed, not before. Embedding the document classes of your loaded movies defeats the former – because you have to recompile the parent as well as the child when you update the child, and the latter – because you’re loading all the child classes in the parent.

How to solve the problem, then? use interfaces. Make all of your document classes implement a single interface and make absolutely sure that no references to the document classes exist anywhere in the parent movie.

For example, here’s a child movie class:

public class MyChild extends MovieClip implements IChild{
  public function transitionIn():void{
    gotoAndPlay(’somewhere’);
  }
}

As you can see, MyChild implements IChild, an interface:

public interface IChild extends IEventDispatcher{
   function transitionIn():void;
}

Now, in your parent movie, you’ll use something like this:

private function movieLoaded(evt:Event):void{
  var child : IChild = loader.content as IChild;
  child.transitionIn();
}

Notice that you’re calling a method on the interface, not the document class. In fact, the parent movie should be completely agnostic where the doc classes are concerned. The interface is enough.

Posted in ActionScript, Flash | Comments Closed