Mobile
AJAX & Widgets
Parke Godfrey
16 November 2012
CSE-2041
Parke Godfrey
16 November 2012
CSE-2041
These slides are based in part on ones from the following sources.
CGI: Can use CGI to deliver a “new” version of the present page / webapp.
Always involves the server and network traffic.
Kludgy, if the page / webapp is complex.
JS: Can instrument the page / webapp with JavaScript for behaviour.
Is client-side; no need to involve the server or network.
What if we need stuff incrementally from the server?
But...what if our webapp needs additional information from a server? Or additional components for the webapp?
We don't want to rebuild / refresh the entire page (CGI).
additional information
cascaded options
Choose your country.
Now choose your province / state.
Now choose your city / town.
additional components
Based on product chosen from a drop-down menu, as descriptive paragraph about the product appears on the right.
A comments section that is not shown (or fetched) unless the user “opens” the tab.
Want to call a server “CGI”, but not as a URL link; that would replace our page / webapp!
We need a backdoor.
Make a request to the server CGI, via JS perhaps?
Have the browser catch the response, and notify the JS via a callback.
This was the situation in 2005. And there did not seem any obvious, universal way to do this.
Until...
The Web community was aware of this issue for a long time. And techniques were invented / introduced.
Surprisingly, mostly by Microsoft!
1996: <iframe>
(MS Internet Explorer)
asynchronous!
1998: client-script API XMLHTTP
(Microsoft Outlook Web Access team)
1999: ActiveX
(Internet Explorer 5)
But these were not standard, and a number of these only worked with IE.
AJAX was a total hack, in a way. Came about in 2004–2006 from techniques used in Google pages.
Named in 2005.
Standardized by W3C in 2006: XMLHttpRequest
.
XML
!
XML for the interchange of data
XSLT for its manipulation
JSON
(JavaScript Object Notation)
JS API for working with the return values
ad hoc
E.g., preformatted HTML or plain text
Server CGI can be coded to return anything in any format.
JS manipulates return with string functions and such
Not very flexible! We have to coordinate server CGI and our JS carefully.
We don't want our webapp to be frozen between the time of making a request and receiving the response.
To work around this,
XMLHttpRequest
registers a callback.
The browser forks / threads a small “watchdog” to handle the request.
The callback is registered (a JS function), and the watchdog makes the HTTP request to the server.
Once / if the watchdog gets an HTTP response from the server, it calls the callback JS function with it. (The watchdog may time out.)
The watchdog is decommissioned.
Old-school:
AJAX to the rescue!
And just the two together:
high-quality presentation and control
Well, HTML5, CSS3, & JS are closing in.
local storage
Progress...
HTML5 provides local storage support.
access to client machine's devices
Made available on given platforms through extended APIs for JS.
E.g., BB's Web Works
push notification
Again, platform dependent.
HTTP Cookies
Quite limited; 4KB per domain.
Microsoft's DHTML Behaviors
(userData
)
Allowed 64KB storage, 640KB for trusted domains.
Only IE.
Adobe LSOs.
Backdoored by JS extensions:
Dojo Toolkit
(dojox.storage
)
Non-standard. Requires Flash be installed.
SQLite
A local database! In the standards?
A “light” SQL model.
Unlimited storage!
Google Gears
provided access.
HTML5 / JS
Local key-value storage.
five megabyte limit
localStorage
var foo = localStorage.getItem("bar");
localStorage["bar"] = "Parke";
There is a good overview at Local Storage — Dive Into HTML5.
Coming to a browser sometime soon?
Web SQL Database / “WebDB”
(openDatabase
)
Indexed Database API
Would storing in the DOM be a good idea?
Webapps are pull based.
What do we mean by that?
The client must initiate an HTTP request to a server to get information.
Even so with AJAX.
“Push” is when a server can push information to the client “app” whenever it becomes available.
No need for the client to make the request.
Native apps do this.
Can webapps?
Many apps will periodically poll a server to check for updates.
May register to run in background so to be able to poll even when the app is not actively in foreground.
Disadvantages? Many.
Running in background wastes battery / resources.
Pounds server resources.
Can use up data-plan bandwidth allowance.
Still may not be current enough (depending on polling frequency).
Widgets are becoming a standard way to make “mobile” apps.
Called the “Web Stack” generically on mobile platforms.
HTML5, CSS3, JS, & AJAX.
Called Web Works on the BB Platform.
Mobile platforms offer extended JS API's for
accessing devices (camera, etc.)
local storage
push notification
Mobile ecosystems control push tightly.