I read this quickly so may have missed something, but two thoughts came to mind:
1) Maybe XML doesn't have to work in AMF and some subclass like XMLAMF could. That would be more PAYG, and you might then make XMLAMF an IExternalizable instead of adding XML support to the AMF code. 2) Check out the SWFOverride metadata. It might do what you want. I'm not a fan of automatically changing imports. I would rather we use conditional compilation. HTH, -Alex On 3/7/19, 12:41 AM, "Greg Dove" <[email protected]> wrote: I meant to do this a few days back, but I continued to make some changes and improvements, so here goes: The amf_updates branches of compiler and asjs have the following changes related to AMFBinaryData: -The BinaryData base class had a minor shift with the writeBytes/readBytes methods. The original method signature for this method continues to be available as writeBinaryData/readBinaryData. The change was made to conform to the original flash interface (and appear the same in javascript). More on this in discussion points below. -AMFBinaryData now extends from BinaryData, and IDataInput, IDataOutput both extend from IBinaryDataInput and IBinaryDataOutput (but also the native IDataInput and IDataOutput in flash). This means that ByteArray code should be more easily ported to royale. -The main serialization/deserialization support in javascript happens in a separate internal class. It uses Array when writing into its local buffer as before and Uint8Array from the main instance when reading. This class is also a subclass of BinaryData, so re-uses the original methods from that for certain things that had different implementations before (e.g. UTF and Double) Additional support has been added for: -IExtenalizable - decoding and encoding support added for instances of classes implementing IExternalizable related: updates to mx.collections ArrayList and ArrayCollection. org.apache.royale.collections.ArrayList mean that these items now implement IExternalizable This has been tested with mx ArrayCollection in the local AMF example project (examples/amf/SampleAmfWebApp and examples/mxroyale/RemoteObjectAMFTest) Also verifed to work with royale ArrayList in Carlos' project (with alias remap from ArrayCollection to royale ArrayList) -Support for 'dynamic' dynamic classes are now supported based on updates in reflection data (some limitations based on compile settings, but hopefully unlikely in most scenarios). -IDynamicPropertyWriter support is added. This was something I was unfamiliar with in flash, because I had never used it, but I suspect it might be more useful in javascript. You can see the original actionscript reference here [1]. Basically it allows for control over the serialization of dynamic fields. So you could ignore fields starting with underscore, for example. Or combine fields in a calculation to write a new field that was not the same as the original object, etc. This might be useful for plain Objects being sent to the server. -XML encoding/decoding support is added. This has been only tested briefly so far. The AMFBinaryData class does not have a hard dependency on the XML class, so the main project or some library would need to have a dependency on XML for this to work in javascript. An error is thrown in javascript when reading XML if the class is not available. I am working on some minor fixes to XML to get identical results to flash with stringification. I am part-way through porting all the trace outputs in the XMLTest project to UnitTests to verify that everything else will work as before, after my (small) changes. The change I am making will allow for identical byte match tests between flash and javascript for AMF encoding of XML (because toXMLString will be identical output) Discussion notes ----------------------- @Harbs, could you please take a look at the amf_updates branch when you get a chance, I think you were concerned about changes to BinaryData.... which leads me to: Changes to BinaryData writeBytes and readBytes using ByteArray in flash and ArrayBuffer in javascript This needs to happen in flash if AMFBinaryData is to implement the same IDataOutput/IDataInput as swf. That may not be necessary in the end, because the interfaces are a little funky, but I personally think it is better to keep it the same as the original. I think readBytes and writeBytes in js having ArrayBufffer as the 'native' byte data argument is right, but others may disagree. ArrayBuffer is the native xhr.response and outputs from things like ImageData (similar to flash.display.BitmapData iiuc), so it seems better than Uint8Array to me (Uint8Array is never far away from ArrayBuffer anyway). I was hoping to have a set of interfaces that could support the AMF related variations (IExternalizable, IDynamicPropertyWriter) which would be single, common imports for both swf and js targets. But because these are interfaces expressing methods with arguments that typed with other interfaces on swf, you can't get a conforming implementation by using an extended interface of the argument type used in the main interface (although, perhaps surprisingly, it does compile ok on swf target - it just has a runtime error on instantiating the class). And because it is expected in native code we cannot change anything here without rewriting everything for swf to work in the same way that we are doing in javascript (which does not make sense to me). So we can import a common interface for the main implementing class, but not for the interface types it uses in its methods. Options to avoid double imports of the inner interfaces (the ones used in the method arguments defined by the parent interfance) include: -Matching the original flash package names in javascript for these interfaces. flash.utils.* This would be the cleanest way to do things, but I think it is contrary to established practice. -Using some kind of automatic remap of the newer royale-specific interfaces to flash.utils. and flash.net interfaces for swf target in the compiler. This would replace imports of the royale classes to imports of the original flash interfaces in the compiler. I am not sure yet how easy this would be. It is probably some sort of automatic import aliasing like Josh implemented. If that was possible to implement as metadata on the original class definition that would be the most flexible here (not sure whether that is possible, it would be something different to [ExcludeClass]) Where to from here. I am currently working on porting the XML trace-out/console.log tests across to UnitTests with assertions. I have made a small change in XML class locally that fixes the stringification I think (so now the AMFEncoding matches flash), but I will test it against all the tests that I can see with XML to make sure it doesn't affect anything else. Small messages. Carlos tried this, but it wasn't working. Maybe there is a need to change something in AMFNetConnection here, I am not sure yet. I will investigate more tomorrow and see if I can get this working. Vector and Dictionary These are the remaining Objects not yet implemented (correctly) for amf encoding. I will take a look at Vector before too long. I know Joshua Granick was looking at something here too, but if nothing else took place yet, I will be keen to figure out something that could work for redlection/serialization. I have personally used Vectors in AMF in the past, but not XML or Dictionary (but I think we should be able to do something for Dictionary too). that's enough... this is already too long... </endOfSaga> 1. https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fhelp.adobe.com%2Fen_US%2FFlashPlatform%2Freference%2Factionscript%2F3%2Fflash%2Fnet%2FObjectEncoding.html%23dynamicPropertyWriter&data=02%7C01%7Caharui%40adobe.com%7C08bdce3231a04acdd59508d6a2d8c250%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636875449190432111&sdata=MTZNF1swW8T95N6yD2eURyZIoFjXKjPJ3qK6wp4m290%3D&reserved=0
