Hi, so recently I ran into some major confusion when working with ByteArray. I had built a Haxe/OpenFL application that wrote a ByteArray to a file, and I found that I was unable to read the file from a separate Haxe app unless it was exported to the same target (i.e. CPP apps couldn’t read AIR-generated files, and AIR apps couldn’t read CPP generated files). I eventually solved this issue by manually setting the endian behavior to match everywhere in my code where I call new ByteArray() in both apps.
It’s my understanding now that this is expected behavior. Majority rules and the final verdict for endian behavior appears to be leaving it up to the platform to decide.
I think it would be a good idea to document this behavior somewhere so newcomers with a Flash background don’t run into “unexpected” expected behavior. As many developers migrate over to OpenFL from Flash, one might assume OpenFL’s ByteArray class is designed to behave universally across targets.
I think the API reference pages for the ByteArray or ByteArrayData classes might be good places for this to be explained, as this is where I was looking when I was trying to debug my issue (I eventually had to figure it by lucky guess, as similar issues people were having didn’t quite sound like mine). The Endian class could also probably use a modification in its description, as it describes how big endian is more common when communicating with servers, while little endian is more common with Intel architecture.
It seems probable that Flash defaulted to big endian in its API since it was designed to be used in a web environment. If this behavior is different with OpenFL for certain reasons I think it would be beneficial to officially document them so it is understood how files generated from ByteArray instances are not going to be cross-compatible with different targets unless endian order is manually enforced.
Anyway, would love to hear thoughts on this matter. If this is already documented somewhere and I missed it, a link would be appreciated as well!