Posts in Category "AIR 1.5.2"

Object Graphs, the GC, and System.disposeXML()

AIR 1.5.2 contains a new, performance-related API that heavy users of XML may find handy, System.disposeXML(), that is an instructive example regarding use (and abuse) of the AIR garbage collector.

When an XML document is loaded, it’s stored in memory as a graph of individual objects representing elements, text, attributes, and so on. Each pair of related objects–for example, a parent/child element parent–are linked, in the underlying representation, with pointers going in both directions.

This is a convenient representation for traversal, but can be problematic for the garbage collector. As I mentioned in my earlier post about referencing counting and ActionScript objects, the garbage collector will eventually find and discard the entire set of objects after the last external reference is removed. However, it takes more work for the GC than less-connected data structures.

In practice, the amount of time it takes the garbage collector to do its job is related both to the number of allocated objects and the number of pointers between them. So while it is nice that the GC is capable of finding even these highly-connected graphs of objects, using them is also asking it do a lot of work. You can reduce this workload by explicitly disconnecting the pointers between objects.

For graphs of ActionScript objects, you can ease the GC workload by simply nulling out reference between the objects. Note that you don’t have to find every last reference for this to be helpful. The GC will still do it’s job in the end, and every bit of clearing references helps. For ActionScript objects this can be particularly helpful because, if their reference count then goes to zero, they can be cleaned up even before the GC sweep completes.

XML objects are a trickier case because the API doesn’t allow developers to traverse the actual object graph. That’s where System.disposeXML() comes in: It traverses the internal object graph backing the XML object, setting all of the internal points to null. Afterwords, the XML object is empty and, presumably, useless. But then, since you were done with it anyway, that shouldn’t be a problem.

Preventing ESC in Full Screen Interactive

Penultimate post on the AIR 1.5.2 update: Prior to AIR 1.5.2, if a user hit the escape key when an application was running in fullScreen or fullScreenInteractive, the application would be forced out of full screen mode. This remains the intended behavior for fullScreen, but was a defect in the implementation of fullScreenInteractive.

Starting with AIR 1.5.2, hitting escape causes fullScreenInteractive to exit by default but the behavior can be canceled by calling preventDefault() on the keydown event. Applications that use full screen to keep users (perhaps kids) from too easily leaving the application may find this change useful. As always, remember to update your namespace to take advantage of this new behavior.

SWFs in HTML in Transparent Windows in AIR 1.5.2

One of the admittedly more annoying limitations of the Adobe AIR HTMLLoader implementation is that it does not render SWFs embedded in the HTML when displayed in a transparent window. In AIR 1.5.2, this restriction has been partially lifted.

The problem arises because, by default, Flash Player renders content into a separate window that is positioned on top of the correct location relative to the underlying HTML. This is the original browser rendering for plug-ins. It’s straightforward, but makes it impossible for the rendered plug-in content to participate in the blending of the transparent window’s contents against whatever lies behind the window.

Flash Player has for some time offered alternate rendering models in which the contents are drawn as part of the HTML content instead of as a separate window. This allows the content to be covered by HTML elements–drop down menus, for example. These modes are accessed by setting the “wmode” parameter to “transparent” or “opaque”. See this Tech Note for details.

Prior to AIR 1.5.2, the HTMLLoader refused to display any SWF when it was inside a transparent window in order to avoid the incorrect rendering that would otherwise result. Starting with 1.5.2, the wmode of the content is inspected. If the wmode is “window”–the default value–the content can still not be rendered correctly, and the old behavior still applies. However, if the wmode is “transparent” or “opaque”, the SWF will be rendered and, because it is rendered into the HTML content, will correctly participate in the window transparency.

LocalConnection.isPerUser in AIR 1.5.2

New to the AIR 1.5.2 release (and the corresponding Flash Player, 10.0.32) is the LocalConnection.isPerUser property. Note that you’ll need to update your application’s namespace to …/1.5.2 to access this property. Here’s why you should do that.

LocalConnection provides local (i.e., on the same machine) communication between SWFs and AIR applications. It operates via a shared memory segment that’s visible to all processes that use the mechanism.When LocalConnection was first implemented on Mac OS, it used a memory segment that is visible to all processes running on the machine. This was reasonable at the time, but problematic now that Mac OS is a multi-user operating system. The unfortunate result is that LocalConnection can be used to communicate across user accounts on Mac OS.

To address this a new, per-user implementation has been implemented on Mac OS. You should always use this mode; it’s safer. To do that, set LocalConnection.isPerUser = true on every LocalConnection object you create.

Unfortunately, AIR can’t do this for you transparently. The problem is that, if it did, you could get into a situation where version skew breaks use of LocalConnection. For example, this can occur if an application is running on AIR 1.5.2 and attempts to communicate with a SWF in the browser running on Flash Player 9. Until both sides are updated, there’s no way to use the isPerUser = true option. By adding an API and making this an option, we’ve given you a chance to migrate to this option without breaking anything along the way.

This issue is specific to Mac OS. Windows and Linux use a user-scoped LocalConnection in all cases, regardless of the isPerUser setting. You can safely set LocalConnection.isPerUser = true everywhere and be confident that the Windows and Linux behavior won’t change.

Final note: The default setting of this property is likely to change to true in a future release, in order to be consistent with our general philosophy of defaulting to safe behavior.

Revised AIR 1.5.2 Application Install Experience

The Adobe AIR 1.5.2 release is now available. There are relatively few changes in it, given that it’s a minor release, but I’ll nonetheless be posting a few entries about the more interesting changes.

Perhaps most interesting of all is that we’ve revised the much-loved unrestricted system access warning that’s displayed during application install. I think you’ll be pleased with the new design:


Please note that this change applies only to applications signed with certificates that are trusted on the targeted machine. I hope you’ll find some comfort in knowing that we do, indeed, listen to–and appreciate–your feedback.