There are four different ways to deploy a mobile application, each with their own benefits and downsides. Before you decide on the type of model to use in your applications, let's take a look at them in further detail.
Applications deployed on a thin client model are accessed through browsers on the mobile device, called mobile browsers or alternatively, mini browsers, or wireless Internet browsers. They are essentially scaled-down versions of a full-blown browser. For instance, the default preinstalled browser that comes with the Windows Mobile operating system, Internet Explorer Mobile, is a mobile browser.
In the thin client model, application code and data are not stored on the mobile device. Just like traditional web-based applications, all the work is done at the server, and each page is served up on-demand as they are accessed from the mobile device. Thin-client applications, therefore do not require the installation of any additional software other than the mobile browser.
Thick clients run entirely on the mobile device and store both code and data locally. It must be installed on the mobile device prior to usage. Thick clients typically utilize a mobile database installed on the same mobile device such as Microsoft SQL Server Compact or Oracle Lite. It is common for thick clients to transfer its data from the local database to a remote and central database periodically so that it can be shared with other units. This process is called data synchronization.
The basic set of features you would find common across thick clients include:
- A responsive and interactive UI
- Ability to store data locally in a mobile database
- Ability to synchronize data with a database on a remote server
A smart client, sometimes known as a rich client lies somewhere between a thin client and a thick client. Code is still stored locally on the mobile device, but data is stored on a remote server. Data (commonly in the form of XML) is retrieved from or updated to the server in an on-demand fashion whenever needed. There are various ways over which this data exchange can take place, the most common being web service calls, made over the SOAP (Simple Object Access Protocol) interface.
As smart clients still render the UI of the application locally, it has the benefit of a responsive and rich interface. However, smart clients do not have to worry about data synchronization as all data manipulation is done in real time (via web service calls). Smart clients are suitable for projects where:
Lastly, messaging-based mobile applications make use of services such as SMS (Short Messaging Service) and e-mail to drive the interaction between the user and the application. Like the thin client model, it does not require installation of any specific software other than the messaging application itself.
For example, a stock price enquiry service may involve the following actions:
- A mobile user sends an SMS containing the stock symbol of the desired stock to a special number
- This incoming SMS is processed by the server-side application, which then queries the database and retrieves the corresponding stock price for the symbol.
- The stock price is then sent back to the user via SMS
The following table summarizes the various strengths and shortcomings of each type of mobile application:
|
Feature |
Thick client |
Thin client |
Smart client |
Messaging |
|---|---|---|---|---|
|
Requires installation/stores code locally on the mobile device |
Y |
N |
Y |
N |
|
Requires live network connection to the application server |
N |
Y |
N |
N |
|
Stores data locally and requires database on the mobile device |
Y |
N |
N |
N |
|
Allows application to access low level device functions |
Y |
N |
Y |
N |
|
Middleware requirements on the mobile device |
.NET CF, Mobile Database |
Mobile Browser |
.NET CF |
Messaging application |
|
UI responsiveness |
High |
Low |
Medium |
High |
|
UI richness/interactivity |
High |
Low |
High |
Low |
|
Ease of development |
Low |
Medium |
Medium |
High |
|
Security |
High |
Medium |
Medium |
Low |
|
Ease of application update and maintenance |
Low |
High |
Low |
High |
|
Ideal for high transactional volume |
Y |
N |
N |
Y |
|
Ideal for data transactions that are large in size (example : file attachments) |
Y |
N |
N |
N |
|
Ideal for complex input data (example : forms involving multiple field input) |
Y |
Y |
Y |
N |
|
Ideal for complex data input methods (example : digital signatures, barcode scanning) |
Y |
N |
Y |
N |
|
Application data latency |
|
|
|
|
|
Support for different operating systems/devices |
|
|
|
|