View unanswered posts | View active topics

Reply to topic  [ 2 posts ] 
proposal to use TargetBuild to ease mobile dev 
Author Message

Joined: Thu Apr 26, 2007 7:04 pm
Posts: 94
tl;dr: 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? :)


Thu Oct 13, 2016 8:32 am

Joined: Wed Aug 31, 2005 7:27 am
Posts: 12172
Location: London
Some good ideas here - you should create a Github issue to discuss it and break it down in feasible chunks.

Wed Dec 21, 2016 3:57 pm
Profile WWW
Display posts from previous:  Sort by  
Reply to topic   [ 2 posts ] 

Who is online

Users browsing this forum: No registered users and 1 guest

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum

Search for:
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group.
Designed by ST Software for PTF.