FYI, I just added an “array” getter which returns the underlying array of bytes. The exact type is different on the different platforms.
Alex, I tried to make the type “TypedArray” instead of “Uint8Array” on the JS side, but TypedArray was not recognized for some reason. Any ideas on why that might be? Harbs On Jul 14, 2016, at 9:33 AM, Greg Dove <greg.d...@gmail.com> wrote: > Harbs and Alex, thanks for your explanations. > > I guess 'drop-in' replacement is quite unrealistic. But I think if could be > closer to the IDataInput/IDataOutput, and given that ByteArray is a common > utility class in many libraries, particularly for low-level parsing of > various formats, the closer the better imo. > > In my experience most ByteArray use seems to be mostly sequential reading > or writing which uses the flash class' read/write methods instead of array > access. So in terms of migration effort, swapping array access out wherever > it is used to the method-based getByteAt, setByteAt is not so bad. > > Harbs, I picked up the recent updates from nightly and there is more there > than what I had for sure, but more to do I think - perhaps I can help - I > will try to work on this over the next day or so and share where I get to. > After using Flex for 8 years I am kinda struggling with my setup for > FlexJS, and I'm not sure if I can use monkey-patching for checking the > additions I have in mind.... which I could do in the past with the regular > flex sdk. > > > cheers > Greg > > > On Wed, Jul 13, 2016 at 6:46 PM, Alex Harui <aha...@adobe.com> wrote: > >> >> >> On 7/12/16, 3:57 PM, "Greg Dove" <greg.d...@gmail.com> wrote: >> >>> I have dipped my toes into FlexJS for the first time. I am evaluating >>> FlexJS for a migration away from Flex4/flash and figured I would try to >>> cross compile an isolated a3 library that is a core dependency for my >>> client's project. >>> >>> It seems there is no direct substitute for flash.utils.ByteArray on the js >>> side, The nearest I could find was org.apache.flex.utils.BinaryData which >>> seems to be a partial proxy implementation for ByteArray. >>> >>> BinaryData does not implement IDataInput and IDataOutput and therefore >>> cannot simply be used in place of the original ByteArray in arbitrary >>> code. >>> >>> Is this intentional? Or is this WIP, with a plan to get to the original >>> interfaces? Or am I looking in the wrong place for what I am trying to do >>> (entirely possible!). >> >> IMO, FlexJS is a WIP, but there is no "plan" per-se. >> >> Unlike Flex, FlexJS is intended to support multiple component sets. The >> Basic set we have released so far is meant to thinly wrap Browser/HTML/JS >> APIs so that when you compose an application, the result has as little >> overhead as possible when compared to writing an HTML/JS app directly in >> JS. It isn't a goal for these components to emulate Flash. Instead, the >> SWF versions of those components are trying to emulate the browser. >> >> There is an experiment under way to try to see how hard it would be to >> make a component set that supports most (but not all) Flex APIs. We >> received several opinions that the Basic set is too big of a migration >> step for existing Flex code bases. Flex is already heavy so making a >> heavy component set that lowers migration pain by spending code on >> emulating more of Flex in the browser might be viable. This component set >> is a ton of work and isn't a top priority on my list right now and could >> use more volunteers to help. >> >> ByteArray isn't even a Flex API. But it is often used so I suppose a >> component set that emulates Flex will likely have to support most of >> ByteArray. The Basic set is supposed to be pay-as-you-go and use plugins >> for additional functionality, so IDataInput/IDataOutput might be replaced >> by plug-ins that support similar APIs. >> >> But really, what actually happens is often up to the person that codes it. >> We don't have resources to mark every API as needing implementation, and >> since we want to make many implementations as plugins, the API may not be >> the same anyway, so we just need folks to jump in and deal with holes in >> the documentation and code and help make things better for the next person >> who jumps in. >> >> HTH, >> -Alex >> >>
