: i think the targetbuild system could be used to simplify mobile development (and possibly other areas too).
let me explain. it's a lengthy post, but please stay with me:1) keeping a list of targetbuilds
we would switch between different platforms desktop/ios/android by setting the targetbuild in the ide. for that, we need a way to save not only the current targetbuild setting but to keep track of other targetbuild settings (the dropdown gets depopulated on project switch). those should probably live in the as3proj file.2) setting a compiler constant reflecting the selected targetbuild
for mobile dev and the different platforms one can make use of the "precompiler directives" like CONFIG::debug. as peter.vullings already pointed out in this thread
, we would treat the targetbuild setting the same way.
then we can disable certain portions of code for certain platforms by adding the CONFIG::[targetbuild] blocks. it's especially useful when working with ANEs which are platform-specific.3) make "precompiler directives" work for application.xml
we would introduce a xml parser that looks for <CONFIG::[constant]></CONFIG::[constant]> blocks and only keeps them if there is this constant defined (and set to true).
this way we can disable platform-specific ANEs on certain platforms when creating the air package.
(the way i do it right now is to copy my "main" application.xml to e.g. application-ios.xml, add the extensions there and pass it to adl via .bat)
adding a xml precompiler step may be easy when it comes to manual edits to the application.xml, on the other hand i don't expect new <CONFIG::>-tags to be easily digested by the "air app properties" gui :/4) rework the mobile template and RunApp.bat stuff
we would pass the targetbuild parameter to the RunApp.bat (or something similar) to always build a target-compatible version of the swf before packaging it with the target-compatible version of an application.xml via adl.
when we target "desktop" we would end up with a desktop-enabled air file that starts up and connects to the debugger just as it is right now.
targeting "ios" would install the ipa file to the device and starts a remote debugger session waiting for the app to be manually launched.
i've looked into all of those things and am willing to invest a bit of time into producing a forked branch of flashdevelop doing those things.
some further thoughts/questions in direction of devs and contributors:
for 1) and 2) i'm quite certain we have to change flashdevelop's sources as there is no feasible way to implement those things via the plugin architecture. please correct me if i'm wrong.
for 1) i have some clues where to start.
for 2) i modified the fdbuild source.
for 3) we could also put the xml parsing step into the RunApp.bat to not be all too invasive.
for 4) i'm certain there are some fd users and/or devs out there who already looked into this matter. anyone?