Hi,
Is File APIs implemented for OpenFL3? I can only see legacy support implementations in the source code.
Ideally I’d like to access: File.applicationStorageDirectory, File.applicationDirectory, etc and be able to resolve path as the AS3 APIs allowed.
Any help would be greatly appreciated.
Thanks,
Matan
So the CPP target is implemented via lime.system.Sytem, but I actually need the AIR target support as well. Due to lack of time and cross-platform video support.
As you can see below, I get null for AIR.
If anyone is interested, I’ve created an extern than handles all the AIR flash APIs. I’ll create a git repo on request.
When you commonly build for AIR, is a define enabled, or is it a plain Flash target?
I’m trying to think of something that would work in AIR, but not cause problems in regular Flash Player. Maybe something with reflection?
So for now I treat flash build the same as an air build, I do however define an ‘air’ compiler flag as well. I think having the extern works pretty well. We should look at adding it into the System class under to provide the top level directories one commonly needs. Once you have the native path, it’s easy to the standard haxe pathing techniques to get where you want to go.
Unfortunately you would need to use reflection to see whether the ‘flash.filesystem.File’ class is present in the application domain. However, I think it’s safe to assume that developers generally understand when a local file system is available and when it isn’t. I’ll be happy without the check to save on overhead. Devs trying to reference the file system on an unsupported target will simply get an error and (hopefully) understand why.
Would you like to me to post the extern?
Here’s an idea –
In the Flash backend code (FlashApplication, for example) we perform a check in order to determine if we are running in AIR. Then subsequent code can check this boolean in order to return null or a real value for APIs in Lime like this. Another idea would be to use Reflection within the call itself, but it could run slower that way
BTW, regarding AIR
At one time, the tools had built-in AIR support. I believe you would use openfl test ios -air, or something like that, in order to enable it.
I’ve received feedback that this was confusing – that it’s easier to think OpenFL and AIR as two separate things, and I was concerned about the support stagnating and getting broken with some further release of AIR, and causing maintenance headaches.
However, if this is something you’re interested in and would really help your workflow, this could be revisited 
Yes, doing the single check when the backend starts up sounds like an idea. I’ve dug up some old AS:
var playerType : String = Capabilities.playerType;
var os : String = Capabilities.os.toLowerCase();
var version : String = Capabilities.version.slice(0, 3)
_isAir = (playerType == "Desktop");
_isFlashPlayer = (playerType == "StandAlone");
_isBrowser = (playerType == "ActiveX" || playerType == "PlugIn");
_isOther = (playerType == "External");
_isMac = os.indexOf("mac") != -1;
_isWin = os.indexOf("windows") != -1;
_isLin = os.indexOf("linux") != -1;
_isIos = version == "ios";
_isAndroid = version == "and";
_isMobile = (_isIos || _isAndroid);
Although, that’s super gross. I’d rather use:
var isAIR : Bool = ApplicationDomain.currentDomain.hasDefinition("flash.filesystem.File");
Regarding the air flag, not sure, I’m trying with all my might to get away from using flash. Unfortunately with this case yet again I need to use it. I’ve written a bash script which is pretty comprehensive to compile everything I need. The project I’m working at the moment is a complex html5 website which the client wants as an app as well. I’ve done this before with Flash, but much rather prefer writing complex websites in HaXe/OpenFL. So to keep things cheap I need to get to a solution in the quickest possible way.
My bash script supports:
After all these various attempts at getting the best outcome, AIR remained the quickest way. Unfortunately.
Problems AIR solve as of now:
Sorry for the life story! 
I’d love to see better AIR support in Lime, where appropriate. I think it’s a simple place for us to add the abstraction. Inline reflection (like if (ApplicationDomain.currentDomain.hasDefinition("flash.filesystem.File")) { // do AIR stuff } is a quick fix that should help. One way or another, I’d be happy to see it
That’s helpful to see a list, I’d like to see those supported in the future as well
Agreed. It’s almost midnight for me. I’ll try and push upstream on lime tomorrow once I’ve done some proper testing with the extern and AIR detection.
Thanks for the chat. I’ll post on this thread once I’ve got my merge ready.
Cheers!
Allrighty, I’m back! Please let me know what you think of this solution before I create the pull request.
Looks pretty good
I think (perhaps?) the detection should happen within the _backend/flash somewhere, probably _backend/flash/FlashApplication.hx
it could be a static value that System could check. This way it stays internal to the backend and doesn’t touch the config object
The check is happening in the FlashBackend class. 
The System class was already using the config class to access other stuff, so I deemed it ok to use for the isAir boolean.
Great! It should be in now, I decided to do Capabilities.playerType == "Desktop", I think this should probably perform just as well, and we don’t have to add an additional check.