Code works in desktop Safari, dies on iOS Safari.

[subimage]

I'm working on a new Sencha 2 app, which is going OK on my desktop. It's a basic nav panel on the left, details on the right kind of app at the moment.

When using Safari on the desktop, it works fine. I can click on items in my list on the left, and they appear on the right.

However, when viewed on the iOS simulator, or on a real iOS device (iPad, iPhone), there appears to be an error happening at line 119, which halts showing of my card that's being loaded.

The code in question can be found here http://pastie.org/2704066 (again - line 119 is the issue). I can prove this because I'm using Firebug Light in the iOS simulator, and I see the console.log above that line, but not the one below it.

I also tried using something like

card = eval('this.'+getter+'());

which again works on the desktop, but fails on iOS.

Is this a loader issue of some sort, or is there something else going on here? I'm working from the Kitchensink source, and I see there's a similar call used there - which works.

Any help would be appreciated. I've been banging my head against this one for about 2 hours now with absolutely no progress. Maddening!

[Jamie Avins]

It's possible you just need to define the card variable (it isn't defined). You can also get rid of mainLayout and animationRecord definitions since you aren't using them.

[subimage]

It's possible you just need to define the card variable (it isn't defined).

This is incorrect. You don't have to explicitly instantiate a variable in JS. However, even adding a var card; to the top of the method doesn't do a thing.

[Jamie Avins]

What is your console log showing for getter?

[subimage]

What is your console log showing for getter?

On iOS mobile the second console.log line doesn't even print. It's like it's throwing an error then not saying anything.

I'm going to try and instantiate the views explicitly when I get into the office and see if that changes things. I'm guessing the Kitchen Sink demo inits them dynamically for memory consumption, correct?

Is doing things that way a recommended pattern to save on memory or do you think it's overkill?

[Jamie Avins]

It won't until the getter is called for the view. It's for performance more than memory.

[subimage]

Here's a new paste with some updated console log statements.

http://pastie.org/2715419

It's definitely dying on the "getter" on line 120 on iOS. Same result on an actual iPad.

I've attached screenshots of the iOS firebug light console output, along side the same thing from Safari's debug console.

It looks like this is an iOS bug? Is there any other way to instantiate a view programmatically? This is really killing my development time.

bug_ios_emulator.jpgbug_safari.jpg

[subimage]

Perhaps the title of this thread is throwing people off - but I suppose my main issue is this...

Assuming the following...

* I have a "main" controller that loads a basic view framework, with a menu and content panel
* I have a MVC application setup, with one controller and view for each "section" in my app
** These items aren't "created" at startup

...how do I instantiate and grab a handle to these views to show them?

[subimage]

Just for fun, I tested it on Mac Chrome. Here it's not working, just like iOS, yet it throws a helpful error.

Screen shot 2011-10-18 at 5.04.30 PM.jpg

If anyone cares to look, I've uploaded the full source for the app here:

http://dl.dropbox.com/u/156966/subimage_sencha_app.zip

[subimage]

Answered my own question I suppose. Turns out that my use of "callParent" in Safari was fine, yet was throwing errors in Chrome.

I am subclassing my views to re-use some code, and what I was doing wasn't working. Using callParent(arguments) in my constructor seems to have fixed things!