How to package your Windows CE applications into a CAB during a nightly build process

I just wrote a post on how to package up your Windows Mobile/Phone/CE applications into a CAB file as part of your automated build process using either TFS 2010 or TFS 2008 and MSBuild. Check it out here:

http://smart421.wordpress.com/2011/02/24/how-to-package-your-windows-ce-applications-into-a-cab-during-a-nightly-build-process/

DiscoverServices : Failure in find service API calls : Can't find PInvoke DLL 'BTInterface.dll'.

I have been coding against the new Motorola MC65 and the Motorola ES400 - devices that will port onto the new Windows Embedded Handheld when released later this year.

I was attempting to pair with an embedded bluetooth device using the EMDK v2.3 - an EMDK that has worked on previous Motorola devices such as the MC75.

When attempting to pair using the Symbol.WPAN.Bluetooth.Bluetooth class, the device receives the pair message but then the EMDK throws ab Exception with message "DiscoverServices : Failure in find service API calls : Can't find PInvoke DLL 'BTInterface.dll'."

The stack trace looks like this:

   at ag.l(RemoteDevice A_0)
   at ag.n(RemoteDevice A_0)
   at ag.j(RemoteDevice A_0)
   at Symbol.WPAN.Bluetooth.RemoteDevice.Pair(String AuthenticationPIN)

I can confirm, once upgrading to the latest version of the EMDK v2.4 fixes this issue (v2.04 of the Symbol.WPAN.dll assembly).

You can download the EMDK v2.4 for .NET here: http://support.symbol.com/support/search.do?cmd=displayKC&docType=kc&externalId=12874&sliceId=&dialogID=196190455&stateId=1%200%20196186434

Testing Motorola EMDK WLAN implementation on the desktop

I've been writing about testing recently and whether or not to use device test projects or desktop test projects. You can read my view on this in a previous blog post.

No doubt if you have written code for any of the Motorola rugged devices (or other rugged OEM devices) you might have encountered the EMDK WLAN class (or similar if not coding against the EMDK) - which wraps the low-level mobile specific Motorola Fusion API. This is a prime example of why you should use a desktop test project rather than device project. Hang on, you just said the Fusion API can only execute on the device, so don't we need a device test project? No. The reason is simple, again if you have a continuous integration, automated build process setup, your tests will be executing on the build server so you won't be able to execute those tests against a real Motorola device. If you have a device test project, the best you can do is execute those tests on the Windows Mobile emulator - but what will this prove? In this case this is really no different in terms of a test problem than executing them on the desktop.

So this is a reason to write your WLAN tests within a desktop test project. Let me demonstrate...

The WLAN class that comes with the EMDK (Symbol.Fusion.WLAN.WLAN) is a prime example, to make things worst, it doesn't implement an interface, take a look:



So this makes it almost impossible to test. Instead how I have overcome this problem is to write an adapter that wraps the WLAN class, then mock out the adapter using Rhino Mocks. Observe the following WLAN implementation, the interface isn't important:

public class MotorolaMC75WLAN : IWLANService
{
    private readonly IMotorolaWLANAdapter _adapter;
    private bool _disposed;

    public MotorolaMC75WLAN(IMotorolaWLANAdapter adapter)
    {
       _adapter = adapter;
    }


    public void Enable()
    {
       if (!_adapter.IsEnabled)
       {
         _adapter.Enable();
         _adapter.PowerStatusChanged += OnPowerStatusChanged;
       }
    }

    private void OnPowerStatusChanged(object sender, PowerStatusChangedEventArgs e)
    {
       //raise events to interested parties....perhaps using some sort of event aggregator
    }

    public void Disable()
    {
       if (_adapter.IsEnabled)
       {
          _adapter.Disable();
          _adapter.PowerStatusChanged -= OnPowerStatusChanged;
       }
    }

    public bool IsEnabled
    {
       get { return _adapter.IsEnabled; }
    }

    public void RenewDHCP()
    {
       _adapter.RenewDHCP();
    }

    public void Connect()
    {
       _adapter.Connect();
    }


    #region IDisposable Members

    public void Dispose()
    {
       Dispose(true);
       GC.SuppressFinalize(this);
    }

    #endregion

    private void Dispose(bool disposing)
    {
       if (!_disposed)
       {
          if (disposing)
          {
             Disable();
             _adapter.Dispose();
          }
          _disposed = true;
       }
    }
}

So that is our high level implementation that can be easily extended and contains no low-level mobile code. The adapter in this case is injected and can be anything we want it to be which allows us to test this class easily on the desktop.

The next thing is our actual adapter. The interface for the adapter looks like this

public interface IMotorolaWLANAdapter : IDisposable
{
    void Enable();

    void Disable();

    bool IsEnabled { get; }

    void RenewDHCP();

    event EventHandler PowerStatusChanged;

    void Connect();
}

The implementation is low-level that talks directly to the WLAN class (Fusion API). I'm not going to include a typical implementation for this but an example Enable() method might look like the following:

public void Enable()
{
    if (IsEnabled)
       return;

    Symbol.Fusion.WLAN.WLAN command = null;
    try
    {
       command = new Symbol.Fusion.WLAN.WLAN(FusionAccessType.COMMAND_MODE);
       command.Adapters[0].PowerState = Adapter.PowerStates.ON;
    }
    catch (OperationFailureException ex)
    {
       //do something...
    }
    finally
    {
       if (command != null)
          command.Dispose();
    }
}

It simply enables the first adapter it can find. Non-of the real adapter is testable.

So if this were a device test project, we'd have to mock out the adapter by hand, then pass it in to the constructor to the MotorolaMC75WLAN class. But as we have decided to use a desktop test project we can use any mocking framework that we choose which enables us free of having to do the laborious hand mocking work.

You can download Rhino Mocks from here if you don't already have it: http://www.ayende.com/projects/rhino-mocks/downloads.aspx. Download the zip and extract it somewhere on your hard disk, then add a reference the Rhino Mocks assembly in your test project - there is only one dll you need to reference.



Add a

using Rhino.Mocks;

to your test class. Now if you wanted to mock out the adapter Enable method, in Rhino Mocks world it could look like the following using the newer triple A syntax:

[TestMethod]
public void ShouldEnableWLAN()
{
    IMotorolaWLANAdapter _mockWLANAdapter = MockRepository.GenerateMock<IMotorolaWLANAdapter>();
    IWLANService _wlan = new MotorolaMC75WLAN(_mockWLANAdapter);

    _mockWLANAdapter
      .Expect(x => x.Enable())
      .Repeat.Once();

    _wlan.Enable();

    _mockWLANAdapter.VerifyAllExpectations();
}

So the only actual thing we are testing here is the real MC75 WLAN class and not the adapter. The code is fairly easy to read. We are simply telling Rhino Mocks to expect exactly 1 call to Enable() when _wlan.Enable() is called. The thing to bear in mind here is to ensure your actual adapter doesn't contain bugs as we can't automate those tests on the build server.

There you have it, a true mocking framework put at use in the mobile space.

If you want to learn more about mocking frameworks, use Google, there are millions of articles out there on the subject.

Automated testing considerations for enterprise Windows Mobile projects - avoid a world of pain

I know in the past I have written blog posts on how to create unit tests that are actually executed on the Windows Mobile emulator which is great if you have mobile specific tests. But to be honest, when you are building large scale enterprise mobile solutions targeting a range of different devices i.e. Motorola, Casio, Intermec etc. Writing device specific platform tests for all these devices becomes quite hard to automate when using an application lifecyle management solution such as Visual Studio and TFS with its continuous integration and automated test execution support.

Even if you only support one type of device, when you do enterprise mobile development, using the tools mentioned above, you're not going to be able to automate those tests as part of a nightly build or even a CI build. As you will no doubt be using the vanilla Windows Mobile Emulators that know nothing about such specifics that you might be testing such as barcode reader, credit card reader, bluetooth stack etc. Instead you would normally write adapters or mock out implementation code when testing your barcode implementation. You'll generally never write an actual test that calls the true native code on that platform, why would you anyway unless it's part of an integration test. Ensuring you do this allows you to write unit tests, integration tests that do run as part of your nightly and CI builds that do improve code quality.

So what type of tests should you write for most of your code base, device or desktop? My advice is desktop even if you think your device project is small, there will come a time when your project becomes large and more complex. The benefit to targeting the desktop is the ability to use mocking frameworks. We tend to use Rhino Mocks and today there are 0 mocking frameworks available on the CF. If you start to go down to road of writing your own mocks, then you're entering a world of pain. When you think of it, most code can be tested on the desktop anyway. For things like data access, if you use SQL CE 3.5, then this can run on the desktop. For the features that require explicit device testing, then create a single device test project for this purpose and exclude it from the build definition.

Writing designer friendly controls for Windows Mobile

One thing that you sometimes need when writing Visual Studio designer friendly controls for Windows Mobile, is knowing if your code is running in design time - which is essentially running on the desktop or not. You need to know this because if you are running on the desktop (design time) you don't want to call device specific dlls.

The following code can be used to determine this:

public static class DesignMode
{
    private static byte _mode = 255;

    public static bool IsTrue
    {
        get
        {
            if (_mode == 255)
                _mode = AppDomain.CurrentDomain.FriendlyName.Contains("DefaultDomain")
                    ? (byte)1 : (byte) 0;
            return _mode == 1;
        }
    }
}

So essentially you can then code in your application:

if (DesignMode.IsTrue)
{
    //don't call coredll.dll
}
else
{
    //call coredll.dll
}

DbDataReader.DoesColumnExist

Have you ever wanted to code something like the following:

var dbCommand = Database.DbProviderFactory.CreateCommand();
dbCommand.CommandText = "select * from MyTable";
var reader = Database.ExecuteReader(dbCommand, null);
if (reader.Read())
{
   if (reader.DoesColumnExist("mycolumn")
   {
      //Then we know its safe to select the column.
   }
}

You're probably thinking, why would I want to do that? well if you're building a generic data handler library and you don't know what columns have been selected but you know the columns that could be selected then it is very useful as using the indexer to return the data for the specified column will throw an exception if it doesn't exist.

I thought this extension method solves this problem and would be useful for others:

public static class DbDataReaderExtensions
{
    public static bool DoesColumnExist(this IDataReader reader, string column)
    {
        if (reader.IsNull())              throw new ArgumentNullException("reader");
        if (string.IsNullOrEmpty(column)) throw new ArgumentNullException("column");
            
        for (var i = 0; i < reader.FieldCount; i++)
        {
            if (reader.GetName(i).Equals(column))
                return true;
        }
        return false;
    }
}

It's relatively straight forward but saves you from writing the same piece of code over and over again.

The unit test class for this is as follows:

[TestClass]
public class DataReaderExtensionsTests
{
    [TestMethod]
    public void ThrowsIfNullReaderIsPassed()
    {
        const MockDbDataReader reader = null;
        AssertExt.Throws<ArgumentNullException>(() => reader.DoesColumnExist("foo"));
    }

    [TestMethod]
    public void ThrowsIfNullColumnIsPassed()
    {
        var reader = new MockDbDataReader();
        AssertExt.Throws<ArgumentNullException>(() => reader.DoesColumnExist(null));
        AssertExt.Throws<ArgumentNullException>(() => reader.DoesColumnExist(string.Empty));
    }

    [TestMethod]
    public void ValidExists()
    {
        var reader = new MockDbDataReader();
        Assert.IsTrue(reader.DoesColumnExist("One"));
        Assert.IsTrue(reader.DoesColumnExist("Two"));
        Assert.IsTrue(reader.DoesColumnExist("Three"));
        Assert.IsTrue(reader.DoesColumnExist("Four"));
        Assert.IsTrue(reader.DoesColumnExist("Five"));
    }

    [TestMethod]
    public void InvalidExists()
    {
        var reader = new MockDbDataReader();
        Assert.IsFalse(reader.DoesColumnExist("foo"));
        Assert.IsFalse(reader.DoesColumnExist("bar"));
    }
}

You'll notice I have mocked the DbDataReader. Because there are mocking frameworks on the Compact Framework and probably will not be for some time (due to CF limitations) I have created a mocked class implementing the IDataReader interface. This mock class looks like the following:

public class MockDbDataReader : IDataReader
{
    readonly Dictionary<int, string> getName = new Dictionary<int, string>();
    public MockDbDataReader()
    {
        getName.Add(0, "One");
        getName.Add(1, "Two");
        getName.Add(2, "Three");
        getName.Add(3, "Four");
        getName.Add(4, "Five");
    }

    #region IDataReader Members

    public void Close()
    {
        throw new NotImplementedException();
    }

    public int Depth
    {
        get { throw new NotImplementedException(); }
    }

    public DataTable GetSchemaTable()
    {
        throw new NotImplementedException();
    }

    public bool IsClosed
    {
        get { throw new NotImplementedException(); }
    }

    public bool NextResult()
    {
        throw new NotImplementedException();
    }

    public bool Read()
    {
        throw new NotImplementedException();
    }

    public int RecordsAffected
    {
        get { throw new NotImplementedException(); }
    }

    #endregion

    #region IDisposable Members

    public void Dispose()
    {
        throw new NotImplementedException();
    }

    #endregion

    #region IDataRecord Members

    public int FieldCount
    {
        get { return 5; }
    }

    public bool GetBoolean(int i)
    {
        throw new NotImplementedException();
    }

    public byte GetByte(int i)
    {
        throw new NotImplementedException();
    }

    public long GetBytes(int i, long fieldOffset, byte[] buffer, int bufferoffset, int length)
    {
        throw new NotImplementedException();
    }

    public char GetChar(int i)
    {
        throw new NotImplementedException();
    }

    public long GetChars(int i, long fieldoffset, char[] buffer, int bufferoffset, int length)
    {
        throw new NotImplementedException();
    }

    public IDataReader GetData(int i)
    {
        throw new NotImplementedException();
    }

    public string GetDataTypeName(int i)
    {
        throw new NotImplementedException();
    }

    public DateTime GetDateTime(int i)
    {
        throw new NotImplementedException();
    }

    public decimal GetDecimal(int i)
    {
        throw new NotImplementedException();
    }

    public double GetDouble(int i)
    {
        throw new NotImplementedException();
    }

    public Type GetFieldType(int i)
    {
        throw new NotImplementedException();
    }

    public float GetFloat(int i)
    {
        throw new NotImplementedException();
    }

    public Guid GetGuid(int i)
    {
        throw new NotImplementedException();
    }

    public short GetInt16(int i)
    {
        throw new NotImplementedException();
    }

    public int GetInt32(int i)
    {
        throw new NotImplementedException();
    }

    public long GetInt64(int i)
    {
        throw new NotImplementedException();
    }

    public string GetName(int i)
    {
        return getName.ContainsKey(i) ? getName[i] : string.Empty;
    }

    public int GetOrdinal(string name)
    {
        throw new NotImplementedException();
    }

    public string GetString(int i)
    {
        throw new NotImplementedException();
    }

    public object GetValue(int i)
    {
        throw new NotImplementedException();
    }

    public int GetValues(object[] values)
    {
        throw new NotImplementedException();
    }

    public bool IsDBNull(int i)
    {
        throw new NotImplementedException();
    }

    public object this[string name]
    {
        get { throw new NotImplementedException(); }
    }

    public object this[int i]
    {
        get { throw new NotImplementedException(); }
    }

    #endregion
}

All we have done is returned 5 for the FieldCount, then provided some data so when GetName() is called we return the relevant item in the dictionary to resemble a real data reader object.

We could have written an integration test but this is pointless as we know the DataReader class has been tested and works.

The unit test class above gives 100% code coverage.

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.

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.

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.

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.

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.

Process.GetProcesses() on the Compact Framework

Process.GetProcesses() is not supported on the Compact Framework 3.5 and often this is a desirable thing to do. But luckily there are workarounds.

You can P/Invoke the required toolhelp.lib function Process32Next passing in a PROCESSENTRY32 struct and a Toolhelp32Snapshop.

The signature looks like this:

BOOL WINAPI Process32Next(
 HANDLE hSnapshot,
 LPPROCESSENTRY32 lppe
);

There is a fair bit of code required to get this working. You could implement this yourself or use an implementation from the Software Development Framework from OpenNETCF to save you a few hours of pain.

Coding this API looks like so:

var processes = OpenNETCF.ToolHelp.ProcessEntry.GetProcesses();
            
foreach (OpenNETCF.ToolHelp.ProcessEntry process in processes)
{
    Console.WriteLine(process.ExeFile);
}

The call to Toolhelp.ProcessEntry.GetProcesses() returns an array of ProcessEntry objects. You can then kill the process, get the process id, get the associated modules, get the base address, thread count etc..

The smart way to removing multiple memory applet references in Windows Mobile

I wrote an article recently to get over the problem of multiple references to an application in Windows Mobile memory applet when loading multiple forms here.

Thanks to monxalo's suggestion to using extension methods support in the .NET 3.5 we can design a more elegant solution.

I just created a simple class named FormExtensions in my UI namespace with the following code:

public static class FormExtension
{
    public static DialogResult ShowDialog(this Form owner, Form form)
    {
       form.Owner = owner;
       return form.ShowDialog();
    }
}

Nothing too complex here. So in our client code where we would normally load another form we could now code something like the following:

private void OnButtonClick(object sender, EventArgs e)
{
   this.ShowDialog(new Form2());
}

This assumes the FormExtensions class is in the same namespace as the UI layer. If not you'd have to fully qualify the extension class. I recomend putting it in the same namespace as the UI though.

A couple Windows Mobile Developer resources

The Windows Mobile Developer Center has recently had a lick of paint, worth a look and worth bookmarking as there is a lot of information here: http://msdn.microsoft.com/en-gb/windowsmobile/default.aspx

Another site worth looking at is the Windows Mobile Developer Network: http://www.microsoft.com/windowsmobile/en-us/developers/default.mspx. This site also contains many RSS feeds and useful info.

Lastly but not least, here is a link to a page on the Windows Mobile Developer Center that lists many Windows Mobile blogs and wikis: http://msdn.microsoft.com/en-gb/windowsmobile/bb264323.aspx

CA1502 Microsoft.Maintainability - .NET Compact Framework 3.5 Func to the rescue...

If you are using the Microsoft .NET Compact Framework 3.5 no doubt you have encountered the new Func delegate as luckily for us device devs, Func is supported on the CF. Pretty much the whole of LINQ uses Func’s and lambdas to get the job done.

In addition, if you are using Code Analysis in Visual Studio (FxCop) then you might have encountered the following error: CA1502: Microsoft.Maintainability : Function has a cyclomatic complexity of n. Rewrite or refactor.

You might get this if you have written some code like in this article: http://social.msdn.microsoft.com/Forums/en-US/vstscode/thread/16fdc314-4719-47da-9cb3-2877f29a47b9/

Typical if/else/if/else/if/else drives developers mad. In that link about, the developer has 26 if’s!!

I’m one of those developers that dislikes this type of code. It’s really hard to read and maintain, which is why FxCop is complaining about it.
But as with everything, there is a simple solution and now Func makes this easier for us. I decided to knock up a quick solution to this.

So as per the post above, we have our context class, and the idea behind this code is to set the constructor with a different strategy type based on the passed string (just as the dev requires in the post). So we have our dummy Context class and it looks like the following:

public class Context
{
    private readonly Strategy _strategy;
    public Context(Strategy strategy)
    {
        _strategy = strategy;
    }

    public Strategy Strategy
    {
        get
        {
            return _strategy;
        }
    }
}

Now for the Strategy types, the dev in the article has 26 of these, but for simplicity, I’ve just created 3, but you get the idea, the code is very easily extended:

public abstract class Strategy
{
}

public class Strategy1 : Strategy
{
}

public class Strategy2 : Strategy
{
}

public class Strategy3 : Strategy
{
}

Now for getting the context, I’ve created a static factory class that returns a context based on a string passed to it:

public static class ContextFactory
{
    private static readonly Dictionary<string, Func<Context>> 
     dictionary = new Dictionary<string, Func<Context>>
     {
         {"1", () => new Context(new Strategy1())},
         {"2", () => new Context(new Strategy2())},
         {"3", () => new Context(new Strategy3())} 
     };                                                                  

     public static Context CreateContext(string name)
     {
        if (string.IsNullOrEmpty(name))
            throw new ArgumentNullException("name");

        return dictionary[name]();
     }

     public Strategy Strategy
     {
         get
         {
             return _strategy;
         }
     }
    
}

So that's the complete example. Calling the code is done as follows:

Context context = ContextFactory.CreateContext("3");

If you run that code and inspect the Strategy property, it will equal Strategy3.

So lets explain the code abit. Instead of having lots of conditional if/else/if/else statements to figure out what name is equal to, we have created a generic dictionary class, where the key is the identifier that identifies the type we want passed to the Context constructor. The value is to set the the new Func delegate that allows us to execute the code the we want for the passed key. We use the Func so that we return the specified type.

So the line:

return dictionary[name]();

is essentially executing the delegate for the dictionary item "name". We would need to check if the item exists in a real world example and throw a meaningful exception in this case. This was left out to clarify the code.

In addition, FxCop is happy no matter how many items we add to our dictionary.