“Have you done any Windows Mobile development?”
“A tiny bit. Isn’t it just like Winforms but on a phone?”

And from such an innocent beginning, a world of pain did explode into my universe. Just like Winforms on a phone is it? What’s the difference between the Compact Framework, Smartphone development, Pocket PC development, Windows Mobile? So many terms! So little time!

Windows Mobile is the operating system, just like Windows Vista. The Compact Framework is just like the .NET Framework on the desktop. As for the difference between a Smartphone and a Pocket PC, well, you’ve got me there. I picked Smartphone because my device had phone functionality and it seems to be working so far. There are separate SDKs for each, so I assume there are some key differences which escape me. With Windows Mobile 6, the Smartphone and Pocket PC SDKs are now Windows Mobile 6 Standard and Windows Mobile 6 Professional, respectively. I think.

Actually I think the real difference in these is the templates for projects you create and the emulators you are provided with. Professional, or Pocket PC, provides emulators for bigger screens. Microsoft has this to say about the naming kerfuffle:

With Windows Mobile 6, we are revising our SKU taxonomy and naming to better align our brand and products with the realities of today’s mobile device marketplace. The historical form-factor based distinction between Windows Mobile powered Smartphone and Windows Mobile powered Pocket PC Phone Edition is blurring dramatically. We want our taxonomies and terminology to evolve to better reflect the evolution of the mobile device industry.

So in order to reflect the blurring of the mobile device form factors, they’ve changed from having SDKs named after the types of device to SDKs named “Standard” and “Professional”. Hmm. How about having a single SDK called “Mobile Device SDK” and allow me to pick the device dimensions from within my project on the fly? Back at the start of this tale, I assumed that picking Windows Mobile for development would allow us to target a range of different devices, large and small, and in fact I can do that. I can deploy my application to a Windows Mobile phone with a big screen and to one with a small screen. The SDK split seems pretty artificial with that in mind.

Naming conventions and confusions aside, it is nice to be able to write against a single API and deploy to any Windows Mobile device. Or it would be if it worked.

My bugbear here is with a particular class: CameraCaptureDialog. Take the Samsung Omnia for example. You can certainly pop up the camera using CCD.ShowDialog(), but can you retrieve the filename of the image you took? You cannot. That’s because the Omnia’s camera supports taking multiple images one after the other until you explicitly close it.

How about the HTC Diamond? Well that opens fine, and returns a filename too, but if you try and re-open the camera straight after processing the filename, to allow the user to take another photo, it fails silently and doesn’t show the camera. If you try and do the same thing with the HTC Touch, it freezes.

Part of the issue is that the Compact Framework leaves too much up to the manufacturers and doesn’t give enough control to the developer. We can set the resolution of the camera for example, but we have no shortcut of setting it to the maximum resolution available. If you try and set it to a resolution which is not supported, some devices reset silently to a much lower resolution.

Microsoft need to extend camera support for .NET developers and give a lower level of access. They need to push device manufacturers to adhere to the Windows Mobile APIs and be more precise in how they are specified. And they need to simplify and modernise their mobile development framework so that developers can be fully aware of all the options available to them.

There are a load of different tool “families” in use in the .NET ecosystem which I’m sure LosTechies readers will take advantage of pretty much every day. IoC containers. Logging infrastructures. URL routing mechanisms. Each of these families operate on broadly similar principals – taking the container example, we know that we need to add types to the container and resolve types which are already in there. For logging, we’d generally have the ability to log to different levels of severity. So you can see that while the implementations and underlying behaviour may be significantly different, there is a layer of abstraction which highlights commonality.

Castle Project has a Castle.Core.Logging.ILogger class which supports the use of a variety of different logging systems within your applications. It is a facade behind which log4net or NLog does the magic while your application happily logs information while not worrying about what is actually taking care of the logging. To me, this is a very interesting method of supporting a tool family – expose the most common methods which a tool supports and let the tool get on with its own business.

What I’d like to see is a community effort to publish an ILogger interface to which various logging libraries can adhere, and an IContainer interface for IoC libraries, and other interfaces for various tool families which have enough common features. In this way, we can enable a new level of code sharing and integration between projects.

(also published at my LosTechies blog)

In my last post I discussed code reuse in the form of an abstract CrudController class: a means of providing create, read, update and delete actions for a given entity. In addition, that class provided the ability to work with an entity specification class to allow for filtered reads – which is just another name for search results.

I’m going to show C# code samples for building with a class like this, but you’ll have to fill in the gaps in terms of how you can work with it. The code to list entities is the most interesting and will demonstrate the concept best, so I’m going to focus on that. To begin with, let’s assume a very simple entity:

public class Post
{
	public DateTime CreatedOn { get; set; }
	public string Headline { get; set; }
	public string Body { get; set; }
	public string Username { get; set; }
}

So, to begin with we’d like to list Posts. A typical method to do so would be:

public void List()
{
    PropertyBag["posts"] = PostRepository.FindAll();
}

But remember that in my case, I’m trying to create a reusable method of doing this, and that I’m also going to be working with ExtJS which is going to consume JSON. So, I have the following class:

public abstract class CrudController<Entity>
{
	private IRepository<Entity> _repository;

	public void GetJsonList()
	{
		RenderText(
			JsonHelper.Serialize(_repository.FindAll())
		);
	}
}

public class PostController : CrudController<Post>{}

I need a shell PostController, but most of the action is happening in the CrudController, and I’m using the magic of Windsor and generics to make it happen. By passing Post as a type parameter to CrudController, Windsor will then give me the correct IRepository<T> to work with, and from there it’s a simple matter of fetching the list of Post Entities in the same way I did in the previous code sample. I want to get a JSON string back, so I’m passing that list to a helper to serialize to JSON.

The next step is to make this listing method a bit more flexible and a bit more powerful. I want to do a couple of things – paging, sorting, and searching. Here’s my new method signature for GetListJson:

void GetListJson(int start, int limit, string sort, string dir, EntitySpecification spec)

The arguments “start” and “limit” are for paging, saying which record I should start from and how many I should return. The “sort” argument tells me the column I should sort on, and “dir” gives me the sort direction. But what about EntitySpecification? Let’s show it in context:

public abstract class CrudController<Entity, EntitySpecification> where EntitySpecification : ISpec
{
	private IRepository<Entity> _repository;

	public void GetJsonList(int start, int limit, string sort, string dir, [DataBind("spec")]EntitySpecification spec)
	{
		spec.AddOrder(sort, dir);
		spec.FindAll(_repository, start, limit);
	}
}

public class PostController : CrudController<Post, PostSpecification>{}

As you can see, EntitySpecification is databound by Monorail; incoming parameters are passed to the specification to build up a criteria for querying, as described in Ayende’s search specification post. That means that I don’t have to explicitly handle searching in my CrudController at all, because it’s all handled by the EntitySpecification. A sample PostSpecification could look like this:

public class PostSpecification : ISpec
{
	private ICriteria _criteria;
	private string _username;

	public virtual string Username
	{
		get { return _username; }
		set {
			_username = value;

			if (value == null)
				return;

			_criteria.Add(
					Expression.Eq("Username", value)
				);
		}
	}

	public void AddOrder(string sort, string dir)
	{
		var order = (dir == "ASC" ? .Order.Asc(sort) : Order.Desc(sort));

		_criteria.AddOrder(new Order());
	}
	public IList<Post> FindAll(IRepository<Post> repo, int start, int limit)
	{
		repo.Find(_criteria, start, limit);
	}
}

When Monorail runs the databinder, the Username property’s getter will be called and the private criteria will be altered. When the specification’s FindAll method is called, that criteria is passed through to filter the returned records.

Let me know if you have any improvements or suggestions, and thank you again to Ayende for the specification ideas.

I’ve previously talked about my dislike for code generation in Javascript. I still standby that, but I am beginning to have a change of heart for certain scenarios. I’ve been working on a couple of ExtJS applications recently and I’ve got lots of code which is purely ExtJS stuff on its own – no HTML or other code in there really. It’s been a project where I’ve been using C# 3 and it’s partly the similarities between the two languages which have triggered this rethink.

Take a look at this code:

var win = new Ext.Window({
	title: 'Order Viewer', layout: 'border',
	width: 500, height: 500,
	modal: true, resizable: false, closable: false, draggable: false,
	items: [ frm, lst ]
});

win.on('render', function() {
	load(5);
});

win.show();

That’s pretty standard stuff for what I’m doing with Ext right now – I create a new window with a load of configuration options, then add in an event handler for the window’s render event, and finally show the window on screen. Now imagine that you could write the following in C# 3:

var win = new Ext.Window{
	Title = "OrderViewer", Layout = Layout.Border,
	Width = 100, Height = 200,
	Modal = true, Resizable = false, Closable = false, Draggable = false,
	Items = new [] { frm, lst }
};

win.Render += delegate {
	load(5);
};

win.show();

As far as I’m aware, all of the above is valid C# 3 code. I’ve basically written it as I’d like to use it, with an enum for the Layout type, and C# style event handler syntax, but the interesting thing to me is how very similar it is to the Javascript version.

The ExtSharp project allows you to write your Ext code in C# and have it rendered as Javascript. I’m going to explore it in my next post, and examine how closely it can be made to fit the code sample above.

It surprises me that no-one offers a web-based build server – specify your source control connection details, set up a couple of tasks (build, test, report) and hit “go”. Is there some obvious problem with this idea that I’ve missed?

I want a build server but I don’t want to have to maintain the install or faff around with configs. I’ve tried TeamCity, which seemed ok, but the interface wasn’t great and it doesn’t support MbUnit.

I’ve started using Beanstalk for Subversion hosting, and it works very well indeed, so maybe that’s what’s got my thirst for web-bases apps going.

For a while I’ve been meaning to come up with a repeatable starting point for my projects. Not only is adding references, configuration and structure to a solution labourious, it’s also pretty difficult to remember every step. Ideally, I wanted to be able to start a project with everything ready for me.

I spent a while today doing just that; a solution which matches the starting point for most of my projects. Firstly, there’s a Monorail project with Windsor, NHibernate and logging integration switched on. All of the required DLL’s have been moved into a Libs directory in the solution folder – the idea behind that is to allow a developer to be able to build the project without needing to install Monorail or any other components. Secondly, there’s a unit tests project with a couple of folders; Controllers and Persistance. These suggest a future structure for this project, with Persistance being used to check the NH mappings work as expected. In addition it contains an NHTestBase class which allows my unit tests to run with a SqlCe database. Thirdly, a project called Core; this holds core functionality for the solution, such as entities and services, exceptions and utility methods.

The whole thing can be found here: http://dev.plastiscenic.co.uk/svn/projects/Plastiscenic.Sample/ but it’s missing one thing – a good way to customise it. Namespaces, directory names, etc, need to be manually changed. For me that’s still better than building it up from scratch but it’s still a pain. If anyone’s got any suggestions, I’d love to hear them.

One final note; this has pushed me to collect together a couple of classes I use often, and I’ve stolen Ayende’s naming convention by creating Plastiscenic Commons. This contains a repository implementation, stuff for setting up a SqlCe database, a static container accessor, and a few other bits. Nothing exciting but I always need them.

Feedback appreciated.