MobileMe isn't just for iPhone users. It also expands upon the simple web apps delivered as part of .Mac using a cohesive Mac OS X inspired interface that behaves more like a desktop app than a web page, providing easy access to data from anywhere you have Internet access. Here's a look at how web apps have developed, how Apple's new online apps work, and the future potential of MobileMe's tightly integrated mobile, web, and desktop apps.
Inside MobileMe: Secrets of the Cloud and Mobile Push (Friday)
Inside MobileMe: Mac and PC cloud sync and mobile push (Saturday)
Inside MobileMe: Apple's Push vs Exchange, BlackBerry, Google (Monday)
Inside MobileMe: iPhone Mail (Tuesday)
Inside MobileMe: iPhone's Exchange alternative for contacts and calendar�(Wednesday)
Inside MobileMe: Web 3 and Web Client-Server Apps (Today)
Before Web Apps: The Document Driven Web
In the era before web apps, the web was a relatively simple system of hyperlinked documents written in HTML. Click a link on a page and your browser would load a new page based on the referenced URL address. The web was brilliantly simple.
However, that simplicity resulted in a number of problems if you wanted to do more than just look at a series of hyper-connected documents. In order to exchange sophisticated transactions with a simple 'fill in the blanks on a form page and submit it,' you'd end up having to reload virtual pages repeatedly.
This is particularly problematic for something like web mail, where the user waits for updates while interactively sending new messages. Just over a decade ago, the concept of web email was entirely new. Unlike an actual desktop email application, handling email over the web meant loading a new web page, entering your email content, and reloading the page every time you wanted to see updates.
Web 2.0: the arrival of Ajax
In the mid 90s, Microsoft helped to pioneer technologies to improve upon the tedious loading of a series of web pages to do transactional web applications. The company was particularly interested in enhancing web-based email, as it was working to develop both its new mail server (Exchange) and its web browser (Internet Explorer) as critical elements of its overall Internet strategy.
The company first developed IFrames for allowing one page to be embedded in another (like picture-in-picture on TV), so the IFrame region could be independently refreshed and redrawn without reloading the entire page.
It later developed XMLHttpRequest, a method for using a web browser scripting language (often JavaScript) to package up XML data to send to the remote web server. The server then responds with new data which the script can use to interactively update part of the page, rather than reloading and redrawing an entire new page from the server. Because the user does not have to wait for the server to respond before continuing to use the web page, this type of interactivity is referred to as Asynchronous JavaScript with XML, or AJAX.
Microsoft introduced this concept to support richer functionality in Outlook Web Access, a web app it first bundled with Exchange Server 2000. It delivered Ajax functionally via an ActiveX control in IE 5; since then, the mechanism has been copied by Mozilla, Safari, Opera, and most other web browsers, making it a de facto standard for adding richer desktop-like behavior to web apps.
Web 3: HTML5 and Web Client-Server
While Ajax's frequent server updates provide richer interactivity than static web pages, they are rarely capable of being used offline and have other limitations that marginalize them in the minds of many users, who commonly view web email as being a distant runner-up to using a desktop email client. To work around these limitations, Microsoft's own OWA makes heavy use of proprietary extensions to Internet Explorer; few of these have been cloned in Firefox or Safari, nor can they really be because they are not documented standards. That leaves many OWA features tied exclusively to the IE browser; in other browsers it presents a simpler interface.
To foster real interoperability among the next generation of rich web applications, Apple, Microsoft, Mozilla, and Opera have been working on a new HTML5 standard that codifies how features should work so that all browsers can operate the same, and so web developers can make use of more sophisticated interactions on the web, knowing how their apps will behave across all browsers.
There are already web standards in place to define presentation, such as CSS; HTML5 focuses more on behavior, targeting features such as drag and drop, offline editing, local storage, and media playback. Just as Microsoft was motivated to rapidly develop Ajax in the 90s in order to enhance its email presentation on the web, Apple is leading the development of HTML5 to put its rich media client apps on the web, starting with the iLife-connected Web Gallery in .Mac, and broadening to the suite of apps in MobileMe, which will continue to develop in the coming months.
JSON Lives
Apple is building its MobileMe "Web Client-Server" apps using the SproutCore JavaScript application framework, which was designed around the concept of making web apps that are more than just a thin layer of Ajax lubricating interactivity on the web. A Web Client-Server app is loaded by the browser's JavaScript interpreter and runs as a self-contained application, making Ajax-like calls to the server while offering an even richer and deeper level of local user interaction, delivering a more immediate response to the user and offering the potential for client-side storage and offline operation.
Web Client-Server apps are entirely HTML pages driven by JavaScript code and presented via CSS. Rather than using the relatively heavyweight XML, they typically use JSON (JavaScript Object Notation), a lighter, simpler object representation that not only carries a data payload like XML, but is also executable by the JavaScript interpreter. This makes JSON faster in both data exchange with the server and in processing on the client side compared to XML.
With that power comes accountability. Being able to inject executable code into a system from malicious sources is a primary security problem. For that reason, web apps that transmit data using JSON have to authenticate with the server and regularly perform security handshakes to ensure that the data being sent back and forth is indeed coming from and going to a trusted source.
On
No comments:
Post a Comment