Thursday, July 19, 2012

Secnha Touch 2: Model-View-Controller Architecture [part 1]

Sencha Touch 2 is optimized around building applications that work across multiple platforms. To make the writing of applications as simple as possible, we provide a simple but powerful application architecture that leverages the MVC (Model View Controller) pattern. This approach keeps your code clean, testable and easy to maintain, and provides you with a number of benefits when it comes to writing your apps:

  • History Support: full back button support inside your app, and any part of your app can be linked to
  • Deep Linking: share deep links that open any screen in your app, just like linking to a web page
  • Device Profiles: easily customize your application's UI for phones, tablets and other devices while sharing all of the common code

An Application is a collection of Models, Views, Controllers, Stores and Profiles, plus some additional metadata specifying things like application icons and launch screen images.

  • Models: represent a type of object in your app - for example an e-commerce app might have models for Users, Products and Orders
  • Views: are responsible for displaying data to your users and leverage the built in Components in Sencha Touch
  • Controllers: handle interaction with your application, listening for user taps and swipes and taking action accordingly
  • Stores: are responsible for loading data into your app and power Components like Lists and DataViews
  • Profiles: enable you to easily customize your app's UI for tablets and phones while sharing as much code as possible
The Application is usually the first thing you define in a Sencha Touch application, and looks something like this:

    name: 'MyApp',
    models: ['User', 'Product', 'nested.Order'],
    views: ['OrderList', 'OrderDetail', 'Main'],
    controllers: ['Orders'],

    launch: function() {

The name is used to create a single global namespace for your entire application, including all of its models, views, controllers and other classes. For example, an app called MyApp should have its constituent classes follow the pattern MyApp.model.UserMyApp.controller.UsersMyApp.view.Main etc. This keeps your entire app under a single global variable so minimizes the chance of other code on the page conflicting with it.
The Application uses the defined modelsviews and controllers configurations to automatically load those classes into your app. These follow a simple file structure convention - models are expected to be in the app/model directory, controllers in the app/controller directory and views inside the app/view directory - for example app/model/User.jsapp/controllers/Orders.js and app/view/Main.js.
Note that one of the models we specified was different to the others - we specified the full class name ("MyApp.model.nested.Order"). We're able to specify the full class name for any of those configurations if we don't follow the normal naming conventions. See the Dependencies section of the docs for full details on how to specify custom dependencies.

No comments:

Post a Comment