Adobe air mobile target feedback


#1

Hi,
so I am in progress of porting my as3 mobile game to haxe, for start made a hybrid one, still exporting to adobe air but wrote all game code in haxe already. During that found some parts that we should improve there:

  • Splash screens are not supported yet (or I didn’t find them). In air mobile for iOS splash screens need to be copied in root with specific names. As side effect missing splash screens are causing size issues as fullscreen is blocked on bigger devices. (I patched lime a bit based on icons implementation and using splashScreen from project.xml for now).

  • In order to debug mobile air apps with fdb param -connect (for wifi debug) or -listen (for usb) is needed for ipa/apk creation. Made trivial patch to AIRHelper but the hardest part is to decide how to pass it from project.xml as just debug cannot be used there, because of 2 debug ways (personally haven’t used USB one).

  • supportedLanguages could be supported to remove unnecessary languages from ipa, but that could be achieved with a custom template, so just nice to have.


#2

You’re right, looking at https://github.com/openfl/lime/blob/develop/lime/tools/platforms/AIRPlatform.hx I don’t see handling for splashScreens, so any help there (pull request?) would be incredibly helpful :slight_smile:

If you use -connect do you need an IP address, or other information for connecting over WiFi? Our Android target currently defaults to connecting over USB, unless the user passes -device=192.168.0.100 or whatever the IP address of the device will be. Perhaps we could adopt something similar? (There’s code handling this in AndroidPlatform).

If there’s no other parallel, we could add support for <config:air supported-languages="" /> or something similar


#3

@singmajesty

supported languages can be used on native platforms as well. created WIP PR

will try to create one for splash screens as well.

regarding -connect it can be used with or without IP address, depends on wi-fi settings. (not sure about -listen as have used only once but I can check docs)

This weekend needed to rush out version of my app so published still as3 air version and found out another issue, from now Assets.car is needed for air apps as well, so official docs suggest to create an empty project in Xcode and than copy one from there, (maybe could be done in command line, but that means no builds on WIN).

Will add more stuff here as I go.


#4

Okay, thank you, it’s appreciated :slight_smile:


#5

Added initial support for some air platform missing features. Looks like not the best moment as the project is refactored :smiley:
Splash screen:


Wifi debug connect (device on iOS is used to decide if that’s universal app or not so added in air config):

Custom simulator:

Feedback, suggestions are welcome, also would appreciate some testing help.

Also, wondering how many people are still interested in adobe air platform as there are still some features missing for packaging and debugging :slight_smile:


#6

Thank you so much for your help! I’ll try and see if I can integrate this in with the recent Lime changes :slight_smile:


#7

@singmajesty can I help somehow with refactoring PR to new project structure? or its better to wait till new structure will be released?


#8

Hey @Hersir

Thanks again for your work. Things have settled down enough now that I know where things are going. In the development version of Lime, the previous Lime tool sources have moved (with minor renames) to https://github.com/openfl/hxp, but the tools are being compiled into the Lime project as before. A refactor will come in the future to make the tools standalone as a separate project, but for now, it should be possible to apply your changes to the HXP project and compile it with the development version of Lime.

AIR improvements have been a part of the recent Lime development work, we’ve primed things to provide shims for the Haxe sys APIs on the AIR platform, fixes to the AIR externs and improvements to how AIR windowing is handled by Lime.

It’s harder for me to scan how the XCodeHelper refactor compares to the previous IOSHelper structure, but in general it looks like your changes are good and are something I can merge right in. I’ll try and do this manually or you can do the pull requests against the HXP project and I’ll merge. Thanks again!