PSvils
Feb 13, 2014, 3:39:50 AM2/13/14
to haxe...@googlegroups.com
And funnily enough, not working is the best way I can put it.
Using FlashDevelop, I build my application with OpenFL to the .swf target.
Then I package that swf using AIR for iOS. I've tested on 2 devices, and as soon as the target is something more than the interpreter packages, the application seems to just spin on the launch screen (by default a big AIR logo).
On Android everything works fine!
The iOS targets are as follows:
ios-test-interpreter
ios-debug-interpreter
ios-test
ios-debug
ios-ad-hoc
ios-app-store
The first 2 work, since they basically pack the AIR runtime and my swf (afaik). The rest, AIR tries to compile my application into a native application, which is also my only option if I'm going to be distributing my application.
Has anyone else experienced issues with an OpenFL to AIR/iOS pipeline?
I'd also like to know how OpenFL packs its assets, since I was able to create a plain haxe/Flash project, include and load an image through haxe.Resource API, and it worked on my iOS devices.
This is really frustrating, since I'm not sure where I can even begin to debug things. I did some raw debugging through the Console in XCode, and I can see that there are several threads spawned, that simply don't do anything, and several of them have something related to image loading in them.
If anyone has any comments whatsoever on any of my questions, or any suggestions, please comment! I've been fighting with this for a while.
P.
ps: I have been exploring the option of using OpenFL's own ios/android targets, but right now, this causes too many issues, since I use the air3 library.
Using FlashDevelop, I build my application with OpenFL to the .swf target.
Then I package that swf using AIR for iOS. I've tested on 2 devices, and as soon as the target is something more than the interpreter packages, the application seems to just spin on the launch screen (by default a big AIR logo).
On Android everything works fine!
The iOS targets are as follows:
ios-test-interpreter
ios-debug-interpreter
ios-test
ios-debug
ios-ad-hoc
ios-app-store
The first 2 work, since they basically pack the AIR runtime and my swf (afaik). The rest, AIR tries to compile my application into a native application, which is also my only option if I'm going to be distributing my application.
Has anyone else experienced issues with an OpenFL to AIR/iOS pipeline?
I'd also like to know how OpenFL packs its assets, since I was able to create a plain haxe/Flash project, include and load an image through haxe.Resource API, and it worked on my iOS devices.
This is really frustrating, since I'm not sure where I can even begin to debug things. I did some raw debugging through the Console in XCode, and I can see that there are several threads spawned, that simply don't do anything, and several of them have something related to image loading in them.
If anyone has any comments whatsoever on any of my questions, or any suggestions, please comment! I've been fighting with this for a while.
P.
ps: I have been exploring the option of using OpenFL's own ios/android targets, but right now, this causes too many issues, since I use the air3 library.
Saar Korren
Feb 13, 2014, 6:46:27 AM2/13/14
to haxe...@googlegroups.com
It might be worth taking the extra investment to remove any dependencies on AIR. It's not exactly a good platform, especially for mobile. It might be difficult with your current codebase, but it's worth investing that effort as early as possible, especially if you're planning on a native store distribution, rather than being forced to do it later when your codebase is potentially much bigger.
Shohei qoq
Feb 6, 2015, 11:30:50 AM2/6/15
to haxe...@googlegroups.com
I experienced same behavior. Invalid appliction.xml for AIR causes it.
You shloud not use subdirectory at <content> element in <initialWindow>.
Bad :
<content>bin/Main.swf</content><content>Main.swf</content>Reply all
Reply to author
Forward
0 new messages