Application Architecture Archetypes

Application architecture whether it is for mobile, server or desktop application can be broken into 3 major archetypes - standalone, connected and occasionally connected. Each has a long history and many implementations. Lets look at how these architectures can be implemented in the mobile space.

Before I look at these architecture I would like to define mobile. Typically when I talk about mobile applications I mean phone or PDA type device. However a laptop or tablet can also be a mobile device. This is especially true when talking about computers connected via WiFi or even CDMA/GSM based modems. The major difference between a computer vs a device is the constraints on the device. In today's world and for the foreseeable future devices are more constrained than there large computer cousins. So when you see device, laptop, computer etc. are being used interchangeable.

Standalone Applications

Standalone applications are exactly an application that can run on the device without any other requirements or resources. The classic example would be a "Hello World" application. I install the application and I do not need anything else to run it. In addition, the other two archetypes or based on standalone architecture.

Todays application typically look like the diagram below. It is composed of a presentation layer, application layer and finally a data layer. In addition some services cross these three main layers for example error handling and security.

In the early days of network technology to enable these standalone application access to network resources OS developers made network resources look local. So early versions of Microsoft Word could save to the network because the shared network location looked like a local drive. So while Word at that point is technically no longer standalone, it is not exactly network or connected aware.

With the .Net and Compact Framework you can build standalone applications. These applications can be as simple or complex as you like.

The benefit

• Can run anywhere and anytime by its user as long as the device can operate.
• The application can be written with little regard to its environment i.e. it can assume that it is the only thing running, does not need to manage fragile network connections.
• Rich user interface.
• Overtime the application can approach near zero defect since the application is self contained. In addition, the most probably source of error is a combination of user input or sequence of interactions that developers had not been foreseen.

The negatives

• Self contained the user has limited interaction with network resources. A good example is Car Navigation systems. To update the map or show newer locations require an update of its map which can be complex for example my wife's navigation is about 6 years out of date and requires the dealer to replace the DVD since it is not easily accessible. This typically means that data is stale to some degree.
• To update the application requires user intervention or some other process.
• A rich user interface can approach a near infinite combination of interactions and input which makes it impossible to test every combination.

Connected Applications

The first connected application basically put the application layers on different physical computers. So for example moving the data layer to a separate server or pushing out the presentation to the user computer. This first version was called client/server since the application was broken into two parts a client and server. A classic example is the Web it is composed of a browser which is the client and a web server. Depending on what ran the client you had a so called fat or thin client.

A thin client is typically a web page delivered to the browser. Then any application logic is done back at the web server or more sophisticated clients use a web service or REST. The latter is know by the acronym AJAX.

With the .Net Framework, ASP.Net and the Mobile Internet Control Toolkit you can build thin client applications. These applications can be as simple or complex as you like.

The benefit

• Can support many different devices not just Windows Mobile
• No deployment to the device
• Scale is achieved by increasing central systems
• Web based applications tend to be robust since user interactions limited (note I am not talking about AJAX)
• Overtime the application can approach near zero defect since the application is a web page with known user interactions and sequences

The negatives

• Always requires a connection and so no airplane mode
• Scaling requires greater back-end infrastructure and server management becomes very important
• User interface is typically not as rich since HTML has limited controls this includes AJAX
• Browser functionality is not consistent across all devices

A fat client on the other hand has a more complex client that might include application logic as well as data. The only portion that might be on the server would be the database. In the mobile world fat clients consist of Compact Framework application communicating to a web service or REST.

The basic architecture would look similar to thin client however the client side application now takes on more of the stand-alone architecture on the client. The standalone architecture is augmented by network connectivity based services.

The benefit

• Rich user interface.
• Can run with limited functionality anywhere and anytime

The negatives

• To update the application requires user intervention or some other process.
• A rich user interface can approach a near infinite combination of interactions and input which makes it impossible to test every combination. In addition fragile connectivity and many device types make it impossible to approach zero defect.

Occasionally Connected Applications

The occasionally connected application is similar to the fat client application. The difference is the application is designed to work even without a connection. A good example is Outlook. Outlook can work even when no connection is available. For most application this means creating some mechanism to retrieve and cache data from network data storage. This can be done using web services or some kind of sync service like SQL Server Merge Replication.

In addition data can be pushed to the clients. With the new .Net framework 3.5 it can be accomplished using Exchange and the store and forward communication mechanism of WCF. This allows for pushing information  or signaling the application to perform an action. This adds an additional services to the device side client.

The benefit

• Rich user interface.
• Can run with full functionality anywhere and anytime
• Connectivity code isolated and thus easier to manage and build solid error handling

The negatives

• To update the application requires user intervention or some other process.
• A rich user interface can approach a near infinite combination of interactions and input which makes it impossible to test every combination. In addition many device types make it impossible to approach zero defect.

Conclusion

In today's environment architectures are much more complex. A complete mobile architecture should at a minimum include

• Device Management - inventory devices, push out updates, manage devices by user group
• Email - push email
• Unified Messaging (I'M, VIP) - handle messages like I'M and Voice over IPA