As most things happening in a TouchUI app, the action begins in the main form (MainForm), and that is also true for the painting of all the graphics. To take full control over how the graphics is drawn in an app, the form's OnPaint method should be overridden, like this:

The Common.Instance is a singleton used to store global things in the app, and is hold the current screen dimensions (ClientRectangle). It also holds an instance of the GDI Graphics class (PaintGraphics) pointing to a bitmap (PaintBitmap) that is used to draw to the screen (via e.Graphics). The bitmap is used as a buffer instead of doing the different GDI painting operations directly to the screen, and that is a good practice (called "double buffering") that will help you avoid things like screen flickering. Another important measure to avoid flickering is to override the OnBackGround like this:

Note that I don't call the form's (base class) implementation (base.OnPaintBackground).

So, we have a way of making the currently active dialog responsible for the painting of the screen, and this is an example of the Paint method of the main dialog:

This code takes care of painting (clearing) the background, the heading text, and the horizontal line below the heading. The result looks something like this:

As we will see in some of the upcoming parts of this series, the dialog continues to pass the responsibility of painting to each of its controls, that does their work in much the same way.

One of the hardest parts of writing apps for CF is the handling of the different forms, and also the navigation between the forms. The handling involves loading the forms (that takes time), showing the forms (and hiding the other forms to prevent strange behavior when switching between apps), and the memory management of forms (especially if they contain many controls, they use a lot of memory). After years with different form handling solutions (stacks with preloaded forms, etc), I finally decided to leave all those troubles behind by only having one form in my apps.

The single form in my TouchUI apps is usually called MainForm and even if it's not a part of the framework, it's really the main controller for the user interface. That is where initialization takes place, and all the events are fired in that single form. Each event (or overridden method) then gets passed on to the currently active dialog. A dialog is a TouchUI class that represent a logical form in the app, and the MainForm host a stack of currently loaded dialogs to ease navigation back up the dialog hierarchy. This is the first code (in the form's Load event) that runs when the app starts:

As the dialog stack is a simple List, most of the other code in the MainForm will access the currently shown dialog with:

Here are some examples:

The last code snippet is from the logic that navigates from the main dialog to a new dialog, and as you can see it resembles the initial code above. Therefore, moving up the hierarchy means to simply remove the last dialog in the stack (list).

The technology that makes the main requirement for the TouchUI framework (see part 3) come true is GDI, which also has a managed wrapper. The main player in that API is the Graphics class, and here are a couple of its methods:

• Clear()
• DrawEllipse()
• DrawImage()
• DrawLine()
• DrawPolygon()
• DrawRectangle()
• DrawString()
• FillEllipse()
• FillPolygon()
• FillRectangle()
• MeasureString()

This is actually most of its methods, but still this is all we need to create any graphics that we want. Also, since it's not that extensive, it's not too difficult to learn GDI. Here's some code:

Let's not bother with how the graphics instance (g) is created, and assume it is, then the result would look something like this:

That's what I like with GDI: get whatever graphics you want with just a few lines of code! In the coming posts in this series I will not explain the details about the different GDI methods used, but there are many good resources to find on the Web if you want to learn more about GDI.

GDI is actually the way that the core operating system (Windows CE) is drawing things to the screen, and if you are interested in knowing more about how this technology performs on a device, you should check out the article Native vs. Managed Code: GDI Performance by Chris Tacke. As you will see, there are some performance gain to be made by calling the native APIs instead of using the managed wrappers. But since I had a goal of pure managed code for the TouchUI framework, I will stick with the managed wrappers in this series.

Let me start by presenting some of the things that I wanted from a simple framework for building nice looking user interfaces on WinPhone:

1. Be able to do whatever I want (i.e. no graphical restrictions)
2. Run on all devices with WinMo5 or later (incl. WinPhone 6.5)
3. Run on all touch and non-touch devices
4. No dependency of third-party products (Resco, miraByte, etc) or even libraries (GapiDraw, etc)
5. No multi-form problems (task switching, etc)
6. Support for any resolutions (from 176 x 220 all the way to 480 x 800)
7. Support for any orientation (portrait / landscape)
8. Soft (kinetics) scrolling with a finger (multi-touch is simple not possible with the current hardware)
9. List item selection (with highlight coloring according to current theme)
10. Form switching animations (left / right)
11. Ability to recognize simple gestures
12. Pure managed code (based on CF 3.5)
13. All of the above with with a single code and executable!
14. Easy to understand and use (i.e. few lines of code)

For an experienced CF developer, this list seems like very high expectations, but I will talk about each of the items in the list and show how it can be implemented.

Just to give you an idea of where we are heading, there are some screenshots of the TouchUI sample application (both the sample application and the TouchUI framework can be downloaded from the CodePlex project named TouchUI):

The first is screenshot is from a traditional non-touch device (WinMo 5 Smartphone with a 176 x 220 screen), and the second and third are from a new high-res device (WinPhone 6.5 Professional with 480 x 800 screen). The beautiful strawberry graphics is from a photo by Tina Phillips / FreeDigitalPhotos.net.

However, the best features are not visible in screenshots, e.g. the nice soft (kinetics) scrolling, and form switching animations. To better understand the user experience, I recommend you to download the code and load it up on a physical device. I hope you will enjoy it!

When I was involved in starting up a mobile cross-platform project a few months ago, one of the goals was to make the experience between the platform as similar as possible. Not surprisingly, the platform that set the standard was iPhone, and the other platforms had to do as best they could to measure up. My main responsibility was the WinPhone platform, and it didn't take much analyzing to realize that old friends like the ListView and the Grid were out of the question. So I went out to look for what others were doing.

I started by looking at Alex Yakhnin's UI Framework, and was (as usual) impressed with the things that Alex can do with the standard controls. Just take a look at the ListBox on the right.

It was when I started to play around with it, and added a few more items in the list, that I was instantly put off when the classical scrollbars appeared in the otherwise nice control.

Even if there are many things to pick from the framework, like how to draw alpha-blended bitmaps in various ways, I wanted something that was not built on the native controls.

So I moved on to the MobileForms Toolkit from Resco, and even if I like what they are doing with many very nice controls, I wanted to have full control of the layout which ultimately require that you have the source code.

The same goes for Touch Controls Suite from miraByte which has some nice controls for scrollable lists with navigation. They are still working on the designer support, but is a nice alternative if you want to get going fast.

The thing I found that came closest to what I was looking for was the Fluid Controls by Thomas Gerber. The sample application was successfully designed to look very similar to the iPhone. It had many of the nice features, like the scrolling lists, animations, etc, but still there was two things that I was missing. First, I wanted something that conformed more with the design guidelines of WinPhone, like the use of the soft buttons (menus), form headings, etc. Second, the implementation was quite extensive, and I was not interested in learning an extensive codebase in order to build a nice user interface.

In the next part of this series, I will show you how I start on what would eventually be the TouchUI.

I started programming for Windows Mobile (Phone) even long before it was called that, even before it was called Pocket PC, and that was back in 1998 (it was actually called Palm PC at the time). I was amazed at the fact that my programming skills from the Windows platform was brought to a device that I could carry in my pocket. It had the same user interface controls that I was used to, and life was amazing.

Now, more than 10 years later I'm less amazed by using almost exactly the same controls in my mobile applications. A lot has happened in this time, but unfortunately this has not been reflected in the set of control that I have to my disposal. I know that many of my friends and fellow mobile developers have tried various ways of tweaking the existing controls into doing things that they were not meant to do. Some built new controls from the ground up, only to find that this they still didn't get all the way to were they wanted.

In my view, one of the more important things that iPhone brought to the table was a new set of controls that were designed specifically for mobile use. They were designed to be both easily controlled with a finger (or even multiple fingers at the same time) and good looking. Taking it one step further, they even added some fun (kinetics soft scrolling, sliding animations when changing views, etc) to the experience which has been really well received by the users. Recently, like in the latest version of Windows Mobile, or rather Windows Phone, WinPhone 6.5, some of these things have been made available in parts of the operating system. However, not much has changed in the tools available to us, the third-party developers, and especially when it comes to the controls.

I hope that will change soon, and that we will see a completely new set of controls for WinPhone designed with modern mobile user expectations in mind. It's probably not enough with just some of the enlargements to make them more finger-friendly that we can see in WinPhone 6.5. No, it needs to be a new set of controls that are designed for fingers that has a nice look, and even a bit of fun.

While waiting for that, I have put together a very simple (according to the KISS principle) framework called TouchUI that include some of the ideas I've been missing in the controls for WinPhone. But before we look more closely at it, I will look at some of the alternatives in the next part of this series.