One important feature in most mobile store apps is the ability to show images of products (or services). In most cases, it's not possible to store all those images on the mobile device. It could be because products are added or removed, that the images change over time, or that they would simple take up to much space in the device's memory (or even on a storage card).

A possible solution to these problems would be to get the images on demand over the network. But even if the image size was kept to a minimum, most wireless connections (especially if you are out of 3G coverage) wouldn't be able to deliver the images fast enough to create a responsive user experience. The solution could be to show a temporary image at once, load the images on background threads, and replace the temporary image when the downloads is complete. That is what I will show you how to do here.

When the image is first shown, which could be in the list or detail dialog, code similar to the following is run:

If the image is not set, it's the first time this image is to be shown, we start by loading a dummy image while the real image is loading. Then we start a background thread to load the image, and it's code look like this:

The download of the image is started, and when it's done, the image is set and the background thread ends. The actual loading of the image from an URL looks like this:

Just a simple web request with the resulting stream directly used to create a bitmap image.

While the image is loading, the Paint event will do something similar to the following:

The locking of the image variable is necessary to avoid thread concurrency problems, and we are also adding a text to the dummy image while the real one is loading.

This simple technique can be used in many situations to increase the user experience.

Now we have come to the client implementation part of the mobile store architecture, and the first thing to do is to create a connection (proxy) to the service. To do this, make sure you have the Power Toys for CF or, if you are running Vista or Windows 7, you should get your copy of the NETCFSvcUtil utility here. Take a look at this blog post on the details of doing this. All the code can be found in the CodePlex project for this series.

As we now have a connection from the mobile client to the server, the next step is to do the actual implementation of the user interface of the mobile client. I therefore recommend you to read through the various blog posts related to the ToucHUI framework. Most of what is implemented in the mobile client of the mobile store is covered in that series, and there are just a few additional features that I will talk about in the rest of this series.

Let's continue with the implementation of the mobile store architecture, and now it's time for the middle tier with the business domain logic as well as the actual WCF service. Here is a screencast of me doing that:

If you prefer, you can also download the screencast and watch it offline. All the code can be found in the CodePlex project for this series.

It's time to start the implementation of the mobile store architecture, and I will start with the server side. More specifically, I will start with the data services tier, and here is a screencast of me doing that:

If you prefer, you can also download the screencast and watch it offline. All the code can be found in the CodePlex project for this series.

A solid design always starts with a solid architecture. The architecture used for this app (series) is the KISS Architecture, and it builds on the collective knowledge in the developer community. It's a classical three tiered architecture on both the server and on the device:

Hopefully, this picture is not revolutionary to anyone, and it makes the best use of the latest technologies on the Microsoft platform:

• .NET Framework - the treasure chest
• C# - my language of choice
• Visual Studio - the worlds greatest development tool
• SQL Server - my database of choice (on both server and device)
• ADO.NET Entity Framework and LINQ to Entities - the way forward on ORMs (for the ADO.NET team)
• ADO.NET Data Services - how to make (REST) data access loosely coupled
• WCF - on discussion, this is the RPC of our time
• .NET Compact Framework – the mobile treasure chest
• Windows Phone – the premier platform for .NET

With this architecture in place, our app is ready for multiple deployment scenarios, and it's especially suited to be deployed in "the cloud".

In the next part, let's get started in implementing this architecture.

I think that one of the hot app trends of 2010 will be companies extending their product and/or services to "anyplace". When I read about the success story of PizzaHut's iPhone app sales, it makes me think of all the companies that haven't yet made their presence in this most lucrative channel.

The first generation mobile apps was about proving it could be done, and we proved it a number of times. Now, it's time for the next generation apps where the main achievement is making it right. I mean, how should we build mobile apps in the right way, with the right architecture, and making sure that they reach the customers not only on a practical, but also on an emotional level. How do we create apps that are both beautiful inside as well as outside?

My take on that is building on a solid architecture, the KISS Architecture, adding an appealing user interface, the TouchUI framework, and putting together something that can be reused. I finally settled for an app where you could buy used cars that looks like this:

In this series I will walk you through building this app from the ground up. I will start with the server side with the core data, and the build my way through data service, business logic, a service, and all the way to the mobile app with a nice user experience.

Come along, and I hope you will enjoyed this as much as I did putting it all together.

This is the final post in this series, and for a complete reference, here are the previous parts:

• Part 1 gave some background
• Part 2 looked at some of the alternatives
• Part 3 was a general introduction
• Part 4 gave an introduction to GDI
• Part 5 promoted one form and many dialogs
• Part 6 showed how the painting is done
• Part 7 discussed how to build an active UI
• Part 8 started the walkthrough of the controls
• Part 9 covered the ScrollControl base class
• Part 10 talked about the ScrollList control
• Part 11 was about the ScrollPanel control
• Part 12 demonstrated animated navigation
• Part 13 showed how to be resolution/orientation aware

The TouchUI framework is published on CodePlex in a project called TouchUI, and this means that you can access the full source code as well as discuss it, come with suggested improvements, etc.

On the upper right you see the UX of the sample included in the code, and it's a beginning of a simple shopping app that allows for scrolling through articles (in this case only strawberries) and then touching them to see more details.

Even if this series is complete, I will probably continue to build further on the framework, and any suggestions on things to add are most welcome. Any other feedback, for that matter, is also welcome!

As I have shown in several places in the previous parts of this series, the painting of things is always related to the bound of the current item (dialog, control, etc). This approach is essential to handle the quite extensive number of resolutions on WinPhone. That's especially true if you want to support all phones since WinMo 5, and even the non-touch devices. Another important reason is the fact that many devices with non-square screens allow the screen to be rotated between portrait and landscape mode.

The magical event that tells our app about the resolution and any change in orientation is the Resize event, and in the TouchUI sample, the code looks like this:

The working area of the screen (excluding the title and menu bars) can be retrieved from a static method (PrimaryScreen) on the Screen class (in the System.Windows.Forms namespace). We save that in our app singleton (Common.Instance) and use it to inform all dialogs about the new dimensions.

Each dialog can adapt to the new resolution or orientation, and this is the code in the main dialog:

It simply update the bounds of its ScrollList control, that in turn will adapt by using the new dimensions in its Paint method. With these simple measures, the app can run on any device with the same code and even the same executable. Here are some different resolutions and orientation examples...

...and they all have their original resolution in the following order (width x height): 176 x 220 (non-touch), 400 x 240, and 480 x 800 (both touch). The beautiful strawberry graphics is from a photo by Tina Phillips / FreeDigitalPhotos.net.

Now we come to one of the nicest additions that the TouchUI bring to the table - the animated navigation. This is, as so many other things in modern mobile user experience design, inspired by the way things work on the iPhone.

When the user select an item in a list (in a dialog), the following code is run in the main form:

As you may remember from the painting part of this series, the PaintBitmap (in the app's singleton class Common.Instance) is used to do all the painting in the app. Then, it is used in the OnPaint method to do the actual painting to the screen. The first thing that happen in the code above, is that a copy of the current screen is made (into the PaintCopyBitmap that is pointed to by PaintCopyGraphics). The navigation is done (the details form is added to the dialog stack), and then the animations horizontal start position (animationLeft) is set along with the offset to move the new screen into place for each frame (animationOffset, in this case it's in four steps making the animation take about a third of a second). The navigation backward (up the dialog stack) is done in a similar fashion, but then the animationLeft and animationOffset are both negative. Btw, the beautiful strawberry graphics is from a photo by Tina Phillips / FreeDigitalPhotos.net.

With this in place, the actual painting is done in the OnPaint method, and it looks like this:

First, the dialog is painted (updating the PaintBitmap with the new content), and then both the old and new bitmaps are painted according to the step in the animation (controlled by animationLeft). When the animation is complete (animationLeft is zero), only the new dialog is painted.

A similar approach is used for the switching of images in the detail dialog in the sample, so be sure to check that out as an example of responding to sweep gestures.

Another controls that inherit from the ScrollControl (described in a previous part of this series) is the ScrollPanel control. As the name implies, this is a panel that implement modern features like soft (kinetics) scrolling, and the design and functionality was inspired by the scroll view control on iPhone.

The ScrollPanel itself does not implement much logic, it mainly functions as a way for the app to implement a scrolling panel. In the TouchUI sample app, that is done in the DetailScrollPanel that inherits from ScrollPanel (and in turn from ScrollControl). The painting of the panel is done like this:

It draws the image at the top, and some Latin text as the bottom, and note that the use of the control's placement and size (Rectangle) will make both the image and the test resize with the screen. Dynamically that useful when switching between portrait and landscape, but it also means that different resolutions on different devices are handled.

This simple setup provides for full controls while still allowing for any use of the panel area. It could be of any height, and it could include any number of items. Although not included in the sample, it could also include traditional WinForms controls to allow input (text and combo boxes).