Titanium

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

GitHub Issuen/a
TypeBug
PriorityMedium
StatusClosed
ResolutionWon't Fix
Resolution Date2013-10-18T18:01:50.000+0000
Affected Version/sn/a
Fix Version/sn/a
ComponentsTooling
Labelsalloy, compiler, platform
ReporterMauro Parra-Miranda
AssigneeTony Lukasavage
Created2013-10-17T13:55:11.000+0000
Updated2014-06-22T13:23:13.000+0000

Description

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.

Comments

  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