"Undefined symbols for architecture armv7" during device testing..

[tzmartin]

Works great for simulator tests, but I'm having an issue with device testing. Seems the class files are undefined, which throws an error during app build. Can you test on your end?

[TRACE] :  Undefined symbols for architecture armv7:
[TRACE] :    "_OBJC_CLASS_$_TiUIWebView", referenced from:
[TRACE] :        l_OBJC_$_CATEGORY_TiUIWebView_$_TiUIWebView_Extend in libdk.napp.ui.a(TiUIWebView+Extend.o)
[TRACE] :    "_OBJC_CLASS_$_TiUITabGroup", referenced from:
[TRACE] :        l_OBJC_$_CATEGORY_TiUITabGroup_$_TiUITabGroup_Extend in libdk.napp.ui.a(TiUITabGroup+Extend.o)
[TRACE] :    "_OBJC_CLASS_$_TiUISearchBar", referenced from:
[TRACE] :        l_OBJC_$_CATEGORY_TiUISearchBar_$_Extended in libdk.napp.ui.a(TiUISearchBar+Extended.o)
[TRACE] :    "_OBJC_CLASS_$_TiUIiOSToolbarProxy", referenced from:
[TRACE] :        l_OBJC_$_CATEGORY_TiUIiOSToolbarProxy_$_Extended in libdk.napp.ui.a(TiUIiOSToolbarProxy+Extended.o)
[TRACE] :  ld: symbol(s) not found for architecture armv7
[TRACE] :  clang: error: linker command failed with exit code 1 (use -v to see invocation)

Env:

• OS X 10.8.4
• Xcode 4.6.3
• Ti 3.1.1.GA

[viezel]

have a look here: https://github.com/viezel/NappUI/issues/2

[viezel]

the quick answer: remember to do this: https://github.com/viezel/NappUI#how-to-use

[tzmartin]

Ah yes. That works. Btw, I had a the same issue with a module I wrote for a vertical ScrollableView class which overrides several methods, etc. Your symbol pre-loader technique fixed it as well.

So this is one for the books.. this symbol pre-loader technique is needed if you write any module that needs to override delegate instance methods.

For example:

– webView:shouldStartLoadWithRequest:navigationType:
– webViewDidStartLoad:
– webViewDidFinishLoad:
– webView:didFailLoadWithError:

Thanks for sharing your brain.

[tzmartin]

Quick note about the preload technique. There's a slightly easier way to define the symbols without requiring users to require() dependencies.

• Add a dk.napp.ui.js file to your module assets directory that contains the following:

Ti.UI.createWindow();
Ti.UI.createTab();
Ti.UI.createTabGroup();
Ti.UI.createWindow();
Ti.UI.iPhone.createNavigationGroup();
Ti.UI.createTextField();
Ti.UI.createWebView();
Ti.UI.createSearchBar();
Ti.UI.createScrollableView();
Ti.UI.createPicker();
Ti.UI.iOS.createToolbar();

This will instantiate the symbols without requiring users to embed commonJS or JS object references.

• Or, if you don't use the module assets technique, have the user simply drop in a preloader.js file into the app/assets/ or Resources/ folder that contains the above mentioned code. No other action is needed.

The key here is Titanium statically analyzes the JS files to determine which symbols are needed before the JS interpreter is invoked. So all you need to do is reference the appropriate Ti.UI class, which marks it for inclusion during the compile process.

I tested for device builds using both techniques.

Thoughts?

[viezel]

Hi Terry. Thanks for picking my brain :) Yep, you got it. The static analysis is why the UI proxy calls are needed. Great idea about using the assets folder. Why didn't I think of that :) much more slick way, so the developer does not need to know HOW the Ti SDK works.

Please do a PR if you don't mind.

Again, great people are using this, and you have have any additional extended API, please submit them.