Albert Einstein once remarked, "The only reason for time is so that everything doesn't happen at once". While this might seem like an offhand comment, it actually has a great deal of relevance when it comes to writing code.

As we write our code in Sencha Touch, we are directing the web browser to create and destroy components on the user's screen. The obvious limitation of this process is that we cannot manipulate a component before it gets created, nor after it's destroyed.

This seems pretty straightforward at first glance. You would never write a line of code that tries to talk to a component on the line before you actually create the component, so what's the problem?

The problem has to do with asynchronous actions within the code. While most of our code will execute sequentially or in a synchronous fashion, there are a number of cases where we will need to send out a request and get back a response before we can proceed. This is especially true in web-based applications.

For example, let's say we have a line of code that builds a map using a request from Google Maps. We will need to wait until we have received a response from Google and rendered our map before we can begin fiddling about with it. However, we don't want the rest of our application to freeze while we wait on the response. So, we make an asynchronous request, one that happens in the background, while the rest of our application goes about its business.

These asynchronous requests are called AJAX requests. AJAX stands for Asynchronous JavaScript and XML. If we configure one of our buttons to send out an AJAX request, the user can still do other things while the application is waiting for a response.

On the interface side of things, you will probably want to let the user know that we made the request and are currently waiting for a response. In most cases, this means displaying a "loading" message or animated graphic.

Using events in Sencha Touch, we can show the loading graphic by tying into the beforerequest event in the AJAX component. Since we need to know when to make the loading message disappear, our component will wait for the requestcomplete event from our AJAX request. Once that event fires, we can execute some code to tell the loading message to go away. We can also use the requestexception event to inform the user whether errors occurred during the request.

Using this type of event-driven design allows you to respond quickly to the user's actions, without making them wait for some of the more time-consuming requests your code needs to perform. You can also use the events to inform the user of errors. The key to events is getting your other components to "listen" for the event, and then telling them how to handle the information they receive.

Listeners can also be added to a component dynamically. If we were to add a new listener to our previous example, it would look something as the following:

var cmp = Ext.getCmp('tapTarget'),
cmp.on('resize',
function() {
var h = this.getHeight();
var w = this.getWidth();
this.update('height: '+h+'<br>width: '+w)
}, cmp);

This code will get the height and width of the container. It will then use the update method to add the height an d width as text to the container, when the resize event fires.

However, there is one slight problem with this approach: the resize event only fires when a container is manually resized by dragging the lower-left corner of a manually-resizable container. Since ours is changed programmatically, the resize event is never fired.

We can fix this by manually firing the event in our previous code using the fireEvent() method:

listeners: {
  tap: {
    element: 'body',
    fn: function(event, div, listener) {
      var cmp = Ext.getCmp('tapTarget'),
      cmp.setWidth(event.xy[0]);
      cmp.setHeight(event.xy[1]);
      console.log(event.xy);
      cmp.fireEvent('resize'),
    }
  }
}

The fireEvent() method can be used with both existing events as well as your own custom events.

While Sencha Touch components respond to a large number of events, it can sometimes be helpful to fire custom events within your application.

For example, you could fire a custom event called vikinginvasion, using the same type of syntax as our previous example:

cmp.fireEvent('vikinginvasion'),

You can then add a listener in your code for vikinginvasion, along with a function to handle the event:

var cmp = Ext.getCmp('tapTarget'),
 cmp.on('vikinginvasion',
 function() {
alert("Man The gates!");
 }, this);

You can also check a component to see if it has a specific listener, using the hasListener() method:

var cmp = Ext.getCmp('tapTarget'),
if(cmp.hasListener('vikinginvasion') {
  console.log('Component is alert for invasion'),
} else {
  console.log('Component is asleep at its post'),
}

There are also a number of helpful options you can use to contrl how the listeners will check for events.

For the most part, listeners can simply be configured with the event name, handler, and scope, but sometimes you need a bit more control. Sencha Touch provides a number of helpful options to modify how the listener works:

Using the different listener options would look something like the following:

var cmp = Ext.getCmp('tapTarget'),
cmp.on('vikinginvasion', this.handleInvasion, this, {
single: true,
delay: 100
});

This example would add a listener for vikinginvasion and execute a function called this.handleInvasion. The handler would only execute once, after a 100-millisecond delay. It would then remove itself from the component.

This basic list of configuration options gives you quite a bit of flexibility when adding listeners. However, there is one additional configuration option available in listeners that will require a bit more explanation. It's called scope.

Within your handler function is a special variable called this. Usually, this refers to the component that fired the event, in which case, the scope would typically be set to scope: this. However, it's possible to specify a different value for scope in your listener configuration. From our previous example, a change in scope might look like the following:

tap: {
 element: 'body',
 scope: eventPanel,
 fn: function(event, div, listener) {
  this.setWidth(event.xy[0]);
  this.setHeight(event.xy[1]);
  console.log(event.xy);
 }
}

In this example, the scope (and as such, the variable this) has been changed to our eventPanel component. We can now set values directly, instead of having to use Ext.getCmp('tapTarget'), to get the panel at the beginning of our function.

We can also set the scope component in a similar fashion, by using the on method to add a listener:

var myPanel = new Ext.Panel({…});
var button = new Ext.Button({…});

button.on('click', function() {
  console.log('This should be myPanel:', this);
}, myPanel);

Here, we added myPanel as an argument after the handler definition, which means that when the click event is fired and the handler function is called, you will be able to access myPanel by referring to this.

Within handler functions, you aren't guaranteed to have access to the same variables when you define the function. Changing the scope of a function can allow you to access a specific variable that's not easy to get to with Ext.getCmp() or Ext.get() . It can also be a simple convenience for getting to the component you are most likely to use in the function.

While scope may be a hard concept to grasp, it is a very useful part of the listener configurations.

Normally, listeners are removed automatically when a component is destroyed. However, sometimes you will want to remove the listener before the component is destroyed. To do so, you'll need a reference to the handler function you created the listener with.

So far, we've been using anonymous functions to create our listeners, but if we're going to remove the listener, we have to do it a bit differently:

var myPanel = new Ext.Panel({…});

var myHandler = function() {
  console.log('myHandler called.'),
};

myPanel.on('click', myHandler);

This can be a good practice, since it allows you to define the handler functions once and reuse them wherever you need them. It also allows you to remove the handler later:

myPanel.removeListener('click', myHandler);

In some cases, listeners are part of a relationship between two objects, and when one of the objects is destroyed, the listener is no longer necessary.

For example, say you have two panels, panel1 and panel2, and you want to change the size of panel1 to match the size of panel2, whenever panel2 is resized. You could put a listener on the resize event for panel2, but if panel1 were to be destroyed, the listener would still be there.

You could add an additional listener to panel1 that would wait for the destroy event and then remove the listener from panel2, but that could become cumbersome quickly.

You can get around this particular problem by using a managed listener. A managed listener works a little bit differently from a regular listener:

var panel1 = new Ext.Panel({…});
var panel2 = new Ext.Panel({…});

panel1.addManagedListener(panel2, 'resize',
  function() {
  console.log('Panel 2 was resized.'),
panel1.setSize(panel2.getSize());
  }
);

This can get a bit confusing, because when we call panel1.on() or panel1.addListener(), we're adding a listener to panel1. However, when we call addManagedListener(), the first argument is actually a different component we're adding the listener to. In this case, we're adding a resize listener to panel2 that will automatically be removed if panel1 is destroyed.

Essentially, addManagedListener adds listeners that clean up after themselves, which can help greatly with memory management.

As you might have noticed from some of our previous code, buttons have a default configuration called handler . This is because the purpose of a button is generally to be clicked or tapped. The handler configuration is just useful shorthand for adding the tap listener. As such, the following two pieces of code do exactly the same thing:

var button = new Ext.button({
text: 'press me',
  handler: function() {
    this.setText('Pressed'),
  }
})

var button = new Ext.button({
  text: 'press me',
  listener: {
tap: {
      fn: function() {
        this.setText('Pressed'),
     }
    }
  }
});

This same default handler behavior applies to tabs as well. The handler simply serves as a quick way to access the most routinely used event for the component.

Sometimes, you will want to keep components from firing events. Perhaps you want to do some additional processing on data returned from an AJAX query, or you want to write some custom code to handle resizing your component. Observable gives you a way to do so via the suspendEvents() and resumeEvents() methods. You can call these methods on any object that extends Observable, such as a panel:

var myPanel = new Ext.Panel({…});

myPanel.suspendEvents();

myPanel.setHeight(100);
myPanel.setWidth(100);

myPanel.resumeEvents();

Normally, the setHeight() and setWidth() functions cause the resize event to fire. In this example, though, we essentially put the panel to sleep while we resize it, and then wake it back up when we're done. In this case, the resize event will never fire, so any components listening for that event will never hear it.

Note that we only suspended events on the myPanel object. If we had resized another panel at the same time, then that panel's events would still have fired.

This is very useful when you need to do things behind the scenes in your application, but sometimes you'll want to have the events fire after you're done with your work, so that the other components can catch up. In that case, simply pass true as the argument to suspendEvents():

myPanel.on('resize', function() {
  console.log('Resized!'),
});

myPanel.suspendEvents(true);

myPanel.setHeight(100);
myPanel.setHeight(100);
console.log('Resuming Events.'),
myPanel.resumeEvents();

You can see how the Resuming Events line comes before the resize events. This is because we didn't fire any events until after the console.log() and resumeEvents() calls.

You should be very careful with suspending events. Much of the built-in Sencha Touch functionality relies heavily on events, and suspending them can cause unexpected behavior.

Let's take a look at our old friend Ext.Component and see some of the common events available to us. Remember, since most of our components will inherit from Ext.Component, these events will be common across most of the components we use.

Most of our events will fall into two categories. The first set of events revolves around the creation of the component.

When the web browser executes your Sencha Touch code, it writes the components into the web page as a series of div, span, and other standard HTML tags. These elements are also linked to code within Sencha Touch that standardizes the look and functionality of the component for all supported web browsers. This process is referred to as rendering the component.

This rendering takes place in a number of stages, each of which fires an event:

These events give you a number of places to interact with your component before, during, and after the rendering process.

The second set of events is concerned with the actions taken by or done to the component itself. These events include:

These events provide a way to base the actions of your code on what is being done by, or done to, your components.

Each component will also have some specific events associated with it. For a list of these events, please consult the API docs at http://docs.sencha.com/touch/1-1/. Just select a component from the list on the left side and click the Events button at the top of the page.

Ext.util.Observable is the base class that handles listening to, and firing of, events for all Sencha Touch components. Any class that fires events extends Ext.util.Observable. For the most part, you won't need to directly use Ext.util.Observable itself, since it comes built into almost every Sencha Touch component, but there are a few cases where using it directly can make things easier.

Sometimes, over the course of building an application, you will find yourself adding the same listeners to the same kind of objects multiple times. For large applications, this can take up quite a bit of memory. That's where Ext.util.Observable.observe() comes in. This method will allow you to add listeners to a class, instead of a particular instance of that class. Normally, when we add listeners, we do something such as this:

var panel = new Ext.Panel({…});
panel.on('resize', function(){…});

The listener will only run if that exact panel is resized. To add a listener to all Ext.Panel components, you can pass the component constructor you want to observe, then add your listeners:

Ext.util.Observable.observe(Ext.Panel);
Ext.Panel.on('resize', function(){…});

You'll notice that we didn't create a new panel here. Instead, we added the resize listener to Ext.Panel itself. Now, any panel you create with the new Ext.Panel() component, it will have the resize listener enabled automatically.

Additionally, this gives you a single place to update when you need to make changes to the resize listener and function. This type of class-based listener can save time, memory, and a lot of headaches.

Ext.util.Observable.capture is a static method. This means you won't have to create a new instance of an object—you can call it directly. This method will call a handler for every single event that an object fires, which can come in handy when you're trying to figure out if you've added listeners to the proper event and if those events are firing.

Using our resizing eventPanel example, add the following line after this.viewport = eventPanel;:

Ext.util.Observable.capture(eventPanel, function() {
  console.log('The eventPanel fired an Event:', arguments);
});

As you can see, this generates a lot of console lines. The first argument to the function will always be the event name, and the subsequent arguments will be the arguments that are typically passed to that particular event. If you want to start capturing events only after a certain known event fires, you can add the capture statement to a listener. For example, if you wanted to only start capturing events after the panel was rendered, you would do someting such as the following:

listeners: {
  render: {
    fn: function(myPanel) {
      Ext.util.Observable.capture(eventPanel,
      function() {
        console.log('The eventPanel fired an Event:', arguments);
      });
    }
  }
}

Now, Ext.util.Observable.capture will only be started once the render event has fired. From that point on, it will continue to capture all events fired by the panel.

You can stop capturing with Ext.util.Observable.releaseCapture(), as well. Say we want to stop capturing events after a resize event. Then, in our capture function, we could do the following:

Ext.util.Observable.capture(eventPanel, function() {
  console.log('The eventPanel fired an Event:', arguments);
   if (arguments[0] == 'resize') {
     Ext.util.Observable.releaseCapture(eventPanel);
   }
});

One of the common uses of event delegation is in lists. Let's say, we have a list of people such as those you would find in a common address book. When a name in the address book is clicked, we switch to the details panel with all of the contact information. This is a pretty straightforward setup most of us would recognize.

However, let's say we want to add a phone icon to each of our list items. When the phone icon gets clicked, the person's phone number is dialed. You might be inclined to add a click handler for each icon, but this is a very bad idea, because all of those listeners take up space in memory.

An address book with 400 people would have 400 listeners. This will slow down a web-based application, as it tries to listen to 400 separate elements within the DOM (in addition to everything else in your code that has a listener).

However, you can get around this problem using event delegation.

Let's start with a very simplified version for our contact list:

var contactList = new Ext.List({
  tpl: '<tpl for="."><li><img src="images/phone.png"/><h1>{contactName}</h1></li></tpl>',
  listeners: {
    el: {
      tap: callContact,
      delegate: 'img'
    }
  }
});

Unlike our previous examples, where we instructed the component which event to listen to, in this case, we tell the component where to listen for the event. In this case, we chose el, which is a property common to all components and basically means within the item (we could also use body).

Now that the component knows where to listen, we tell it what to listen for on the line tap: callContact. This also tells the List component what to run when the tap event occurs.

The last line, delegate: 'img' delegates the event to any img tag inside our List component. In this case, it would be our phone.png icon on each row of the list.

The result is a single listener, which checks to see if an image is tapped in our list.

This saves on memory, and also means that if you add or remove any list items, you don't have to add and remove listeners, too.