AIR
uses
WebKit
(www.webkit.org
),
also used by the Safari web browser, to parse, layout, and render
HTML and JavaScript content. The built-in host classes and objects
of AIR provide an API for features traditionally associated with
desktop applications. Such features include reading and writing
files and managing windows. Adobe AIR also inherits APIs from the Adobe® Flash® Player,
which include features like sound and binary sockets.
Important:
New versions of the Adobe AIR runtime may include
updated versions of WebKit. A WebKit update in a new version of
AIR
may
result in unexpected changes in a deployed AIR application.
These changes may affect the behavior or appearance of HTML content
in an application. For example, improvements or corrections in WebKit
rendering may change the layout of elements in an application’s
user interface. For this reason, it is highly recommended that you
provide an update mechanism in your application. Should you need
to update your application due to a change in the WebKit version
included in AIR, the AIR update mechanism can prompt the user to
install the new version of your application.
The following table lists the version of WebKit used in each
release of AIR. The closest corresponding release of the Safari
web browser is also given:
|
AIR version
|
WebKit version
|
Safari version
|
|
1.0
|
420
|
2.04
|
|
1.1
|
523
|
3.04
|
|
1.5
|
526.9
|
4.0 Beta
|
|
2.0
|
531.9
|
4.03
|
|
2.5
|
531.9
|
4.03
|
|
2.6
|
531.9
|
4.03
|
You can always determine the installed version of WebKit by examining
the default user agent string returned by a HTMLLoader object:
air.trace( window.htmlLoader.userAgent );
Keep in mind that the version of WebKit used in AIR is not identical
to the open source version. Some features are not supported in AIR
and the AIR version can include security and bug fixes not yet available
in the corresponding WebKit version. See
WebKit features not supported in AIR
.
Using
the AIR APIs in HTML content is entirely optional. You can program
an AIR application entirely with HTML and JavaScript. Most existing
HTML applications should run with few changes (assuming they use
HTML, CSS, DOM, and JavaScript features compatible with WebKit).
AIR gives
you complete control over the look-and-feel of your application.
You can make your application look like a native desktop application.
You can turn off the window chrome provided by the operating system
and implement your own controls for moving, resizing, and closing windows.
You can even run without a window.
Because
AIR applications run directly on the desktop, with full access to
the file system, the security model is more stringent than the security
model of the typical web browser. In AIR, only content loaded from
the application installation directory is placed in the
application sandbox
.
The application sandbox has the highest level of privilege and allows
access to the AIR APIs. AIR places other content into isolated sandboxes
based on where that content came from. Files loaded from the file
system go into a local sandbox. Files loaded from the network using
the http: or https: protocols go into a sandbox based on the domain
of the remote server. Content in these non-application sandboxes
is prohibited from accessing any AIR API and runs much as it would
in a typical web browser.
HTML content in AIR does not display SWF or PDF content if alpha,
scaling, or transparency settings are applied. For more information,
see
Considerations when loading SWF or PDF content in an HTML page
and
Window transparency
.
