MICROSOFT_PRESS_EBOOK_PROGRAMMING_WINDOWS_8_APPS_WITH_HTML_CSS_AND_JAVASCRIPT_PDF

More important than minimizing closures is making sure that the event listeners themselves—and
their associated closures—are properly cleaned up and their memory allocations released.
Typically, this is not even something you need to think about. When object such as HTML elements
are destroyed, such as when a page control is unloaded from the DOM, their associated listeners are
automatically removed and closures are released. However, in a Windows Store app written in HTML
and JavaScript, there are other sources of events for which the app might add event listeners, where
those objects are never destroyed. These can be objects from WinJS, objects from WinRT, and window
and document. Those listeners must be cleaned up properly, or else the app will have memory leaks
(memory that is allocated but never freed because it’s never released for garbage collection).
Of special concern are events that originate from WinRT objects. Because of the nature of the
projection layer that makes WinRT available in JavaScript, WinRT ends up holding references to
JavaScript event handlers (known also as delegates) while the JavaScript closures hold references to
those WinRT objects. As a result of these cross-references, those closures might never be released.
This is not a problem, mind you, if the app always listens to a particular event. For example, the
suspending and resuming events are two that an app typically listens to for its entire lifetime, so any
related allocations will be cleaned up when the app is terminated. The same is true for most listeners
you might add for window and document events, which persist for the lifetime of the app.
Memory leaks occur, however, when an app listens to a WinRT object event only temporarily and
neglects to explicitly call removeEventListener, or when the app might call addEventListener for the
same event multiple times (in which case you can end up duplicating closures). With page controls, as
discussed in this chapter, it’s common to call addEventListener within the page’s ready method on
some WinRT object. When you do this, be sure to match that call with removeEventListener in the page’s
unload method to release the closures. I’ve done this in HereMyAm3d with datarequested in
pages/home/home.js just to be clear.
Throughout this book, the WinRT events with which you need to be concerned are highlighted with
a special color, as in datarequested (except where the text is also a hyperlink). This is your cue to check
whether an explicit call to removeEventListener is necessary. Again, if you’ll always be listening for the
event, removing the listener isn’t needed, but if you add a listener when loading a page control, you
almost certainly will need to make that extra call. Be especially aware that the samples don’t necessary
pay attention to this detail, so don’t follow any examples of neglect there. Finally, note that events from
WinJS objects don’t need this attention because the library already handles removal of event listeners.
In the chapters that follow, I will remind you of what we’ve just discussed on our first meaningful
encounter with a WinRT event. Keep your eyes open for the color coding in any case.
132