Ajax is especially important for mobile devices. The ability
to download only the data to be updated and avoid unnecessary page loads
is key for mobile browsers. However, Ajax is not part of the official
standards, and support can vary from device to device.
Note:
If your mobile website gets content using Ajax, you should
implement Google’s proposal for search engine optimization (SEO). You
can find more information about this at http://code.google.com/web/ajaxcrawling.
Let’s first verify the browsers’ support for the XMLHttpRequest native
object (see Table 1).
Cross-domain requests are not compatible with mobile browsers today
because of supposed security
problems, but you can bypass this problem with a simple proxy on your
server.
Table 1. XMLHttpRequest support compatibility table
| Browser/platform | XMLHttpRequest
support |
|---|
| Safari | Yes |
| Android
browser | Yes |
| Symbian/S60 | Yes since
3rd edition |
| Nokia Series
40 | No before
6th edition |
| webOS | Yes |
| BlackBerry | No before
4.6 |
| NetFront | No before
3.5 |
| Internet
Explorer | Yes since Windows Mobile
5 |
| Motorola Internet
Browser | No |
| Opera Mobile | Yes since
8.0 |
| Opera Mini | Yes since
3.0 |
When we say that the object is available, we are talking about full
support for the following properties and methods:
open
abort
send
onreadystatechange
readyState
status
responseText
1. XML Parsing
The property (standard in desktop Ajax) we left out from
the previous list is responseXML. That is because XML
parsing is a more complex mechanism inside the browser and can have some
problems. The first difference we need to verify is how the browsers
treat whitespace inside tags. Let’s look at a simple example:
<node>
<subnode />
</node>
Some browsers understand that the previous code is a node with
only one child, the subnode. Other XML parsers believe that there are
three children: a text node with spaces (and a newline character), the
subnode, and another text node. This difference can be a little
difficult to debug if we are not aware of it. Table 2 shows
which browsers support XML parsing, and the nature of that
support.
Table 2. XML parsing compatibility table
| Browser/platform | XML parsing
support | Spaces as
children |
|---|
| Safari | Yes | Yes |
| Android
browser | Yes | Yes |
| Symbian/S60 | Yes | Yes |
| Nokia Series
40 | No before
6th edition | Yes |
| webOS | Yes | Yes |
| BlackBerry | No before
4.6 | Yes |
| NetFront | Yes from
3.6 | Yes |
| Internet
Explorer | Yes | No |
| Motorola Internet
Browser | No | Yes |
| Opera
Mobile | Yes | Yes |
| Opera Mini | Yes, on the
server | Yes |
2. JSON Parsing
JavaScript Object Notation (JSON) is the most lightweight
solution for Ajax because it allows us to use dot notation for object
access, rather than the DOM parsing required for other techniques, such
as XML. We receive the JSON as text with responseText and convert it to an object using
eval. So, the first question is: how
well does eval work on mobile
devices?
We need to test eval support
for JSON objects using the strict standard and the de facto standard
used on and compatible with most browsers. The differences between the
two are shown in this code, and Table 3
reports on whether they worked:
// Strict standard
var obj = {
'name': 'John',
'surname': 'Doe'
}
// De facto standard
var obj = {
name: 'John',
surname: 'Doe'
}
Table 3. JSON parsing compatibility table
| Browser/platform | eval with JSON (strict
and de facto standards) |
|---|
| Safari | Yes |
| Android
browser | Yes |
| Symbian/S60 | Yes |
| Nokia Series
40 | No before
6th edition |
| webOS | Yes |
| BlackBerry | No before
4.6 |
| NetFront | Yes |
| Internet
Explorer | Yes |
| Motorola Internet
Browser | Yes |
| Opera
Mobile | Yes |
| Opera Mini | Yes |
Note:
For low- and mid-end devices with Ajax support it is not
recommended to create more than two connections to the server at the
same time. If possible, try to keep the number of simultaneous
connections to the minimum.
3. JSONP and Lazy Loading
JSON with Padding (JSONP) is a very modern technique for
accessing a third-party domain’s content without the cross-domain
problems of Ajax requests. Many public web services are offering this
new way of communicating with third-party servers.
JSONP uses a script tag generated by JavaScript to a URL with a
parameter we define, generally for a local callback function to be
called when the script (and the data it fetches) is downloaded and
executed.
A very similar technique is used for scripting code: you download
only a subset of the scripts in the initial download, and then you
download the other scripts that you will need later.
JSONP needs one feature to be working on the browser: the ability
to insert a script dynamically from JavaScript. If this feature works,
the browser should detect the new DOM script element and automatically download and
execute this new resource. As this script will call your function with
the data, you will be able to receive data from a third-party
server.
Note:
Modern JavaScript libraries such as jQuery support JSONP
requests without dealing with DOM. You can use $.getJSON with a parameter to replace an
Ajax query with a JSONP query.
Generally, the third-party server offers some URL to use JSONP as
format. For example:
http://api.thirdpartyserver.domain/<jsonp_script>?<callback>=<our_function>
The server will respond with something like this:
<our_function>( {<json_data>} );
We can test if a mobile browser detects the dynamic creation of
script elements using the following
code:
function doJSONP() {
var head = document.getElementsByTagName('head')[0];
var script = document.createElement('script');
script.type = 'text/javascript';
script.src = 'http://mobilexweb.com/tests/jsonp?cb=finished';
head.appendChild(script);
}
Table 4 shows how well
this works on the different browsers. Some browsers support an onload event that can be applied to the script
and will be executed when the script is ready. JSONP doesn’t need this
event because of the callback definition in the same URL, but for lazy
loading it can be useful on compatible browsers.
Table 4. Dynamic script loading compatibility table
| Browser/platform | Dynamic script loading
support | onload
support |
|---|
| Safari | Yes | Yes |
| Android
browser | Yes | Yes |
| Symbian/S60 | Yes | Yes |
| Nokia Series
40 | No before
6th edition | |
| webOS | Yes | Yes |
| BlackBerry | Yes from
4.6 | No |
| NetFront | Yes | No |
| Internet
Explorer | No | |
| Motorola Internet
Browser | No | No |
| Opera
Mobile | Yes | Yes, and onreadystatechange |
| Opera Mini | No | |
4. Comet Techniques
Comet is a new web application model
that provides an alternative to the polling design pattern used for
making periodical checks for news on a server and similar tasks. With
this model, we can send long-lived HTTP requests that remain open until
the server has a response to give to the client.
For example, if we are showing a mailbox, we might want to check
whether there are new messages every x seconds. A
Comet technique allows us to emulate a kind of push technology where
instead of us making a request every x seconds, we
make only one request and the server holds that request open until it
has new data for us. This can result in HTTP connections being held open
for a very long time. This is only one kind of Comet technique; there
are others available, but they are not very reliable.
Note:
Palm, BlackBerry, and Apple offer push services for developers:
that is, we can push messages or content from our servers to their
servers, and they will push the information to the devices.
Unfortunately, these features are not available for web applications
in Palm and Apple’s solutions.
These techniques are not recommended for mobile browsers yet. The
main problem will be 3G and 2.5G network connections: even if the server
accepts them, Internet gateways are not prepared for long-lived HTTP
connections, and the proxies will terminate the connections after a
period of time.
Warning:
If you are using a hung connection at the server as a Comet
solution, be aware that only Symbian 5th
edition, mobile Safari, Windows Mobile 6.5, and Android give
predictable results. On Series 40 6th
edition and other devices, the browser hangs with the request, so the
user cannot even click on a link.
There are also some Adobe Flash solutions that work by opening
sockets to receive news from the server. This will only work when Flash
Player 10.1 has become widespread, though, and using WiFi. 3G networks
will not be reliable for these situations. We will also need to be
careful about battery consumption.
