[ALOY-659] Bad behavior when setting a platform specific 'controller' .JS with no platform specific associated .XML
GitHub Issue | n/a |
---|---|
Type | Bug |
Priority | Medium |
Status | Closed |
Resolution | Fixed |
Resolution Date | 2013-08-01T01:19:48.000+0000 |
Affected Version/s | Alloy 1.1.2, Alloy 1.1.1, Alloy 1.0.0 |
Fix Version/s | Alloy 1.3.0 |
Components | Runtime, Tooling |
Labels | n/a |
Reporter | Federico Casali |
Assignee | Tony Lukasavage |
Created | 2013-05-03T23:11:06.000+0000 |
Updated | 2013-10-11T23:14:26.000+0000 |
Description
Problem description
When setting a platform specific Controller .js file with no associated platform specific .xml , App does not run with bad error message. See sample attachedAttachments
File | Date | Size |
---|---|---|
ALOY-659_output.log | 2013-05-04T05:10:39.000+0000 | 19486 |
controller_iosFolder.zip | 2013-05-03T23:11:06.000+0000 | 1147 |
Screen Shot 2013-05-03 at 10.07.32 PM.png | 2013-05-04T05:10:39.000+0000 | 63155 |
[~fcasali] can you add the actual error and console output (debug level) to the ticket description?
Attaching output log and screenshot
PR: https://github.com/appcelerator/alloy/pull/201 test app: https://github.com/appcelerator/alloy/tree/master/test/apps/testing/ALOY-659 Run the app on all supported platforms. Make sure it compiles successfully. When the app runs, it should also open an alert dialog with the name of the current platform.
On 1.2.2-beta it's also buggy in the inverse case (which is more troubling) - when you have a platform specific view but a single controller. Tested this with your Navigation Window test app - just pulled win.js from the controllers/ios into controllers. Seems to work fine with latest 1.3.0 Alloy from Github. It would be great if these fixes can be merged into production Alloy ASAP (i.e. for 3.1.3), since it's *really* hard to maintain DRY code when we have to keep multiple JS files due to this bug. Thanks!
[~mokesmokes] It's unlikely that this will be put into 1.2.2 since that version is already in its release review process. I can see how far along we are, but no promises that this will be able to get into Alloy any quicker at the moment.
Thanks Tony. Then any practical suggestion for cases such as when the top view elements differ between Android (e.g. Window) and iOS (e.g. NavigationWindow)? Is Alloy 1.3.0 stable enough for use, or do we really need to double up on the controller code due to this bug (that would be quite painful to maintain), or do you have another practical suggestion? Thanks again.
BTW, regarding my previous comment: apparently 1.3.0 (coupled with 3.1.3RC) works fine on the iOS simulators (AFAICT), however misbehaves on actual iOS 6.1 devices. Have found this to be the case on both my app and your Navigation Window test app - HTH.
[~mokesmokes] This is a result of TIMOB-14884. The 1.3.0 branch will not work properly on ios devices until that ticket is resolved. At that point, when Alloy 1.3.0 is released, it will require TiSDK 3.2.0+.
Verified as fixed. Alloy 1.3.0 CLI 3.2.0 TiSDK 3.2.0.v20131010163242 Titanium Studio 3.1.4 Closing.
Federico - was this fixed for both cases? i.e. 2 JS files and one XML file, and 2 XML files and one JS file? Both didn't work. Thanks