[ALOY-1249] iOS: Misleading error message when controller file not found
| GitHub Issue | n/a |
|---|---|
| Type | Bug |
| Priority | High |
| Status | Closed |
| Resolution | Won't Fix |
| Resolution Date | 2015-11-10T20:27:38.000+0000 |
| Affected Version/s | Alloy 1.5.1 |
| Fix Version/s | n/a |
| Components | Runtime |
| Labels | n/a |
| Reporter | Shannon Hicks |
| Assignee | Feon Sua Xin Miao |
| Created | 2015-02-18T15:59:35.000+0000 |
| Updated | 2015-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
| File | Date | Size |
|---|---|---|
| Screenshot 2015-02-18 09.54.58.png | 2015-02-18T15:59:35.000+0000 | 19256 |
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.
This appears to be caused by the linked ticket: TIMOB-18196
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"
Sometimes when compiling to Xcode renames the controller (Detail -> detail) and has given me is you mistake !!
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.
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:
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.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.
Created TIMOB-19881