AIR 1.0 and Spry
Adobe AIR 1.0 was recently released to the world. Folks who have been using Spry within their beta AIR applications, developed with previous versions of the AIR SDK, may find that some functionality no longer works properly when running their application under the AIR 1.0 runtime. This could be due to a couple of changes that were introduced recently, specifically:
- AIR's user agent string was changed.
- AIR now disables certain browser functionality within the application sandbox.
To address these issues, the Spry Team has recently released Spry 1.6.1 to enable pages that use Spry, to run properly within AIR 1.0 applications, with a few small tweaks. The Spry 1.6.1 release can be downloaded here.
Below we go into more details as to what has changed within AIR 1.0, and how it affects pages that use Spry.
AIR User Agent String Changed
The user agent string for the AIR runtime used to contain the keyword "Safari" in it. For AIR 1.0, "Safari" was removed. Because of browser implementation differences, it is sometimes necessary for Spry to figure out what browser it is running under. The browser detection code used within Spry used to rely on the keyword "Safari" to trigger any code specific to the layout/rendering engine used within the Safari browser. Since AIR uses the same rendering/layout engine that Safari does, this meant that the same code would be triggered since the AIR runtime's user-agent string contained the keyword "Safari". Now that they differ, some of the Spry source code must be updated so that Spry can identify both Safari and AIR browsers.
For the Spry 1.6.1 release, all source files that previously performed browser checks for "Safari" have been modified to look for the string "WebKit", which correctly identifies the layout/rendering engine used in both Safari and AIR.
AIR Application Sandbox Disables Functionality
The application sandbox within the AIR 1.0 runtime has security measures in place that disable certain browser functionality considered to be high-risk since they could potentially be exploited by unauthorized parties, after the onload event fires. The features that have been disabled all revolve around the dynamic execution/evaluation of JavaScript strings.
The Spry data component relies on some of the functionality that is disabled within the application sandbox for region processing. What follows is a short list of what is disabled after the onload event fires, and how it impacts the various components within Spry:
- eval()
- All calls to eval() after the onload event is fired, are ignored, except in the case where eval() is called with a strict JSON string.
- This breaks the following Spry features:
- spry:if and spry:test attributes currently require eval() to evaluate their JavaScript expression value. For Spry 1.6.1, these attributes have been enhanced so that the developer can specify a function, instead of a JavaScript expression, to call whenever those attributes need to be evaluated. For more information see the API documentation for spry:if.
- <script> tags that are inside the region template markup are evaluated with eval() every time the region is re-generated. As a workaround, developers can trigger script via an onPostUpdate observer on the region. Checkout the samples page for examples of how to use region observers.
- setTimeout()
- Dynamically Inserted <script> Tags
- <script> tags that are inserted via innerHTML are ignored.
- on* Event Attributes
- on* event attributes (such as onclick, onmouseover, onmouseout, etc) on elements inserted dynamically with innerHTML are ignored.
- This means on* attributes on elements within Spry region template markup will no longer function after the region is re-generated. Developers can work around this problem today by using region onPostUpdate observers to unobtrusively attach or execute behaviors after the re-generated content is inserted into the document. Checkout the samples page for examples of how to use region observers and unobtrusively attach behavior.
More Info
The Spry Team has put together a case study article that walks developers through the changes that were necessary to get the Spry Photo Gallery running under AIR 1.0. Developers will need to use these same techniques when attempting to get their own pages, that use Spry, to run under AIR 1.0.
The final version of the Spry Photo Gallery, discussed in the case study article, that runs under AIR 1.0 can be found here.