This time we will look a little closer at an important change on the user interface side of the architecture. I'm talking about applying the MVC pattern (or rather its variation, the MVP pattern), and even if this change is far from recent (both mentioned patterns have been around for quite awhile), the importance of applying this pattern has increased. The reason is an increased focus on automatic testing, TDD, and continous integration. By applying the MVC pattern, the bulk of the logic of the user interface (located in a "controller"), can be tested independent of the actual user interface. This, and the more traditional benefits, that you can apply different "views" (user interfaces or more general, channels) to the same user interface logic, makes the MVC pattern a common part of any modern software architecture.

If you do some browsing on the Web, you quickly find that there are many implementation of the MVC pattern, but there are not that many specific to Windows Mobile developers (although most .NET implementations should migrate without much hazzle). One great initiative was the MCSF by Microsoft's patterns & practices team, which included a solid implementation of the MVC pattern (among many other) that was migrated from various application blocks for the full .NET Framework. However, the MCSF was so solid that it took a great deal of time to learn before you could be productive. Also, the MCSF is now a bit outdated, and judging from the lack of news or updates about it, my hopes are not up.

The community (and me too) wanted something simpler, and in some projects, I have used a very simple and straightforward implementation by my former fellow MVP, Alex Yakhnin (he's now employed by Microsoft), that he published as a small blog series last fall (see part 1 and part 2). In those blog posts Alex also showed a simple solution to a very common problem when building great UX for Windows Mobile, and that is to handle the caching of forms. Loading a form is an expensive task in terms of performance, and therefore it's necessary to cache the forms in memory.

In upcoming posts, I will continue with more of my thoughts on the changes in mobile architecture, and of course also some code samples to show the theory in practice.

I'm continuing the series that started with part 1 and part 2 by talking more about the changes in a modern mobile multi-tier architecture. We can see that the most important changes are happening on two levels, and the first is the tighter bond between the business logic and it's data that I talked about in my previous part in this series.

As I already mentioned in the previous post in this series, the second major change to the classic Application Architecture for .NET that you see on the left is the change in the way that clients exchange information with the server (or more general, the way that two systems or peers exchange information). As soon as Web Services arrived, we instantly understood that this would be the future way of communication between systems. At the time when we wrote our book, the basic plumbing wasn't in place, and most had to be done by hand. Since then the basic Web Service technologies (XML, SOAP, HTTP, etc) has been complemented with both new exiting ones to enable better support for security, sessions, transactions, etc, as well as much better tools support. The beauty of Web Services is that they can open up a "locked" architecture (that can only deliver a fixed UX, like most Web sites on the Internet) to any client. That client could be anything from a custom made application to another system that simply want to use only the services and the data. This is what my series on Windows Mobile Web Services (e.g. Movie Lookup Web Service) is all about. Most of you probably agree that cool sites like IMDB, and FlightExplorer become even better when they can participate in a mash-up application to deliver greater value.

One technology that is important in this change is WCF as it builds on the good things about Web Services, and also takes the concept one more step. It's what .NET Remoting should have been in the first place, and even if it can be confusing as a consequence if its versatility, the main message is that you can do everything that you can do with Web Services and so much more (and it also performs very well). Therefore, my recommendation is to take a hard look at this technology and evaluate if it brings something that you need in your mobile applications. Just to make you more interested, it can travel over a number of transports (HTTP, TCP, Named Pipes, MSMQ, etc). However, not all of these transports are supported out-of-the-box on .NET Compact Framework yet, but a great thing about WCF is that it can be extended on multiple levels (transport, bindings, etc). What is supported though, is the ability to solve a classic problem with mobile applications: How can I communicate efficiently with a device that may be shut down and that is very hard to address (changing IP addresses, etc)? It's possible using the WindowsMobileMailTransport class that allow messages to be sent as e-mail. In combination with Exchange Server, and it's push e-mail technology (a.k.a. DirectPush or Always-Up-To-Date), this means that mobile application can be built that communicate very efficiently with the server (or another peer).

In upcoming posts, I will continue with more of my thoughts on the changes in mobile architecture, and of course also some code samples to show the theory in practice.