Any article mentioning the iPhone is guaranteed to pique interest …but this isn’t a cheap trick, there is substance here as well. Many of our customers find they need to deliver documents or content via several different methods to a variety of users – from power users and administrators to engineers and lawyers to retail customers.
Due to security concerns and potential support requirements, the rule of thumb nowadays when delivering content is thin client (usually a browser) for retail users and fatter client for internal or power users. For example, you can’t presume or expect retail customers to download ActiveX controls or Java applets, even if they provide greater functionality. The results are too variable and customer support can be demanding. So an HTML thin client is a reasonable solution if it offers enough functionality. Here is where AJAX comes in. This increasingly popular browser technology allows you to create, among other things, HTML pages with dynamically updated image areas. A good example is Google Maps. Not a huge amount of functionality but enough for many document and drawing viewing purposes. Response is quick because only the image area is updated; the rest of the page remains unchanged until you need to make it change.
And AJAX doesn’t require anything but Javascript which is standard in an HTML rendering engine like a browser.
So where does the iPhone come in? Well, the iPhone runs the Safari web browser. This web browser is fully functional, so it supports AJAX pages. So if you want to view your bank statement or insurance claim without a computer, fire up your iPhone and start working!
Of course, a lot is happening behind the scenes. The server based application, which can be a .NET server component or a Java servlet or some other technology, is opening up the documents, rendering pages and sending down the appropriate images and HTML content down to the client. Because most operations (rotate, zoom) on the client require a re-download of the image, it is critical that the server application be fast and powerful and that the data connection be fast.
And what if you’re a more traditional or a power user, and you need to have more functions? Well, if properly designed, you can use a .NET client or a Java applet or some other “fat” client to communicate with the same server component to access your documents and work with them. In those scenarios, you can perform document manipulation right on the client so rotation, zooming and even cropping can be done without re-downloading. In this ideal situation, with the correct architecture one system can satisfy multiple platform technologies and multiple levels of users – how nice is that?
Recent Comments