Titanium

[ALOY-1249] iOS: Misleading error message when controller file not found

GitHub Issuen/a
TypeBug
PriorityHigh
StatusClosed
ResolutionWon't Fix
Resolution Date2015-11-10T20:27:38.000+0000
Affected Version/sAlloy 1.5.1
Fix Version/sn/a
ComponentsRuntime
Labelsn/a
ReporterShannon Hicks
AssigneeFeon Sua Xin Miao
Created2015-02-18T15:59:35.000+0000
Updated2015-11-10T20:27:38.000+0000

Description

When Alloy can't find a controller on iOS, it gives a message saying that a module (controllerName) for architecture (arm7/arm64) can't be found. very confusing, becuase it sounds like there's a native module problem. 
Alloy.createController('foo');

Attachments

FileDateSize
Screenshot 2015-02-18 09.54.58.png2015-02-18T15:59:35.000+000019256

Comments

  1. Tim Poulsen 2015-02-18 I can confirm this behavior. We need to add a file-exists check to Alloy.createController(). As it stands, if the file is not found, it would appear the underlying code wrongly assumes we're requiring in a native module.
  2. Tim Poulsen 2015-02-19 This appears to be caused by the linked ticket: TIMOB-18196
  3. Tim Poulsen 2015-02-20 PR https://github.com/appcelerator/alloy/pull/667 Functional test 1. Use the included test app. It attempts to load a controller file that doesn't exist (named doesNotExist). 2. Build the app for iOS. You'll get a red-screen error, but with a more meaningful "Cannot find controller: doesNotExist" 3. Build the app for Android, it will also fail as expected but with the message "Requested module not found: alloy/controllers/doesNotExist"
  4. Paco Castilla 2015-02-24 Sometimes when compiling to Xcode renames the controller (Detail -> detail) and has given me is you mistake !!
  5. Feon Sua Xin Miao 2015-07-27 Instead of handling this at run time, I think Alloy should throw an error at compile time to let the developer know that there's no such controller file.
  6. Feon Sua Xin Miao 2015-07-27 PR: https://github.com/appcelerator/alloy/pull/712 Functional test 1. Use the included test app. It attempts to load a controller file that doesn't exist (named doesNotExist). 2. Build the app. Compilation should stop and you should see an error output as follow: 
       [INFO]   controller: "index.js"
   [ERROR] Cannot find controller: "doesNotExist"
  7. Fokke Zandbergen 2015-11-05 See the comments by [~skypanther] and me on the PR. A compile time check would fail when the controller name is composed dynamically. It needs to be a run-time check. But maybe we should take this issue to TIMOB since it's not just an Alloy issue. The architecture is also confusing if you do a require() for some CommonJS module you expect to be there but isn't. But of course the hard thing there is that Titanium can't know if the user meant to require a native or CommonJS module. Going back to why we added the architecture I think the reason was because of the 64-bit thing. A native module might be there but not 64-bit. Now THIS is something we could check on (Titanium) compile time and if we do so we don't need to mention the architecture in the error anymore. Another way could be that if Titanium finds a non-64-bit module but it needs 64-bit then it would only then add that the module is not available in the required architecture. In the end handling that better in require() would be better then just resolving this ticket, which would then become invalid anyway.
  8. Tim Poulsen 2015-11-05 This is / was caused by a TIMOB change (yes, for the 64-bit change). See my comment above. I proposed a different solution at the time, but was outvoted by the approach that was taken in the SDK. You're right, the fix should be in the SDK. There are bigger issues in SDK-land. So, Alloy just needs to compensate and move on.
  9. Fokke Zandbergen 2015-11-05 Created TIMOB-19881

JSON Source