Microsoft patterns & practices Summit 2009

Microsoft are hosting the patterns & practices Summit Oct 12th - 16th 2009 at the Microsoft Conference Centre on Microsoft Campus in Redmond, WA.

To learn more about this event, see here: http://msdn.microsoft.com/en-us/practices/dd578307.aspx

Microsoft Architect Insight Conference May 8th 2009 Mobile Decks for download

As promised to the delegates at the recent Microsoft Architect Insight Conference held on 8th May 2009 at Microsoft London Victoria, I have uploaded the decks from my breakout which was presented with Dave Baker from the Developer and Platform Group at Microsoft and my interactive session for download.

The two decks were used in the sessions Extending the Enterprise through Mobile and Mobile Implementation Patterns. Please note: the interactive Mobile Implementation Patterns deck is very light and the session was very much a chalk and talk session. I opened it up for debate for just about anything mobile. This deck contains some information about Hitachi Consulting who we are, our clients we've worked with which may interest you.

Thanks to Dave for giving a great session and also thanks to all the delegates in the interactive who made it a good discussion session.

You can download the decks here.

Copying dependency files to the output directory when running unit tests with MSTest

A rather long title don't you think :) But have you ever wanted to write a unit test using Visual Studio Test Edition and MSTest to have a dependency on configuration files other than app.config to fulfill your test?

This post is mainly about test support for device testing but is the same for desktop testing too.

Now, most people use app.config as a configuration file in .NET for desktop applications. On devices, System.Configuration is not supported. So some device developers end up writing there own configuration reader by serializing the XML into an object. Alternatively they use the class from OpenNETCF SDF or they might parse the XML using LINQ to XML or plain old System.Xml.

Personally I tend to use the serialization option. My configuration files are not named app.config I tend to name them something more specific. You'll find Visual Studio or the test engine does not deploy any other file to the tests Output directory, even if you set properties Build Action to Content and Copy to Output Directory to Copy always. Running your test will fail if you have a dependency on the given configuration file as Visual Studio will not deploy the custom configuration file. It is highly likely most desktop developers have never seen this or unaware this limitation exists because most desktop devs use app.config. In most cases for desktop devs there is no problem.

So how do device guys get around this problem? You can use the same technique as the Mobile p&p team do with the DataAccess block which forms part of the recent Mobile Application Blocks drop: http://www.codeplex.com/Mobile. In one of there test projects they have a mock database dependency that is tested on the desktop but need a sample database to test against.
They set the Build Action to Embedded Resource then they use reflection to unpack it. You might think this is quite a bit of work, but they have a reusable class named TestResourceFile that belongs to the TestUtilities project. Using this class does all the unpacking for you.

The code to copy this dependency could look like the following (I've taken this from the p&p Mobile codebase):

private TestResourceFile CreateDbFile()
{
    dbFile = new TestResourceFile(this, "MockDatastore.sdf");
    connectionString = String.Format(connectionStringPattern, dbFile.Filename);
    return dbFile;
}

[TestMethod]
public void ThrowsIfNullParameterNameIsPassed()
{
   using (TestResourceFile file = CreateDbFile())
   {
      using (Database database = new SqlDatabase(connectionString))
      {
         Database service = new SqlDatabase(connectionString);
         ExtendedAssert.Throws(
         delegate { DbParameter param = service.CreateParameter(null, "Maria Anders"); });
      }
   }
}

But even still there is a better way to solve this problem and that is to use the DeploymentItemAttribute class. It's use is simple. The following code illustrates it use:

[DeploymentItem("Mobile.DataMapper.config")]
[TestClass]
public class DataContextFactoryTests
{
}

The above code will copy the file "Mobile.DataMapper.config" to the test output directory. You need to ensure to set the file properties Build Action to Content and Copy to Output Directory to Copy always.

I've got to say thanks to Chris Tacke for telling me about this attribute class.

http://answers.microsoft.com

Microsoft has recently (last few months) announced and released a website for Windows Vista users to post questions here: http://answers.microsoft.com.

There is quite a large MVP presence there to answer your Windows Vista questions.

What type of applications can we build on Windows Mobile today - Part 3 of 10

This is part 3 of 10 of the getting started with Windows Mobile development series. For previous posts in this series please see here.

Today mobile development is getting easier. Many folks from the desktop can port there C# skills over and hit the ground running fairly quickly. The Compact Framework is maturing nicely. Development tools and emulators are getting more feature rich and more reliable.

The types of applications you can build today for Windows Mobile - with regards to managed code fall into the following groups:

1. Microsoft .NET Compact Framework. This is a subset of the Microsoft .NET Frameworkdesigned specifically for mobile devices. Use this technology for mobile applications that must run on the device without guaranteed network connectivity.
2. ASP.NET Mobile. This is a subset of ASP.NET, designed specifically for mobile devices. ASP.NET Mobile applications can be hosted on a normal ASP.NET server. Use this technology for mobile Web applications when you need to support a large number of mobile devices and browsers that can rely on a guaranteed network connection.
   

ASP.NET for Mobile no longer has designer support in Visual Studio 2008. You can simply use the desktop controls and they will render. Now with "6on6" which is IE 6 engine on Windows Mobile 6.1 this will make web development for mobile easier. You can test IE 6 with the recently released WM 6.1 emulators. I wrote a post on this here. One thing to bear in mind is of course screen size.

Most developers write .NET Compact Framework applications over ASP.NET for LOB (Line of Business applications) due to the smart client nature. Also the power of a .NET CF application allows the developer to do whatever he wants. You can access the camera the GPS chipset the radio or the phone. You can access Outlook, manipulate appointments or add/change a contact. You can access a Relational Database Management system such as SQL Server Compact to store your applications data then sync back to SQL Server desktop using Sync Services (Sync Framework). You can write very compelling UI using GDI or on later devices GDI+ for support such as gradient backgrounds and transparency. XNA sadly is not supported, however DirectX is but is limited and memory intensive.

The main power of using the .NET Compact Framework over any other technology is the fact that it is embedded and works great in smart client environments where connectivity is an issue.

ASP.NET is rarely used in my experience, one reason is due to the connectivity issues. Under ASP.NET, mobile devices require a constant connection with the server in order for this type of architecture to work. Web applications do not work well in enterprise solutions for mobile devices. They do work well for consumer applications but not mission critical ones.

You'll probably be thinking how do you architect an application for the .NET Compact Framework. Most developers adopt the Active record pattern for the business layer. This tends to work well as mobile applications tend not to be as complex as desktop applications. And now performance tends not to be so much of a problem as it once was. ORMs and Domain Driven Development with patterns such as the repository data access layer is not quite as good a story.

The only ORM that supports the CF and SQL CE to date is LLBLGen. I am in the process of building an ORM for the Compact Framework and intend on writing an MSDN article how I did it.

The CF 3.5 does support WCF as a consumer, ServiceHost is not supported. There are many binding and other limitations however. Usually the device will have its own domain that uses either a message protocol which can be completely bespoke over TCP or a service layer with standard DTOs via HTTP. Or in some cases Sync data directly using Sync Services or merge replication. Each application is different. Of course vanilla Web Services ASMX has been supported since CF 1.0.

Preview of Windows Mobile 6.5 at MIX

Checkout WM 6.5 by Loke Uei Tan (requires Silverlight). See other videos here: http://videos.visitmix.com/MIX09/All

An example of the Plugin pattern on the Compact Framework

I have been talking about IoC containers on the Compact Framework lately and thought I'd show an example of implementing a simpler example of separating concerns. There is another common pattern to which IoC I believe was derived called the Plugin pattern.

The Plugin pattern is talked about by Martin Fowler in his Patterns Of Enterprise Application Architecture book (good book by the way). It is (in my opinion) a simpler solution to IoC but is a little more limited and doesn't usually involve a framework.

I involves using reflection and creating a factory to create a type usually specified in a configuration file using a common interface. This pattern promotes Aspect Oriented Programming.

As I am in the process of building a managed ORM for the Compact Framework, I decided to use the Plugin pattern for building the data context part of the API. I decided this because the Plugin is easy to implement and doesn't require any framework to implement. I wanted to keep the ORM as simple as possible while at the same time making the framework decoupled from the type of database desired.

As mentioned I am using this pattern for the data context part of my ORM and I have a configuration file used to specify the type of database. Doing this enables me to easily change my database without having to rewrite a vast majority of my application. I don't even need to recompile my app. I can simply change the config and re-run my app.

The configuration setting that specifies the database dialect looks like this:

<property name="datacontext" value="Mobile.DataMapper.Dialect.SqlServerCe35DataContext"/>

The SqlServerCe35DataContext looks like:

public class SqlServerCe35DataContext : DataContext
{
      private SqlDatabase _database;
      private readonly MsSqlCe35Dialect _dialect;

      public SqlServerCe35DataContext()
      {
          _dialect = new MsSqlCe35Dialect();
      }

      internal override Database Database
      {
          get 
          { 
              if (_database == null) _database = new SqlDatabase(ConnectionString);
              return _database;
          }
      }

      internal override Dialect Dialect
      {
          get { return _dialect; }
      }
}

The DataContext class contains the default implementation of SQL Server CE and is defined as an abstract class. It also implements the IDataContext interface which we use in our factory. This enables us to use the Plugin pattern successfully.

Part of the DataContext class looks like this:

public abstract class DataContext : IDataContext
{
    private DbTransaction _transaction;
    private string _connectionString;

    public virtual void Commit()
    {
        if (_transaction.IsNull()) throw new InvalidOperationException("There is no transaction for this session.");
        _transaction.Commit();
    }

    public virtual void BeginTransaction()
    {
        _transaction = Database.GetConnection().BeginTransaction();
    }

    public virtual void BeginTransaction(IsolationLevel isolationLevel)
    {
        _transaction = Database.GetConnection().BeginTransaction(isolationLevel);
    }

    internal abstract Database Database
    { 
        get;
    }

    internal abstract Dialect Dialect
    {
        get;
    }
}

I've omitted many memebers as it's not important what this class does. What is important is the implementation in order to implement this pattern for devices.

For those interested, this is based on the Mobile Client Software Factory. I will be publishing the source code to my ORM for Windows Mobile soon - once finished.

So as we saw, the DataContext is abstract and it contains an interface. Just so you can see, the interface looks like this:

public interface IDataContext : IDisposable
{
    string ConnectionString { get; set; }

    //Transaction management.
    void Commit();
    void Rollback();
    bool IsInTransaction{ get;}
    void BeginTransaction();
    void BeginTransaction(IsolationLevel isolationLevel);

    IList<TEntity> Read<TEntity>(QueryExpressionCollection queryExpressionCollection);
    IList<TEntity> Read<TEntity>(QueryExpressionCollection 
      queryExpressionCollection, List<Func<ObjectProperty>> columnsInScope);
    IList<TEntity> FindAll<TEntity>();
    TEntity Read<TEntity>(object id);

    int Delete<TEntity>(TEntity entity);
    TEntity Save<TEntity>(TEntity entity);
    string DatabaseName { get; set; }
       
}

As I said I omitted most of the above members from the DataContext class above for clarity as I want to focus on the architecture not implementation details for this post.

So now we have four things:

1. Configuration file that tells us what datacontext to use.
2. The datacontext implementation (SQL CE Server) to use.
3. The base datacontext class.
4. The datacontext implementation.

The only thing that is missing to put all this together so the consumer can just work with the interface (as the consumer doesn't care about where the data lives or how the data is retrieved) is the DataContextFactory.

The Factory is very simple. It looks like this:

public class DataContextFactory
{
    private IDataContext _instance;

    public DataContextFactory()
    {
        CreateInstance(null);
    }

    public DataContextFactory(IDataMapperConfiguration dataMapperConfiguration)
    {
        CreateInstance(dataMapperConfiguration);
    }

    private void CreateInstance(IDataMapperConfiguration dataMapperConfiguration)
    {
        if (dataMapperConfiguration == null) 
           dataMapperConfiguration = MapperFactory.CreateDataMapperConfiguration();
        var dataContext = dataMapperConfiguration.DataContext;
        var asm = Assembly.GetExecutingAssembly();
        _instance = (IDataContext)asm.CreateInstance(dataContext.Value);
        if (dataMapperConfiguration.HasConnectionString)
            _instance.ConnectionString = dataMapperConfiguration.ConnectionString.Value;
    }

    public IDataContext GetDataContext
    {
        get
        {
            return _instance;
        }
    }
}

Notice how we have another dependency the IDataMapperConfiguration. There's no need to document this code but quite simply it's a serialized object of the XML posted earlier. We get two things from this XML file 1. The ConnectionString and 2. The concrete DataContext class that implements DataContext. Notice how we set the ConnectionString property after the type has been created. We do this because the CF only supports one Assembly.CreateInstance method that accepts the type to create.

So using this code from the consumer looks like this:

IDataContext context = new DataContextFactory().GetDataContext;

then the consumer can work with this interface as opposed to the implementation. The consumer knows nothing about the underlying database or storage. If you changed the database from Sql CE to SQLLite for example, it is a simple case of changing the configuration file, then re-running the app.

You could implement this architecture with the IoC framework and using dependency injection pattern but the current one developed by the p&p team at Microsoft doesn't have support for configuration files. This means you'd have to recompile your app anytime you change the DataContext implementor. Now, no doubt Microsoft will roll out another version that supports configuration files in the future as the ContainerModel is a fairly early drop.

So the benefit with this implementation is, it's really really easy to implement and doesn't require any framework. If the implementors existed in another assembly, you could easily change the DataContextFactory to use the LoadFrom method to load a given assembly.

Dependency injection using the ContainerModel on the Compact Framework

I mentioned a few weeks ago about the availability of an IoC framework for the Compact Framework here.

But a question related to this is how do you implement the dependency injection pattern with this IoC framework as IoC (Inversion of Control) and dependency injection go hand in hand with one another.

The most common way to implement dependency injection is via the constructor. Sadley this container doesn't work like Castle Windsor where Castle resolves dependencies for you automatically without you having to define then when registering the class. However the class still needs to be defined by an interface! With the device Container model you have to explicitly define your dependencies at registration. I'm ok with this as I'm happy to have a half decent container model for the Compact Framework.

So we have our CustomerRepository class that has a dependency on some Adapter (I just made this adapter up, it could do anything). The class looks like this:

public class CustomerRepository : Repository<Customer, int>, ICustomerRepository
{
    private IAdapter _adapter;

    public CustomerRepository(IAdapter adapter)
    {
        if (adapter.IsNull()) throw new ArgumentNullException("adapter");
        _adapter = adapter;
    }
}

Now, there are no methods in this class but the point is to show the dependency because later, we want to use the adapter class to do some... adapting.

So how do we set up the container to inject the adapter. Something like the following should do the trick:

using Microsoft.Practices.Mobile.ContainerModel;

var builder = new ContainerBuilder();
builder.Register<IAdapter>(adapter => new Adapter());
builder.Register<ICustomerRepository>(repository => new CustomerRepository(Resolve<IAdapter>()));
builder.Build(container);

Then from the consumer, we can code something like the following:

var customerRepository = ComponentContainer.Resolve<ICustomerRepository>();

We didn't have to declare our dependency, it was injected by the framework. We just resolved the adapter when we registered the repository. Of course you need to register this dependency with the framework first. You could use the concrete type here but this means if you change implementation details, you'd have to change the implementor in more than one place.

There we have it, dependency injection using an IoC container on the Compact Framework 3.5.

Missing IEnumerable<T>.ForEach(Action<T> action)

Have you ever wanted to code something like this in .NET 3.5:

var repository = new CustomerRepository();
repository.Customers.ForEach(customer => Console.WriteLine(string.Format("Customer: {0} {1}", 
    customer.FirstName, customer.LastName)));
Console.Read();

Where Customers is of type Collection. Well you can't out of the box as the framework doesn't provide an extension for IEnumerable foreach (which is what Collection implements).

The Repository and domain object in the above case looks like this:

public class CustomerRepository
{
    public CustomerRepository()
    {
        Customers = new Collection<Customer>()
                        {
                            new Customer()
                                {
                                    FirstName = "Simon",
                                    LastName = "Hart"
                                },
                            new Customer()
                                {
                                    FirstName = "Joe",
                                    LastName = "Bloggs"
                                }
                        };
    }

    public ICollection<Customer> Customers
    {
        get; set;
    }
}

public class Customer
{
    public string FirstName
    { 
        get; set;
    }

    public string LastName
    { 
        get; set;
    }
}

You can make the above call work with this simple extension for IEnumerable:

public static class GenericIEnumerableExtensions
{
    public static void ForEach<T>(this IEnumerable<T> collection, Action<T> action)
    {
        foreach (var item in collection)
        {
            action(item);
        }
    }
}

It's quite simple in that it accepts one parameter, an Action delegate with one parameter - this could be extended to do whatever you want. Although the above is in line with the List.ForEach extension method.

The benefit of this is it simply reads better with less code.

You might find this library found on codeplex useful: http://extensionmethodsyay.codeplex.com/

Mobile Application Architecture Guide

The p&p team at Microsoft has put together this document on Mobile Application Architecture best practice. You can find it here on codeplex: http://www.codeplex.com/AppArch/Release/ProjectReleases.aspx?ReleaseId=19798

I am currently putting together a solution that I plan to write an MSDN document detailing many of these technologies referenced in the document - some of which do not exist for mobile devices. This solution contains all the cool new stuff like, object relational mapping, Inversion of control, dependency injection, crosscutting inteceptors, domain driven design and how to achieve this in a mobile application. The latest UI controls in the market place. The repository data pattern. .NET CF 3.5, LINQ and lambdas - when to use them. Test driven development using MSTEST for devices.

I will post the link here when done.

Apple iPhone OS 3.0 preview event

A first look at the coming release of the Apple iPhone OS 3.0 by engadget: http://www.engadget.com/2009/03/17/live-from-apples-iphone-os-3-0-preview-event/

Microsoft Recite Technology Preview

There is a lot of cool stuff coming out of Redmond lately and Microsoft Recite is no exception.

Microsoft Recite is a tool that allows you to verbally record your thoughts to aid you to remember things, then retrieve them by asking (voice recognition) Recite for the content using any of the phrases in the recorded message.

Recite is supported on these devices:

AT&T BlackJack II

AT&T Pantech Duo

HTC Diamond

Moto Q9m

Palm Treo 800w

Palm Treo Pro

SMT 5800

T-Mobile Dash

T-Mobile Shadow

T-Mobile Wing

Motorola Q9C

Checkout a video of Recite in action here: http://recite.microsoft.com/Pages/ReciteVideo.aspx
Get it here: http://recite.microsoft.com/Pages/download.aspx

I am unaware of any Recite managed SDK at this point.

Microsoft TechDays Developer 2009 - 24hr Virtual Event

On April 1st 2009, be part of Microsoft history and join developers all over the world for the first ever 24-hour day of technology learning.

Participate in 95 live sessions anywhere, at anytime or on-demand at your convenience.

It is a free event.

To register for this event, click here: http://www.msfttechdays.com/public/home.aspx

To view the sessions, click here: http://www.msfttechdays.com/public/sessionlist.aspx

Microsoft are still calling for content so not all sessions are visible. Also you will be able to build you're own schedule in due course.

I'm not aware of any mobility tracks as yet, but my best guess is there will be some.

I'm a PC and I'm an MVP!

The MVP version of the "I'm a PC" video (from the MVP summit 2009):

Broadband Speed test - South East England

I recently changed ISPs for my home network. I now use O2 (in UK) O2 bought Be Un Limited a while back. I was on Sky - Sky bough Easynet a few years ago. Sky was very slow and unreliable.

The upload bandwidth was almost no-existent. Experience playing on-line games was not much fun due to the lag. You need good upload bandwidth for playing on-line games successfully otherwise you just get slaughtered.

I used http://www.speedtest.net to measure the speed of both networks. As you can see, it is a big difference between the two networks. Also notice the ping response differences.

Anyone else in my area, Guildford, South East England who is on Sky should consider O2.

Here are the results:


Sky Easynet (before)


O2 (Be Un Limited)

I am around 5 miles from the BT exchange.

IoC framework for the Compact Framework

Andy Wigley mentioned the other day the p&p team has released a series of blocks for the Compact Framework including a dependency injection framework called ContainerModel. So I decided to have a look.

You can get the code from codeplex here: http://www.codeplex.com/Mobile

It is based on the MCSF but for .NET CF 3.5.

I have had a look at the IoC framework and it is pretty good but would be even better if it had support for configuration files (XML). So currently you have to code something like this:

builder
    .Register<IEditCustomersView>(
        c => new EditCustomersView())
    .InitializedBy(
 (c, v) => v.Presenter = c.Resolve<EditCustomersPresenter>());

Then you can code this:

var view = ApplicationRoot.Container.Resolve<IEditCustomersView>();

This is a first cut so maybe we will see support for configuration files in the future. If I get time I'll add support for it.

It's quite cool as you can pass in an Action delegate at the time of register to instantiate the class.

Oracle Day 2009 - Smart Strategies for Uncertain Times

On March 5th 2009 in London, Oracle is holding an event "Oracle 2009 - Smart Strategies for Uncertain Times" to which Edenbrook is a key sponsor. A snip from the event website:

The Oracle Day 2009 will cover the Oracle Technology stack from the Database and Middleware through to SOA, Enterprise 2.0, Business Intelligence and Security. This event will bring together IT professionals across industry sectors to address the real challenges faced by IT today - consolidating, cutting costs and innovating. After the keynote speaker presentations the event will break into two distinct tracks, one for IT Management and one for IT professionals and architects, providing the opportunity to select the sessions most relevant to you.

The address for this event is:

Renaissance Chancery Court Hotel
252 High Holborn
London
WC1V 7EN

To register see here or see here for more information.

Mobility developer tools - Part 2 of 10

UPDATE: updated 15/02/09 to correct some information.

This is part 2 of 10 of the getting started with Windows Mobile development series. For previous posts in this series, please see here.

Again we are concentrating mainly on Microsoft Windows Mobile technology although other developer tools are briefly mentioned.

Unmanaged Device Development

Unmanaged device development is supported but not under Visual Studio 2008. Porting MFC code to Windows Mobile is not easy as there is no support for OLE on Windows CE. There is support for COM on Windows CE however.

Managed Device Development

The most common method for writing device applications today is using managed code. C# or VB.NET are the only supported managed languages for the Compact Framework. Very few people build applications using embedded technologies today. The sort of people doing embedded (native) development today are people who are writing low-level device driver software or managed developers who want to implement some sort of security code protection algorithm which can’t easily be reversed engineered as a managed application can.

All versions of Visual Studio 2002 had support for managed device application development. This changed from VS 2003 where the express edition dropped managed device support and this was true for VS 2005 as well. So Standard Editions or later of VS 2003 or VS 2005 are required in order to target devices. This changed again with the release of the latest version of Visual Studio which is 2008 where Professional Edition or later is required for device application development support.

VS2008 supports multi-targeting that allows the device developer to target CF 2.0 and CF 3.5. In order to target CF 1.0 you have to use VS 2005 with a CF 1.0 project. The Compact Framework is covered in great detail in a later relevant section.

When installing Visual Studio 2008, the Smart Client extensions are selected by default but prior versions you have to explicitly select the Smart Client extensions for Mobile device support.

What is the Compact Framework

The Compact Framework is a subset of the full Microsoft .NET Framework (not to be confused with the .NET Micro Framework which has a 300k memory footprint). Because device applications run on memory and CPU constrained devices, not all the classes, methods, properties etc are supported on the CF. There is a lot of stuff missing.

The Compact Framework has around a 3-4 Mb memory footprint although with each release this gets larger to satisfy developers needs and new technology but devices are shipping with more and more memory (ROM and RAM) each year.

Since Windows Mobile 2003 Second Edition, Microsoft has insisted that at the time the OEM builds the WM image, the latest RTM version of the Compact Framework is shipped in ROM. This is really cool for many reasons:

1. This gives a developer more RAM for his/her applications and also more flash storage
2. Before WM5 was released, there was no flash persistent storage that the OS occupied. Back then, everything resided in RAM and memory was divided between application storage space and proper RAM used to load applications. Performance was a nightmare as you can imagine. The user could customize this divide, but this was too complex for a non-technical user. So if the battery went flat, you would lose all your content. WM5 changed this. So Microsoft decided to ship the CF in ROM. This elevated some of the memory constraints but often the CF was out of date at the time of build because of the long process carriers/OEMs take to build new images they are not agile enough like Microsoft so by the time the devices hit the market, they are a version behind.
3. As it happens, WM2003 SE shipped with version 1 of the CF, which mean’t managed developers could for the first time write an auto load application and ship it on a removable flash card such as a SD or Micro SD card. So when card was inserted into the device the application would run. Previous to this managed developers had to write this kind of auto load application in eVC++ or eVB. The later WM5 devices shipped with the CF 2.0 SP1. Even many WM6.0 devices still ship today with CF 2.0 SP1 even though CF 3.5 has been released for over 1 year. It turns out WM6.1 do ship with CF 3.5 and SQL Compact 3.0 (latest version of SQL Compact at the time of writing is 3.5)
   

Compact Framework – Architectural differences over the desktop version

There are some architectural differences with the Compact Framework over the desktop versions. There was no v1.1 or v3.0 of the CF. The latest version of the CF which is 3.5 has its own CLR. It’s not derived from the CF 2.0 as per the desktop. There is no *current* support for vector based UI such as WPF other than Silverlight 2 for Mobile (not even in CTP yet) – which we talk about in a later article. There is WCF client support in CF3.5 just no ServiceHost support. The WCF support is also a subset. The subset support is documented here and here.

The Compact Framework is Retargetable – which means it supports and does define the AssemblyFlags(AssemblyNameFlags.Retargetable) attribute in all it’s assemblies. So what does this mean? Well it means you can retarget the IL compiled against the CF and run it against the desktop CLR (within reason) and generate the same native code. It saves you the need to recompile for the desktop.

Below is a snapshot of the System.Windows.Forms assembly, as you can see the Retargetable enum is defined with the AssemblyFlags attribute.

// Assembly System.Windows.Forms, Version 3.5.0.0

[assembly: AssemblyVersion("3.5.0.0")]

[assembly: AssemblyFlags(AssemblyNameFlags.Retargetable | AssemblyNameFlags.PublicKey)]

[assembly: SatelliteContractVersion("3.5.0.0")]

[assembly: CLSCompliant(true)]

[assembly: ComVisible(false)]

[assembly: InternalsVisibleTo("Microsoft.WindowsCE.Forms,PublicKey=0024000004800000940000000602000000240000525341310004

000001000100bd1c7c2c1fbccfb3d24f1df7837e334e7686556e90dae8768b959497f308652686d8bebb7fc14eeb

efcfa9cffbf97d522fc678a5091cf188af5f3044b05fc3737b1c732fae4e191307da9fe29bda9c7d77e49dda0e5ed3

616b50f1e4d0a4b95fcd627157449e79cae5c5be456aa379849bd6dee7db0d5b0ff0743b0cabfa8ee7")]

[assembly: Debuggable(DebuggableAttribute.DebuggingModes.IgnoreSymbolStoreSequencePoints)]

Although it is possible to share your device compiled with the desktop, the reverse is not true. This is because….you guessed it the desktop assemblies do not contain the Retargetable enum.

Usually though, device developers share code, not assemblies, and have separate projects for the desktop and the device. Then in the code they will define a conditional compiler directive so that device specific instructions, for example calling coredll.dll functions are omitted on the desktop.

Although the Compact Framework and the full framework use what appears to be the same classes, methods, properties. They both use the same languages C# or VB.NET and the CLR appears to be the same – at least from the outside. The Compact Framework’s CLR is dramatically different from that of the full framework especially from a memory GC and allocation perspective. This is largely to do with the way Windows CE handles memory. Each process, this includes each AppDomain is allocated a maximum of 32 meg. This doesn’t include the System core space. So of course the CF has to work with this constraint and there are many things it does to ensure the smooth running of applications and the general OS to ensure it doesn’t grind to a hault and run out of memory. I have written a fairly lengthy article about this process here.

Platform Invocation

Because the Compact Framework is just that, compact it is inevitable that you have to call native code (OS Win32 APIs). This process is known as Platform Invocation or P/Invoke and thankfully it is supported on the CF.

Just one example of this is controlling the Telephony API (TAPI) there is no managed API to control the radio, GSM, 3G etc. So it is often beneficial for managed device developers to have a background in native C++ as it requires translation to managed code for interop.

There is a good site for doing interop between .NET and native here: http://www.pinvoke.net.

Device Emulators

Device emulators available today are true ARM emulators and they come with the relevant Windows Mobile SDKs. So for example the latest version is Windows Mobile 6.1 SDK for Windows Mobile standard and professional. See the earlier post: Windows CE, Pocket PC, Smartphone, Windows Mobile - what's the difference! - Part 1 of 10 as to what the differences are between standard and professional. Pre Windows Mobile 5 emulators were based on x86 so were not really a true emulation. So back then developers never really used the emulators.

Today they have come along way.

Since Windows Mobile SDK 6 we have had the Cellular Emulator that allows greater human testing.

OpenNETCF SDF

OpenNETCF Smart Device Framework is a shared source project free for developers to download in a pre-compiled format.

The SDF has been around for many years and was a life-line for developers when the CF v1.0 was released. This was because there were so many features/classes missing which made device developers used to developing desktop applications very difficult.

So what is the SDF? The SDF is a series of class libraries to bridge the gap between the full framework and the Compact Framework. The OpenNETCF team identified the missing assemblies and in many cases wrote these for which now forms the SDF. The SDF also contains many device specific classes many of which form wrappers around native APIs that are absent from the CF and also include many UI controls. Even with the lastest version of the CF many featuers are still missing due to memory contraints, the SDF does in many cases offer an alternative solution.

The community edition is free in pre-compiled format. The standard or professional editions are required if you want support - for a small fee.

Please see the following link for more information:
http://www.opennetcf.com.

ORMs on Windows CE

There is currently no support for NHibernate or the Entity Framework or even DLINQ (LINQ to SQL) on Windows CE and the Compact Framework. There is however support for LLBLGen but often performance becomes a bottleneck for ORMs to work effectively.

Most device developers handcraft data access layers themselves with a repository and domain model or a more Active record pattern approach.

I am currently working on building a simplified ORM for the CF. It is tailored for the CF 3.5. It doesn't include any type of lazy loading or using proxies not because of the technical challenges this will impose but because the performance would a major issue on devices. I have designed it to support persistence ignorance objects or the support for Plain Old CLR Objects. It is built on the Mobile Client Software Factory Data Access Application block. I want to find a way to abstract the repository interface from the implementation as the Castle project does. Currently the repository interface is tied to the implementor.

I'll post this code on MSDN once finished.

LINQ for devices

There is support for LINQ on the Compact Framework. However there is no support for LINQ to Entities or DLINQ (LINQ to SQL). There is support for LINQ to XML.

I've written a few posts about LINQ for devices here.

Databases on Windows CE

There are a few options of relational database management systems when it comes to mobility. The options are as follows:

1. SQL Server Compact
2. Sybase IAnywhere
3. SQLite
4. MySQL
   

Microsoft’s latest offering is SQL Server Compact 3.5. As with the Windows Mobile OS name changes, SQL Server Compact has gone down a similar path. The difference with SQL Server Compact today is that it can be run on the desktop as well as mobile devices. There are different installations but you can read/write the same database on both platforms. This feature has been supported since v3.1.

There is support in SQL Server Management Studio (standard or later, not express) that allows you to connect to an SDF (compact database). The database looks as if it were a normal MDF desktop database. You can run queries, change the schema, create a diagram etc. The tool also has support to connect to a database on the device when the device is connected via ActiveSync or Device Manager (Vista). Note though, SQL Server 2005 Management Studio doesn’t work with SQL Server Compact 3.5. You have to have SQL Server 2008 installed. You can however use Visual Studio 2008 to connect to the SDF if you wish, although the tooling is very limited.

The Microsoft Patterns & practices team have written a data application block that allows easy data access. This application block forms part of the Mobile Client Software Factory.

SQL Server Compact – Architecture differences over the desktop version

The main difference between SQL Server Compact and the full desktop version is SQL Server Compact is embedded. It runs within the callers context. This explains the reason why there is no support for stored procedures in SQL CE. This doesn’t mean the whole database engine is reloaded per application domain or process space. The process is shared across many applications as the system core memory space is used.

Since version 3, SQL CE is now multi-threaded so it has multi-user support. As with most device technologies, SQL CE is a cut-down version of the desktop version. It wasn’t until v3.5 recently released that the rowversion (timestamp on desktop version) data type was supported.

My Mobiler

My mobiler is a tool that allows remote control of your device over ActiveSync or Sync Center. This is great for demos. I blogged about this tool a while back here: http://www.simonrhart.com/2008/06/my-mobiler.html.

You'll notice it is very similar to ActiveSync remote display but alot better. ActiveSync remote display comes with Windows Mobile Power Toys.

Although to get it to work on later devices you'll need to read this.

Windows Mobile Power Toys

Windows Mobile Power Toys is a suite of applications to aid development. One of the most useful applications that comes with this suite is the Hopper - a user input stress simulator.

Windows Mobile API Usages Tool

The Windows Mobile API Usages Tool is a command-line tool that runs on your desktop that performs static analysis of applications and binaries to run on Windows Mobile devices and reports the usage of system APIs and other resources. The goal of the tool is to provide a report of system dependencies to the application developer, optionally including the deprecated APIs that the application may currently depend on.

The Windows Mobile team blog talk about this tool in a little bit of detail here.
Non-Microsoft Mobility Development

Recently the Google Android was released. The developer tools are freely available to download. The development environment is called Eclipse (Java based) and the Google Android SDK contains the emulators to test your code.

If you are interested in writing applications for Google Android, see here: http://code.google.com/android/

Currently you will not get the same development experience with Google Android than you do with Windows Mobile. Developing applications for mobile phones is challenging and Google Android is still yet to mature somewhat.

Summary

There are probably more tools that I have forgotten about but when I remember, I'll add them.

Windows Mobile Development - for newcommers

This post details the internal links for 10 getting started with Windows Mobile articles in the following order parts that are designed for newcomers to mobility. The links will become enabled once published:

• Windows CE, Pocket PC, Smartphone, Windows Mobile - what's the difference! - Part 1 of 10
• Mobility developer tools - Part 2 of 10
• What type of applications can we build on Windows Mobile today - Part 3 of 10
• Data storage and synchronization techniques on Windows Mobile - Part 4 of 10
• Unit testing and debugging on Windows Mobile - Part 5 of 10
• What is a smart client app and how do we develop a smart client app on WinMo? - Part 6 of 10
• Communications with Windows Mobile - What are our options - Part 7 of 10
• Silverlight and Windows Mobile - whats the story - Part 8 of 10
• The future of Windows Mobile - Part 9 of 10
• Our first Compact Framework 3.5 Windows Mobile application - Part 10 of 10

Windows CE, Pocket PC, Smartphone, Windows Mobile - what's the difference! - Part 1 of 10

Welcome. This is the first part of 10 articles to get you introduced to Windows Mobile (device) development. For other posts in this series, please see here.

The first question many new comers ask is, what is the difference between Windows CE, Windows Mobile, Pocket PC, Pocket PC Phone Edition, Smartphone, PDA's ? ....There are more names.

Essentially this is Microsoft marketing gone mad! The truth is, all the platforms above are Windows CE.

Windows CE

Windows CE is an embedded operating system designed to run on small memory and CPU contrained devices. The OS is highly customizable. An OEM (original equipment manufacturer) can choose which bits to add and which bits to take away.

Some ISV's (independent software vendors) build their own Windows CE using a tool called Platform Builder to provision to a generic Windows CE device. Doing this allows great control over how the device will operate. This is known as Windows CE Embedded.

Pocket PC

Pocket PC 2000 or PPC (Windows CE 3.0) was the first Pocket PC which didn't contain any GSM or radio. These are the devices you can still buy today except they are now called Windows Mobile Classic and most now are based on Windows CE 5.0. These devices were initally released with a 320x240 QVGA screen or 92DPI. So we mentioned Pocket PC is a Windows CE device.

Pocket PC/Windows Mobile devices have a different shell and a whole bunch of additional Win32 APIs and applications not seen on generic WinCE. So fundementally WinMo is a WinCE but a greatly customized version of it. The OEMs/carriers decide how the WinMo will be built, even down to what APIs are available to appliation developers and the security policy employed.

Smartphone

First released in 2001. The Smartphone followed the PPC that added GSM support but unlike the PPC, it didn't have a touch screen and still doesn't today. Today the Smartphone is known as the Windows Mobile Standard edition. It's worth noting that the smartphone has a much smaller screen than the Pocket PC which at the time was 176x220 QVGA - which by and large hasn't really changed much. Hi-resolution smartphone devices are rare unlike its bigger brother PPC.

Pocket PC Phone Edition

First released in 2002 (based on CE 4.1) which included GSM support with 2.5G (GPRS). Eassentially this was very similar to the Pocket PC except for radio. At the time there were very few of these devices around. Today it's hard to by a regular PPC (Windows Mobile Standard) device.

Windows Mobile 2003 Second Edition

Released in 2003 and based on CE 4.2. Contained many shell extensions - a whole UI overhaul and also the .NET Compact Framework v1.0 included in ROM which was a major benefit for managed developers for lots of reasons, the main one being it was able to write a managed app to load from a flash card on a cold boot (hard reset). Notice the naming change. This was when "Windows Mobile" replaced Pocket PC. But just to confuse the matter, the Smartphone was kept.

Windows CE 5.0

Released in 2004, but it wasn't until 2005 when Windows Mobile 5.0 devices became available from carriers and OEMs. WM 5.0 release was also when the naming changed to the following:

• Windows Mobile Classic (touch) would become - Pocket PC
• Windows Mobile Standard (non-touch) would become - Smartphone
• Windows Mobile Profesional (touch) would become - Pocket PC Phone Edition/Windows Mobile 2003

Windows Mobile 5

This was a major release for Microsoft from a platform perspective and developer story perspective. This was when Visual Studio 2005 with the .NET Compact Framework 2.0 was released which contained many many enhancements. Some of the great features from a platform perspective were an intermediate GPS driver which allowed developers to code against an API to get GPS data. Previously developers had to write very low level code to parse NMEA sentenses from a serial port (bluetooth or infrared) which was painful. In addition only one application could open the port and read data at anyone time.

Previous to WM5.0 there was no support for an embedded GPS chipset. Another cool feature was a standard Microsoft stack for communicating with the devices camera. Previously you had to code against the OEM's SDK which changed from device to device. A new flash file system was employed so files didn't exist in RAM taking up valuable memory so enabling a persistent store for all files. Some of the later devices included the .NET CF 2.0. Of course support for C# 2.0 was a massive benefit for the managed developer. The new security model was also introduced in this released - a requirement from the carriers which has caused major pain for ISV's and developers. This is not going away, sadly.

Windows Mobile 6.0/6.1

Windows Mobile 6.0 was released in 2007 and 6.1 in 2008. In fact I was in Redmond when 6.1 was released in April. Many enhancements and as more and more devices are released the uptake of VGA screens (initially supported from WM5.0) are becoming more common. Now also support for WVGA screens (640x800) is becoming popular - the new X1 from Sony and the HTC Touch Pro both support these displays. It is also worth mentioning here that WM6.1 is still based on Windows CE 5.0. It's simply shell extensions that have been added. Mainly the look and feel among other things. One thing is for sure, the performance is greatly improved over WM5.0.

References

See here for the Windows Mobile 5.0/6.0/6.1 SKU matrix: http://www.microsoft.com/windowsmobile/en-us/meet/version-compare.mspx

Although this post has been primarilly about Microsoft device development, in a future post I will talk about other platforms and languages/developer tools such as the iPhone, the Google Android and the Symbian OS.