Titanium

[ALOY-659] Bad behavior when setting a platform specific 'controller' .JS with no platform specific associated .XML

GitHub Issuen/a
TypeBug
PriorityMedium
StatusClosed
ResolutionFixed
Resolution Date2013-08-01T01:19:48.000+0000
Affected Version/sAlloy 1.1.2, Alloy 1.1.1, Alloy 1.0.0
Fix Version/sAlloy 1.3.0
ComponentsRuntime, Tooling
Labelsn/a
ReporterFederico Casali
AssigneeTony Lukasavage
Created2013-05-03T23:11:06.000+0000
Updated2013-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 attached

Attachments

FileDateSize
ALOY-659_output.log2013-05-04T05:10:39.000+000019486
controller_iosFolder.zip2013-05-03T23:11:06.000+00001147
Screen Shot 2013-05-03 at 10.07.32 PM.png2013-05-04T05:10:39.000+000063155

Comments

  1. Tony Lukasavage 2013-05-04 [~fcasali] can you add the actual error and console output (debug level) to the ticket description?
  2. Federico Casali 2013-05-04 Attaching output log and screenshot
  3. Tony Lukasavage 2013-08-01 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.
  4. Mark Mokryn 2013-09-15 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!
  5. Tony Lukasavage 2013-09-15 [~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.
  6. Mark Mokryn 2013-09-15 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.
  7. Mark Mokryn 2013-09-15 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.
  8. Tony Lukasavage 2013-09-15 [~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+.
  9. Federico Casali 2013-10-11 Verified as fixed. Alloy 1.3.0 CLI 3.2.0 TiSDK 3.2.0.v20131010163242 Titanium Studio 3.1.4 Closing.
  10. Mark Mokryn 2013-10-11 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

JSON Source