3.3. AIR Implementation of Functionality
HTML and JavaScript functionality is consistent with that found in
other WebKit-based projects and browsers, such as Apple's Safari browser.
When exploring documentation on HTML engine / browser functionality, you
can use references to the Safari 3 browser as an indicator of the
functionality available within the HTML environment within AIR.
However, because the HTML engine is running within Adobe AIR, and
not a browser, there are a few differences that are useful to understand
before beginning development with HTML and JavaScript within Adobe
AIR.
3.3.1. URI Schemes
Working with Universal Resource Identifiers (URIs) within HTML content
in AIR applications is largely the same as working with URIs within the
browser. This section gives a quick overview of working with URIs within
HTML content in AIR applications, and introduces some new URIs made
available by the runtime.
3.3.1.1. Supported URI schemes
Adobe AIR provides support for the most common URI schemes available within the browser
| Scheme | Description | Example |
|---|---|---|
| http:// | URI that points to a resource accessed via the standard HTTP protocol. | http://www.adobe.com |
| https:// | URI that points to a resource accessed via a protocol encrypted with SSL/TLS. | https://secure.example.com |
| file:// | URI that points to a resource on the local or a networked file system. | file:///c:/Test/test.txt |
| mailto: | URI that opens the default email application. | mailto:john.doe@example.com |
3.3.1.2. Unsupported URI schemes
The feed:// and data:// URI schemes are not supported by Adobe AIR 1.0, and there is only
partial support for the ftp://
scheme.
Finally, the javascript: URI
scheme is not supported within applications running within the
Adobe AIR application sandbox. Please check the Security model section later is this
chapter for more details.
3.3.1.3. AIR URI Schemes
Adobe AIR also provides a number of additional URIs that makes it easy
to reference files and content within specific areas of the users
system.
| URI | Description | Example |
|---|---|---|
| app:/ | Provides a reference to the root content directory of the application. This should be used when referencing content included within the AIR file. | app:/images |
| app-storage:/ | Provides a reference to an application-specific storage area on the user's system. This area is useful for storing user-specific application settings and content. | app-storage:/settings/pref.xml |
NOTE
The AIR-specific URIs take only a single slash, versus two
slashes in the other URIs.
Within HTML content, these URI schemes can
be used anywhere within HTML and JavaScript content where regular HTTP
URIs are used.
3.3.2. Relative URLs
You're not restricted to using just absolute URLs within AIR
applications. You can also use relative URLs, but it is important to
remember that relative URLs within AIR applications are relative to the
application, and not to a server (as they would be when doing
traditional browser-based client/server development).
Relative URLs will be relative to the root of the application, and
will resolve to the app:/ URI.
For example:
<img src="foo/image.png" />
will resolve to:
<img src="app:/foo/image.png" />
You should keep this in mind when moving web and browser-based
content and code into an AIR application.
3.3.3. Cookies
Adobe AIR has full support for setting and getting cookies from
HTML-based content in remote sandboxes (content loaded from http:// and
https:// sources) that is bound to a specific domain. Content loaded
from the installed directory of the application (referenced via app:/
scheme) cannot use cookies (the document.cookie property).
Cookie support is implemented via the operating system's
networking stack. This means that AIR applications can share cookies set
by any browser or application that also leverage the operating system
stack.
For example, AIR applications can share cookies set through
Internet Explorer on Windows, and Safari on Mac, as they both also use
the operating system's cookie storage functionality. Firefox implements
its own cookie storage and thus cookies set within Firefox cannot be
shared with AIR applications
NOTE
In addition to cookies, AIR applications have a number of other
APIs that can be used to persist data, including the file API, as well
as the embedded database API.
3.3.4. Windowing
3.3.4.1. Windows
You can create new windows via JavaScript just as you can within the
browser.
myWindow = window.open("Window.html", "myWindow",
"height=400,width=400");
However, the runtime property that provides access to AIR and
Flash Player APIs is not automatically available within the new
window. In order to make it available, you must explicitly place it
within the scope of the new window like so:
window.runtime = window.opener.runtime;
You can also create native windows using apis provided by AIR.
The HTMLLoader class includes a
static method, HTMLLoader.createRootWindow(), which lets
you open a new window (represented by a NativeWindow object) that contains an
HTMLLoader object and define some
user interface settings for that window. The method takes four
parameters, which allow you to define the user interface.
var initOptions = new runtime.flash.display.NativeWindow
InitOptions();var bounds = new runtime.flash.geom.Rectangle
(10, 10, 600, 400); var myHtml= runtime.flash.html.HTMLLoader.
createRootWindow(true, initOptions, true,bounds);
var urlReq = new runtime.flash.net.URLRequest("http://www.
example.com"); myHtml.load(urlReq);
Windows created by calling createRootWindow() directly in JavaScript remain independent from the opening HTML
window. The JavaScript window opener and parent properties, for example, are null.
3.3.4.2. Dialogs
The alert, confirm and prompt HTML dialogs are also supported within Adobe AIR.
In addition, the file-browse dialog created via:
<input type="file" />
is also supported in Adobe AIR 1.0.
3.3.5. XMLHttpRequest and Ajax
The XMLHttpRequest object,
which enables the use of Ajax techniques for sending and
loading data, is completely supported within AIR applications.
One advantage to developing Ajax applications within Adobe AIR
versus the browser is that because you have a consistent runtime to
target across operating systems, you do not have to worry about cross-browser, platform
inconsistencies in how the API is implemented.
The primary benefit of this is that you have to write only one
version of the code.
Here is a simple example of an XMLHttpRequest object call within an AIR
application that works regardless of which operating system the
application is running on:
<script type="text/javascript">
var xmlhttp;
function appLoad()
{
//replace with URL to resource being loaded
var url = "http://www.mikechambers.com/blog/";
xmlhttp = new XMLHttpRequest();
xmlhttp.open("GET", url,true);
xmlhttp.onreadystatechange=function(){
if (xmlhttp.readyState==4)
{
runtime.trace(xmlhttp.responseText);
}
}
xmlhttp.send(null)
}
</script>
When called, this function uses the XMLHttpRequest object to load the specified
URL and prints its contents out to the command line. The main thing to
note in this example is that because the runtime is known and it is
consistent across operating systems, you do not have to detect the
existence of, or in the implementation of XMLHttpRequest as you would when deploying in
the browser.
Both synchronous and asynchronous XMLHttpRequest calls are supported, as is
loading data across domains.
3.3.6. Canvas object
The canvas element is supported by WebKit and also by AIR. It defines APIs for
drawing geometric shapes, but in most respects it behaves like an
image.
The result of a drop operation when dragging images can be among
other types (e.g.: a file reference) a canvas element; it can be
displayed by appending the element to the DOM.
3.3.7. Clipboard object
The WebKit Clipboard API is driven with the following events: copy, cut, and paste. The event object passed in these events provides access to
the clipboard through the clipboardData property.
You can use the methods of the clipboardData object to read or write
clipboard data.
For more details on how to do these operations, please check the
cookbook chapter.
3.3.8. Drag and drop
Drag-and-drop gestures into and out of HTML produce the
following DOM events: dragstart,
drag, dragend, dragenter, dragover, dragleave, and drop. The event object passed in these events
provides access to the dragged data through the dataTransfer property.
The dataTransfer property references
an object that provides the same methods as the clipboardData
object associated with a clipboard event.
For more details on how to work with drag and drop, please check
the cookbook chapter.
3.3.9. Supported plug-ins
Adobe AIR does not support other plug-ins except Acrobat or Adobe Reader 8.1+ for displaying PDF content
and Flash Player plug-in for displaying SWF content.
In order to load Flash content into HTML, you use the same embed
element syntax that you use when embedding Flash content within a
browser page.
<embed
src="content.swf"
quality="high"
bgcolor="#FFFFFF"
width="400"
height="200"
name="content"
swLiveConnect="true"
align="bottom"
allowScriptAccess="always"
type="application/x-shockwave-flash" pluginspage="http://
www.macromedia.com/go/getflashplayer" />
NOTE
You can load both relative and absolute URLs, with relative URLs
being relative to the application install directory.
You can use the same techniques that you use in the browser, such
as the ExternalInterace API, to
facilitate Flash to HTML and HTML to Flash communication within HTML
content.
For the SWF content, the Flash Player plug-in is built into AIR
and doesn't need to use an external plug-in.
3.3.10. Unsupported functionality
The window.print()
method is not supported within Adobe AIR 1.0. There are other
methods available via the exposed AIR APIs that give you access to
printing within the runtime, but these might feel different from what is
available at the browser level.
In addition, support for Scalable Vector Graphics (SVG) is not included in AIR
1.0.
No comments:
Post a Comment