Symantics

[grantges]

Hey Rick, couple of things.

I like the modified structure, and how your implementing the examples. A couple of points of feedback:

Core.js

• Recommend adding the openScreen method to the Navigator object as a default method for opening controllers - this removes a dependancy at the most basic level. Your "Simple" project example shows how to abstract this to a very simple lib file (navigation.js), but think that core should have this basic ability by default. More complex examples (ViewNavigation for example) appropriately show how to override the Navigator object in core to create custom navigation paradigms.
• We should try and stick to similar naming conventions - openScreen vs open are both referenced in the example apps- for clarity lets just use "open"?

ViewNavigationExample => Navigation Object (lib/navigation.js)

• Setting "this" to "that" - i understand why your doing this, but I find this to be confusing to those that don't have a pretty fairly deep knowledge of javascript, in particular variable scope etc. recommendation is to change this variable name to "_navigation" with a commment about referencing the instance of the object from within internal functions etc.

General Repository Structure
As the repository now stands, I can not simply do an import of the project into Studio and run it - would recommend altering the structure to make that a cleaner process.

[rblalock]

I just renamed the simple examples navigation module to "open" instead of "openScreen" since the other example doesn't have "openScreen".

Someone can still have App.open or App.openScreen if they want to do that. It looks simpler for someone just learning about app development and all that. So you think the "simple" example should be like any other examples and it should have openScreen in core.js vs. it's own navigation file?

Regarding var that = this; - this is pretty standard practice. I think naming it var _navigation = this; is more of a shift from the standard. It should probably have a comment though indicating why this is, which is a good point.

For importing: You should be able to download the repo and import the demo_app no problem. The reason I'm keeping them separate from the root is if you want to use just the core.js file and some of the helpers in a new project, you can just download them and be off to the races without worrying about the examples. As these examples get more fleshed out, the core.js singleton will be slightly different depending on the example all so I don't want someone downloading a core.js that is only for an example if they're just wanting a vanilla version of it.