First, since many people seem to wonder why anyone would use AIR and support seems to have been dropped from Haxe, we use it as a PC development environment for mobile targets. On device, we run native code to implement the same functionality. We need AIR as opposed to Flash because of the need for setting custom headers in URLLoader which Flash prohibits, the need to intercept redirects and and the need for HtmlLoader to simulate the device’s in-app browser. All of this works in the AS3/AIR app but switching to Haxe we lose these key features leaving it non-functional for development work.
I have kludged work-arounds for the intercepts and HtmlLoader, but I cannot access certain web APIs without the headers.
It seems like I might be able to create some external API references and use adl for the run-time, but I’m not sure how nicely this will play and if I would lose debugging in FlashDevelop. The AirHelper.hx file has been commented out and from looking at what it takes for a Flash target, it looks like the helper is only a small piece.
I’m a very experienced programmer, but have I am new to Haxe and OpenFl, so general answers that presume that I know how the magic happens will probably be unhelpful. I’m more than happy to contribute back if others find AIR useful for this type of development.
FYI: Our app will not build in Neko due to what appear to be bugs in Neko and (static initialization compile errors in generated code from source that works in Flash) and run-time errors in parseInt() (that also works in Flash) even if I comment out the other things. All this just to say, let’s assume that I really do need to run AIR.
Then I believe it is just like a Flash build, with additional externs defined.
The real custom logic was probably in the AIRHelper code (which we thankfully still have), to package and run the project properly.
It would be possible to modify FlashPlatform and make it recognize an “air” target flag, or to possibly extend FlashPlatform with an AIRPlatform class, which reuses key Flash platform logic, while adding extra build steps or changing the run step
I can be available to discuss this, I might to want to talk more if you think AIR is worth being permanently supported, we could consider making AIR externs hosted in OpenFL proper, so no extra haxelib is needed for this
Thanks for the reply. I had wondered the same thing–if extending FlashPlatform was the way to go, but I’m unsure of how to hook things up from there. I would be happy to work with you to get it running. I feel that AIR is excellent as a debugging platform on PC for mobile development (since it offers full functionality that Flash omits) and would be useful for others in this capacity.
What would be entailed in adding or changing the build steps?
You could do an additional line that looks like this:
Try adding AIR to the PlatformTarget enum, and handle the case here by instantiating a new AIRPlatform class instance
In the AIRPlatform class, the extra logic would go in to do AIR builds instead of standard Flash builds. This class would then use the AIRHelper class we have – uncommented, a few tweaks might be needed, but otherwise, most of that logic would be available for building/running/testing, I believe.
I think we would also need templates/air/template/application.xml, or something like that, in the update step you would copy the “templates/air/template” folder
Happy to help if you have more questions, and we can help integrate if it starts working