webOS skill level: Beginner
Technologies covered: Ajax
Prerequisite knowledge: Advanced-level HTML, CSS, and Javascript
Ajax and webOS
First off: What is Ajax? From wikipedia:
Ajax...is a group of interrelated web development techniques used to create interactive web applications or rich Internet applications. With Ajax, web applications can retrieve data from the server asynchronously in the background without interfering with the display and behavior of the existing page.
Basically, if your goal is to create an interactive web page that makes use of remote data (information that does not reside on the user's local device) and responds to user input without reloading a new page, you want to use Ajax. But what does this mean for webOS developers?
So far, Palm has not specifically provided any best practices when it comes to transferring data to and from remote servers. Will there be a custom Mojo function for this? Maybe...however, Palm is really stressing that webOS applications are based on the Ajax programming paradigm so it is also quite possible that remote data transfer will be done via existing Ajax functionality built in to JavaScript or the Prototype JavaScript framework that will be bundled with webOS devices. This tutorial will get you up to speed on these methods.
Although AJAX stands for Asynchronous JavaScript and XML, you do not have to use XML as the data transfer format. In fact, other data formats may be preferred for their simplicity or their specific use in a particular application.
Using Ajax in your webOS application can be distilled into the following 3 steps:
- Create a scene containing a a UI control or widget hooked up to a JavaScript listener function designed to retrieve data from a webserver using Ajax.
- Create a page on your webserver that is designed to process Ajax requests made from your application and return the requested data.
- Process the returned data and display it to the user.
Ajax using "plain" Javascript
Using Ajax to retrieve and pass data to and from a remote server can be accomplished by accessing the XMLHttpRequest object using plain JavaScript . I could write a detailed tutorial here, but w3schools has already done a great job; why reinvent the wheel? This article taught me the basics of Ajax:
https://www.w3schools.com/Ajax/default.asp
If you find this example confusing or could use some additional clarification, this site has posted the same tutorial with different commentary, as well as a server-side script written in PHP instead of ASP:
https://www.tizag.com/ajaxTutorial/ajaxphp.php
Both tutorials detail the usage of an ActiveX object for IE browsers; you can safely ignore any references to the ActiveX object as webOS will not be using it. (ActiveX is a proprietary Microsoft technology.)
One thing I want to call out in these tutorials: the responseText property of the XMLHttpRequest object contains whatever you want to return from your page. That could be XML, JSON, or data formatted specifically for use in your application. For example, I created an application that would populate drop-down menus on an HTML form automatically. So the data I returned with my script was in the format:
and I plugged this directly into my HTML element; no messy XML parsing required.
Also note that some browsers currently restrict XMLHttpRequest calls from communicating with servers that are on a different domain than the one from which the web page was loaded. In the case of webOS, the application's scene will be loaded from the Pre's internal "server", so if this restriction were to be in effect, it would result in no applications being able to use XMLHttpRequest to retrieve data from a web server. We'll have to see how Palm handles this. They may require an application to specify the web server(s) with which it will communicate and/or require that the webserver somehow authorize that specific application to retrieve data from it. Or, they may leave it wide open and allow any application to request data from any webserver.
Now that you know how to use the XMLHttpRequest object to get data from your server, let's look at how you might use the Prototype JavaScript framework to accomplish something similar.
Ajax using the Prototype JavaScript Framework
First of all; why would you want to use a framework like Prototype? Why not just use the basic JavaScript functions and avoid the overhead of using a framework code library like Prototype? Good question. Here are a few answers:
- You end up writing many fewer lines and not having to deal with handling cross-browser differences (although cross-browser won't be an issue with webos applications, use of a framework like Prototype would make it easier to modify your application for use on a traditional website). For example, the setup of your Prototype call is neat and tidy and with ability to hook in callbacks and timeout/error cases, which, if you were to handle all that yourself, you'd end up writing that part of the framework yourself in your application's JavaScript.
- You let other people that are experts take care of the finicky details of JavaScript and the DOM so you can focus on building your application.
- As long as the API doesn't break from framework version upgrades, then you benefit from framework improvements without doing much work. The alternative would be to follow the changes in JavaScript and the DOM from platform to platform and version to version to make sure you didn't code something in a way that's becomes deprecated and removed.
- Frameworks like Prototype are usually open-source and community-built, so it's like having thousands of people looking at a part of your application to make sure bugs are found and fixed.
With all those benefits, why would you not want to use a framework like Prototype? There are a few possibilities:
- Increased memory usage. When you use a framework, your application must load the library files of that framework into memory before it can utilize them. The effect of this increased memory usage may be negligible on the Pre or other webOS devices; we won't know for sure until we can get our hands on one. It may also be negated by the fact that if another, already loaded application is using the framework, your application can take advantage of it without a memory penalty as it's already loaded into memory for the other application.
- Increased CPU usage. If your goal is to be as lightweight as possible and your intended use of Ajax is extremely simple, you might be able to accomplish what you're trying to do with a few of lines of "plain" JavaScript instead of loading a full framework and using framework functions, which are generally more computationally expensive as they tend to do a lot of background setup that helps your application be more robust.
- You want minute control over the details. Since a framework like Prototype is designed to take care of the details for you, if you want to tweak a very specific aspect of your Ajax transfer, you may find that the framework functions don't give you enough control.
If you weigh the benefits and drawbacks and decide using a framework is for you, let's look at the Ajax and the Prototype framework!
Once again, I'm going let defer to an already excellent tutorial provided by the folks over at Prototypejs.org:
https://www.prototypejs.org/learn/introduction-to-ajax
You'll notice that Prototype makes it really easy to handle different types of data or error conditions that could be returned from your Ajax call by allowing you to register callback functions that handle each of those possibilities. If you were to handle that all with plain Javascript, you would first need to process the data returned from the Ajax to call to determine whether an error occurred or what type of data was returned before you could even act on it—which means more lines of code.
To see the difference a bit more clearly, the are a couple of tutorials over on The Register that show the same application built with both the XMLHttpRequest object in plain JavaScript and the Prototype framework:
using "plain" Javascript: https://www.theregister.co.uk/2006/06/20/ajax_web_tutorial_part2/
using the Prototype framework: https://www.theregister.co.uk/2006/12/17/ajax_prototype_tutorial/
Ajax and JSON
SeanBlader from the forums pointed out that JSON is a data interchange method that has some advantages over XML. From what we've seen so far from Palm, JSON plays a big part in webOS development, being used in the first official webOS tutorial and some of the supporting material in the recent developer webcast.
Here's a great article on the advantages of using JSON over XML with Ajax:
https://www.developer.com/lang/jscript/article.php/3596836
or in SeanBlader's own words from the forums:
https://www.weboshelp.net/index.php?option=com_jfusion&Itemid=70&topic=13.msg65#msg65
That should give you enough to get started with Ajax on webOS. If you combine what you've learned in this tutorial with our HTML5 Database Storage tutorial, you can figure out how your application could get data from a remote server and store it locally on the Pre or any other webOS device for offline use.
When Palm releases new information or best practices for remote data transfers in webOS, we'll come back and update this article.
Thanks to SeanBlader and alee from the forums for their input on this article. (If you'd like to contact either of them, simply create an account, log in and send them a private message.)
Krishnan makes this comment
Wednesday, 10 February 2010
It was greatly useful to me. could you just explain how to process XML response in Web OS?