Titanium JIRA Archive
Alloy (ALOY)

[ALOY-850] Alloy: Automatically remove constants for platforms not targeted on compile

GitHub Issuen/a
ResolutionWon't Fix
Resolution Date2013-10-18T18:01:50.000+0000
Affected Version/sn/a
Fix Version/sn/a
Labelsalloy, compiler, platform
ReporterMauro Parra-Miranda
AssigneeTony Lukasavage


I'm all for using [platform=ios] and so, but I wonder if the Alloy compiler could take away the need to do that for the very simple and very common case where in TSS, but also in JS/XML you would use platform specific constants that don't exist if you don't build for that platform.

Example code

1. Create a new project: titanium create -p android,ios -n ns --id ti.ns -d . 2. Initialize Alloy: cd ns && alloy new 3. Replace the contents of index.tss with:
    ".container": {
        statusBarStyle: Titanium.UI.iPhone.statusBarStyle.LIGHT_CONTENT
4. Build for Android: titanium build -p android -T device 5. The app will crash with:
    10-17 15:39:40.420: E/TiExceptionHandler(12559): (main) [152,152] ----- Titanium Javascript Runtime Error -----
    10-17 15:39:40.425: E/TiExceptionHandler(12559): (main) [0,152] - In alloy/controllers/index.js:15,58
    10-17 15:39:40.425: E/TiExceptionHandler(12559): (main) [1,153] - Message: Uncaught TypeError: Cannot read property 'LIGHT_CONTENT' of undefined
    10-17 15:39:40.425: E/TiExceptionHandler(12559): (main) [0,153] - Source:         statusBarStyle: Titanium.UI.iPhone.statusBarStyle.LIGHT_CONTENT,
    10-17 15:39:40.450: W/ResourceType(12559): Failure getting entry for 0x010802c0 (t=7 e=704) in package 0 (error -75)
    10-17 15:39:40.455: E/V8Exception(12559): Exception occurred at alloy/controllers/index.js:15: Uncaught TypeError: Cannot read property 'LIGHT_CONTENT' of undefined

Possible solutions

The TSS/XML/JS parsers could check for references to these platform specific constants and then just replace them with null (or undefined?) when that specific platform is not targeted.


  1. Tony Lukasavage 2013-10-18

    I don't see a reason to do this, particularly when it will increase compile time, when the device query is already readily available.
  2. Malcolm Hollingsworth 2013-10-19

    @Tony - this is a very annoying issue that I have come across myself more than once even though I take care in the code I am creating. Whilst it will increase the time to compile - that time must surely be measured in the milliseconds in total. By forcing a code based exception surely there is more code to check against for the compiler - so I would imagine one would cancel the other out. At the most basic level this could be nothing more than "if constant includes ios/iphone/ipad ignore for others" and so on. I would greatly value this clean-up method being automatic, Alloy is not meant to do our work for us, but it should be able to handle something I find such an obvious feature requirement. I vote this is re-opened.
  3. Stephen Feather 2013-10-19

    What is the true time increase on compile? What is the cost to implement? What is the cost savings across 1 developer? What is the cost savings across all developers?
  4. Fokke Zandbergen 2013-10-19

    From your standpoint and role to keep Alloy lean and mean I understand you don't like to add this Tony. However, from a developer stand point this is just another way in which Alloy saves us time and code to write. So I hope you can take a more pragmatic standpoint and allow me to do a PR including test and benchmark.

JSON Source