Dependencies and upgrading
If your project is built with Alloy, good news! An older version of Backbone ships with Alloy by default, as well as its underscore dependency. If you’re maintaining a classic Titanium project, you can download the most recent version of Backbone and underscore from here and use them like normal commonjs libraries. Additionally, we have provided an updated version of Backbone that has been modified to work with the current version of Alloy. To use it in an Alloy project, just place the minified version in your lib folder and add
An aside on the topic of mixins
On to the main Backbone.Event
The core advantage of building a Titanium app with Backbone is its powerful event system, and it couldn’t be easier to use. To mix in Backbone Events to an alloy controller, just add
Now that you have backbone events mixed in to your controller, you can start listing to and triggering them. First, let’s set up an event listener.
To break down that code snippet, using the ‘on’ function from underscore you can subscribe a function to be executed every time that some event is fired. Then, from whithin the other controller, you can use the ‘trigger’ function to notify listeners of some action. For example, if you had some picker controller, you could trigger a ‘change’ event whenever the user makes a new selection, and then listen for that event from the parent controller.
So why not normal callbacks?
Secondly, Backbone exposes a handful of functions that makes it very easy to clean up event listeners en masse. You can use ‘off’ to dismiss event listeners individually, dismiss listeners for an individual event, or tear down every event listener associated with a given object.
In addition to this system for managing events, the most recent version of Backbone provides a number of functions to allow objects to better manage their event listeners.
The advantage of using the listenTo pattern is that either object can tear down an event listener shared by them. This has important implications for Alloy controllers: as long as you manage most of your cross-controller interactions through Backbone.Events, you can tear down every event listener originating from a controller with a single call. We can use this feature to set up intelligent disposal functions that let us tear down most references to a controller quickly and prevent memory issues.
And that’s it. From here, you can set up other controllers to listen to the dispose event and do things like remove the controller when its disposed or build out new UI on controller disposal. Then, after all of the dispose listeners have been handled, all event relationships are automatically disposed of. Assuming you clean up all of your references in dispose events, there’s nothing else you need to do for the average controller to keep memory in check. Bear in mind that things like app-wide events (such as events on Titanium.App, Titanium.Geolocation, Titanium.Gesture, etc.) can still lead to memory leaks and should be handled in your disposal listeners.