View Full Version : Big PIcture Architecture

24 Aug 2011, 7:18 AM
I'm building a large Sencha Touch application (my companies first with this framework) and i have a big picture architecture question.

Our app will be very large, offering hundreds of views over time. The app will model the standard tablet UI metaphor where you have a list of menu items on the left and the detail screens are shown on the right.

My question relates to how best to architect these views to manage memory resources on the client. I don't want views (think panels showing on the right in the tablet UI) loaded up into memory when the app first loads on the client especially if those views are rarely displayed to the end user.

From the examples i've seen and from what i've gathered, it's best practice to extend all components like so:

app.views.businessSnapshotFormPanel = Ext.extend(Ext.form.FormPanel, {
... configuration code here

When a view needs to display this component we simply perform a

var myForm = new app.views.businessSnapshotFormPanel;

When not needed any more we destroy the component or the panel it lives in.

Does this sound about right? My concern is that any view that contains var myForm =, will automatically load into memory when the client app loads in the browser. Is there any way to "scope" an entire screens worth of components so that it doesn't load when the entire app loads?

Thanks in advance.

24 Aug 2011, 9:51 AM
You've basically got the idea.

Using your component events (activate, deactivate, etc.) is probably the best approach for creating/destroying components. You shouldn't have to worry about loading things into memory unless your code is poorly scoped.

For example, if you've got a form that contains a variety of input fields, don't create those input fields (or child containers, or whatever) until you know for sure you're going to need them. A good place to do this might be inside of your initComponent() method (assuming you're properly extending these classes). That way, these children are correctly destroyed as part of the component life cycle.

24 Aug 2011, 3:54 PM
John -

Assuming that hundreds of views is the appropriate solution ( it often isn't), you might want to consider reviewing the usage patterns of the system and see if you can identify sets of views that can be grouped into sub-apps within the app. If this is possible, you can then code those as separate apps, each satisfying a usage pattern. With this approach you don't force all potential users to download the definitions for views, controller, models, stores, etc. that they will never instantiate based on how they use the system.