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 DevelopmentUnmanaged 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 FrameworkThe 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:
- This gives a developer more RAM for his/her applications and also more flash storage
- 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.
- 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 versionThere 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 InvocationBecause 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 EmulatorsDevice 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 SDFOpenNETCF 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 CEThere 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 devicesThere 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 CEThere are a few options of relational database management systems when it comes to mobility. The options are as follows:
- SQL Server Compact
- Sybase IAnywhere
- SQLite
- 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 versionThe 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 MobilerMy 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 ToysWindows 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 ToolThe
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 DevelopmentRecently 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.
SummaryThere are probably more tools that I have forgotten about but when I remember, I'll add them.
