2 Replies Latest reply on Jul 11, 2007 1:39 PM by Newsgroup_User

    Complex data and Messaging

    FerrieJB Level 1
      Hi,

      I'm a fairly experienced developer of Flex2 and FDS but just now I've hit a snag I can't seem to resolve on my own.

      I'm using RTMP messaging to send Actionscript objects from one Flex app to another, both running at the same time on the same server, subscribed to the same destination and subtopic.

      The objects are sent in the AsyncMessage.body part, just as many tutorials and training manuals use in their examples.

      The received data is handled by a function that read the MessageEvent.message.body which is typed as Object.

      The examples by Adobe always show how this property can simply be cast back into its original type like this for instance:

      var myCollection:ArrayCollection = event.message.body as ArrayCollection

      Also it's noted that the body property of the AsyncMessage object can hold any Object, built-in Flex component or custom ActionScript object and that these can also be cast back into their original types.

      Now I have written several custom AS3 classes, object instances of which need to be sent to a messaging destination just like this, only it won't work...

      The event.message.body does contain the information, typed as an Object. That seems to work and all data is there, even of the most complicated classes, but as soon as I cast this result back into int original type using the keyword "as" it only returns "null" (which, according to Flex documentation, happens when the left expression is not an instance of the class right of the keyword). So someway or another during serialization and deserialization my datatype is lost.

      It's fairly easy to reproduce in an isolated Flex app. At these two links are MXML files I used to reproduc the same behaviour using a simple Array object. Now that should really give no problem, but is seems it does! If I send String or Date it works fine and I am able to cast it back in to their original types no problem. But Array is broken?!

      http://gozo.infoprofs.nl/ferrie/testA.mxml
      http://gozo.infoprofs.nl/ferrie/testB.mxml

      Has anyone had any experience like this? Am I missing something? Please help, I'm in the middle of a big project and this comes at a most unfortunate time during development, so help would be really appreciated.

      Thanks,
      Ferrie Bank
        • 1. Re: Complex data and Messaging
          FerrieJB Level 1
          Ok, the immediate pressure is off: I decided to do a workaround and use XML messages for communication as this does seem to work .

          Only I'm still very much interested in hearing more about this, because using XML has all kinds of drawbacks. There is less separation of concerns in my classes due to the fact I have to be able to generate the XML strings from different places.

          I was really relying on the fact I could use complex data objects in messaging and my question is: did I implement is wrong, or is Flex DS broken or did I simply misunderstand the possibilities and isn't it supposed to be possible after all?

          Anyway, I also registered a call with the Dutch Adobe Technical Support and they're escalating to an expert, so...
          • 2. Re: Complex data and Messaging
            Level 7
            For the case where custom typed ActionScript objects are being used but are
            seen as anonymous Objects by the receving application, the following causes
            may be the issue:

            1. You don't have the correct [RemoteClass] metadata on your custom AS3 classes.

            2. You have the correct metadata, but you haven't imported and referenced
            the custom AS3 class anywhere in your application so it wasn't linked into
            the SWF and thus isn't available at runtime.
            3. You've decided to register a class alias yourself via the low-level flash.net.registerClassAlias()
            function but this wasn't called before a remote instance of the type was
            received.

            For the case where your message.body isn't of the type you'd expect, like
            Array or ArrayCollection - that's a little tricker to say why in the AS-to-AS
            (via message service) case. If ClientA creates an Array then on the server
            that will be an Object[] and thus sent to ClientB as an AMF 3 Array. If,
            however, the server were to generate it's own collection type, say java.util.ArrayList,
            remember that that would appear as an mx.collections.ArrayCollection back
            in the Flex client and Array and mx.collections.ArrayCollection cannot be
            directly cast to one another. I don't think this latter scenario is what
            is happening here as your client is the one creating the body of the message.

            You should consider turning on Debug level logging in /WEB-INF/flex/services-config.xml
            and ensure that the ConsoleTarget has a filter to watch for Endpoint.* to
            see just what exact AMF type is being received and sent by the MessageBroker
            in FDS.


            Pete




            Hello FerrieJB,

            > Hi,
            >
            > I'm a fairly experienced developer of Flex2 and FDS but just now I've
            > hit a snag I can't seem to resolve on my own.
            >
            > I'm using RTMP messaging to send Actionscript objects from one Flex
            > app to another, both running at the same time on the same server,
            > subscribed to the same destination and subtopic.
            >
            > The objects are sent in the AsyncMessage.body part, just as many
            > tutorials and training manuals use in their examples.
            >
            > The received data is handled by a function that read the
            > MessageEvent.message.body which is typed as Object.
            >
            > The examples by Adobe always show how this property can simply be
            > cast back into its original type like this for instance:
            >
            > var myCollection:ArrayCollection = event.message.body as
            > ArrayCollection
            >
            > Also it's noted that the body property of the AsyncMessage object can
            > hold any Object, built-in Flex component or custom ActionScript object
            > and that these can also be cast back into their original types.
            >
            > Now I have written several custom AS3 classes, object instances of
            > which need to be sent to a messaging destination just like this, only
            > it won't work...
            >
            > The event.message.body does contain the information, typed as an
            > Object. That seems to work and all data is there, even of the most
            > complicated classes, but as soon as I cast this result back into int
            > original type using the keyword "as" it only returns "null" (which,
            > according to Flex documentation, happens when the left expression is
            > not an instance of the class right of the keyword). So someway or
            > another during serialization and deserialization my datatype is lost.
            >
            > It's fairly easy to reproduce in an isolated Flex app. At these two
            > links are MXML files I used to reproduc the same behaviour using a
            > simple Array object. Now that should really give no problem, but is
            > seems it does! If I send String or Date it works fine and I am able to
            > cast it back in to their original types no problem. But Array is
            > broken?!
            >
            > http://gozo.infoprofs.nl/ferrie/testA.mxml
            > http://gozo.infoprofs.nl/ferrie/testB.mxml
            > Has anyone had any experience like this? Am I missing something?
            > Please help, I'm in the middle of a big project and this comes at a
            > most unfortunate time during development, so help would be really
            > appreciated.
            >
            > Thanks,
            > Ferrie Bank