[ALOY-850] Alloy: Automatically remove constants for platforms not targeted on compile
GitHub Issue | n/a |
---|---|
Type | Bug |
Priority | Medium |
Status | Closed |
Resolution | Won't Fix |
Resolution Date | 2013-10-18T18:01:50.000+0000 |
Affected Version/s | n/a |
Fix Version/s | n/a |
Components | Tooling |
Labels | alloy, compiler, platform |
Reporter | Mauro Parra-Miranda |
Assignee | Tony Lukasavage |
Created | 2013-10-17T13:55:11.000+0000 |
Updated | 2014-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 withnull
(or undefined
?) when that specific platform is not targeted.
I don't see a reason to do this, particularly when it will increase compile time, when the device query is already readily available.
@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.
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?
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.