Mobile thick clients vs thin clients

For many application developers, the fastest, easiest way to introduce a mobile solution was to "chop down" an existing Web-based application. Users that had a device with a browser could then access the applications. However, because the resulting applications were not designed for the navigation capabilities of a mobile device or the smaller bandwidth, the user experience suffered. These problems can be solved by using a thick client instead of a thin client.

With a thin client, there is nothing running on the device except the presentation. All the content is on the host. The data, along with the rules to display it, are sent down and rendered on the local machine. Everything is done on the server; every request requires going back to the host. With a thick client, however, the presentation engine is on the local machine, which does the work.

The need for thick clients is driven by the complexity of the information and the presentation demanded by
mobile users. Mobile users, too, want robust applications and a good user experience. Years ago with the
PC, users went to a Web site and got straight HTML. PC users said, "That's not good enough." Then came
dynamic HTML, Java applets, Flash, and great plug-ins.

It depends on

• what application you want to build
• which audience you want to target
• Operating cost
• Billing and revenue models

Thin clients are good for:

• Displaying regularly changing information eg. news.
• Casual one-off browsing, where the user is unlikely to ever need to come back and benefit from having any sort of state remembered, and not being able to access any content is not a serious problem (due to lack of signal, etc).
• Very changeable data with simple display requirements that change unpredictably over time, with minimal data entry requirements.
• Situations where reliable network connections are guaranteed – either fast connections, or very small nuggets of content that can be found very quickly.

Thick clients are good for:

• Repeated user experiences – local secure caching can reduce data entry, always a significant pain point on mobile.
• Intelligent data delivery can reduce costly data overheads whilst providing faster responses for the user for known types of data set.
• High interactivity and improved user experiences with many potential data visualisation models and on-client validation (minimising round trip requirements to the server, which cost money and time).
• Improved branding around content, which only ever has to be downloaded once rather than at the start of ever session – handsets rarely dedicate persistent storage to browser caches so ever visit to a branded site reloads many Kbs of images, CSS etc.
• Real security, guaranteed – there are known issues with Wap security which can even affect Wap2 browsers running through legacy APNs.
• Offline access – content can be stored locally to browse even when there is no signal (eg. Tube maps), data entry can be performed when required and then submitted to a server asynchronously etc.
• Data roaming can be incredibly expensive so for content like travel guides designed to be read abroad, or interactive services for which Java can choose to use SMS instead of GPRS, there are big cost savings to be had.
• Precise optimal rendering of certain types of content, for example barcodes (used for ticketing etc) which would be useless if the handset decided to rescale them badly as can happen when displaying MMS messages or images in browsers.

First is the ability to do local processing and local data storage. With a thin client, modifying one item could require making several trips back to the host. And, because the bandwidth in the wireless world is so small, bringing pages down is a long, arduous task. A thick client, however, enables mobile users to work offline with the local data that is brought down; everything is done locally.

The advantage of a thick client's local processing ability can be seen when a user makes a mistake while entering data. With a thin client, the user would be prompted again, requiring another trip. With a thick client, you could use an "if" statement to determine if the information is correct before sending it to the host, which saves time.