In The Hand Ltd today released Networking In The Hand, a developer library for the .NET Compact Framework 2.0 and 3.5 Beta. This library adds additional networking functionality not found in in the Compact Framework while matching the object model used in the full .NET framework to make it easy to share your code between platforms. Functionality includes:-

• InTheHand.Net.WebClient - Provides helper methods for working with information upload and download over HTTP and FTP transports, and any other WebRequest based implementations.
• InTheHand.Net.FtpWebRequest - Provides a complete desktop compatible implementation of the WebRequest pattern for FTP.
• InTheHand.Net.WebRequestMethods - Provides a reference of all the HTTP and FTP methods (GET/POST etc)
• InTheHand.Net.NetworkInformation.Ping - Perform a Ping and determine network availability and performance.
• InTheHand.Net.NetworkInformation.IPGlobalProperties - Retrieve a wide range of networking statistics to measure traffic and help identify faults.

The library is licensed on a per-developer basis with no additional royalties required to distribute the runtime with your applications. Full details on the product can be found on the product details page - http://inthehand.com/content/Networking.aspx. A fully functionality Evaluation version is available to download - http://inthehand.com/files/folders/evals/entry4014.aspx.

Stephen Fry, intellectual and comic hero has not only started blogging, but started talking about mobile devices. Definitely worth a read.

(from Dave Sussman)

There are videos and photos doing the rounds from a new spoof information site for Windows Mobile which takes a light-hearted look at mobile working. Why not take a look?

Late last week HTC quietly released the Windows Mobile 6 upgrade for the S620. A few eagle eyed bloggers posted about it. The first thing I found was that the upgrade process doesn't work with Windows Vista, when it reboots the device into bootloader mode the computer fails to connect. I had to run the upgrade from a Windows XP machine (where it worked flawlessy). Upon rebooting I had a fresh clean Windows Mobile 6 device. I noticed that HTC had left the default "Mobile Operator" screen during boot up, only after running its initial setup was this removed. Everything was working great, I was able to setup my exchange server in ActiveSync and get all my PIM data back onto the device. The lock dialog is slightly altered in this release, rather than tapping the right softkey to cancel you have to tap the right soft-key to open the menu and select the second option (option 1 is "Reset Password" but is disabled). The reason I often cancel this screen is because I just want to check the home screen for the time / next appointment. The time can optionally be displayed on the unlock screen but only for the key lock, I no longer use that because my exchange provider enforces a password.

There are a few fancy UI features, the improvements to the calendar day screen are welcome along with the ability to edit task items. Essentially there are few differences to Windows Mobile 5.0 in the look and feel and layout of start menu and applications. One interesting change is that the alarm can now be set to operate only on weekdays, or every day. It's still not as flexible as other approaches, and the default sound applied to the alarm is rather alarming to say the least!

With my initial success I then tried docking the device with my main Vista machine. On this machine I'm running the latest Windows Mobile Device Center 6.1. When I connected the S620 popped up a message telling me to upgrade to ActiveSync 4.5 or later on my PC. Fellow MVP Jaap van Ekris was able to point out a simple workaround. Just go to Start > Settings > Connections > USB to PC and uncheck "Enable advanced network functionality". It now partners correctly with my Vista machine.

In November Microsoft will be hosting the twin conferences of Tech Ed Developers and Tech Ed IT Forum in Barcelona. Tech Ed Developers runs the week of 5th to 9th and covers 14 different tracks, one of which is Mobile & Embedded. This will cover the latest versions of all of Microsoft's Mobile & Embedded products from the .NET Micro Framework through to Windows Mobile, Windows Embedded CE and Robotics studio, and of course the .NET Compact Framework.

This year I'll be delivering a session on networking technologies available to Windows Mobile developers. This will cover a broad spectrum from personal area networking (Bluetooth and IrDA) through to cellular network specific (SMS, GPRS etc) and internet standards (FTP, HTTP etc). We will look at which technologies are appropriate for which scenarios, the relative costs and how to implement them. It's going to be an interactive session and will include plenty of code snippets and an interactive demo or two.

My co-authors Andy Wigley and Daniel Moth will also be delivering sessions in the Mobile & Embedded track and we plan to get together for a book signing during the event. Registration for the conference is available with a €300 off the full price until 28th September.

Following on from the developer contest I mentioned a while ago, Motorola are running a series of developer summits later this year. They will be covering development across their range of platforms and devices, including Windows Mobile. They will have a UK event in London on the 9th of November, which conflicts with Tech Ed Developers 2007 in Barcelona which I'm already committed to - more details on that to follow...

Full details - MOTODEV Summit

In .NETCF v3.5 there is a new namespace - System.Media which brings audio support to the Compact Framework. Previously the common way to add sounds to your application was to use the PlaySound API (either P/Invoking yourself or using one of many wrappers). Now that the framework itself has built-in support, which matches the desktop .NET v2.0 framework it makes sense to standardise on the SoundPlayer component.

There are some differences in behaviour which you'll need to be aware of. When you specify a filename this doesn't simply call through to the native APIs passing the filename, the file is first loaded into memory and then the WaveOut APIs are used to play it. This means that if you simply create a new SoundPlayer and call Play the file will not be loaded, the Play method will have to first load the file contents, and then play the sound. This will create a noticable delay before the sound is heard. The class allows you to load the file at any time prior to calling play - you can use either Load or LoadAsync to do this. Once the file is loaded the Play method will be able to immediately begin playing the file. Exactly where you call the Load/LoadAsync method will depend on your application design. Keeping a large audio file cached will tie up valuable memory, you should dispose of the SoundPlayer instance once you have finished with it.

Among the Configuration providers in Windows Mobile is one which allows you to programmatically uninstall package from the device. The UnInstall provider is documented here:-

http://msdn2.microsoft.com/en-us/library/aa455977.aspx

To see if your package can be uninstalled you send the following XML - e.g. using DMProcessConfig.XML or ProcessConfiguration in managed code.

<wap-provisioningdoc>
   <characteristic type="UnInstall">
      <characteristic-query type="YourAppName"/>
   </characteristic>
</wap-provisioningdoc>

Replacing YourAppName with the name of your installation package usually "CompanyName Product" as defined in your device CAB project. The response will look something like this if the package name is found:-

<wap-provisioningdoc>
   <characteristic type="UnInstall">
      <characteristic type="YourAppName">
         <parm name="uninstall" value="0"/>
      </characteristic>
   </characteristic>
</wap-provisioningdoc>

Then you can uninstall the package using:-

<wap-provisioningdoc>
   <characteristic type="UnInstall">
      <characteristic type="YourAppName">
         <parm name="uninstall" value="1"/>   
      </characteristic>
   </characteristic>
</wap-provisioningdoc>

In March I showed how to get the version of a connected device from the desktop. This post documents the rest of the registry settings used to store device information. There are two registry locations, the first at HKEY_CURRENT_USER\Software\Microsoft\Windows CE Services contains information about the currently connected device. The second, HKEY_CURRENT_USER\Software\Microsoft\Windows CE Services\Partners contains information for each of the partnerships established on the desktop PC.

When the device is docked, regardless of whether a partnership is established, the following keys are populated in HKEY_CURRENT_USER\Software\Microsoft\Windows CE Services:-

• DeviceHardwareId -String containing a unique Guid for the device
• DeviceOemInfo - OEM specific string (as returned by SystemParametersInfo using SPI_GETOEMINFO) e.g. WIZA200 (HTC Wizard)
• DeviceProcessorType - DWORD value - 2577 (ARM) for all Windows Mobile devices
• DeviceType - string containing platform type (as returned by SystemParamtersInfo using SPI_GETPLATFORMTYPE) e.g. PocketPC or SmartPhone
• DeviceVersion - DWORD value - see my previous post.

The partnerships are stored with a unique DWORD partnership id e.g.

HKEY_CURRENT_USER\Software\Microsoft\Windows CE Services\Partners\12345678\

There are additional values to describe sync behaviour and some Windows Mobile Device Center specific values e.g. to specify the display icon for a device. Otherwise all of the above values are duplicated here for the partner device, except with some naming differences:-

• DeviceHardwareId
• OemInfo
• ProcessorType
• DeviceType
• Version

Each partnership has a directory containing any resources used, this includes the icon etc. The path is retrieved from the DataFolder value. This is a path beneath the users roaming application data folder which you would get using System.Environment.GetFolder(System.Environment.SpecialFolder.ApplicationData)

The icon is specified in DeviceIconFile and if you append this to the path you'll have the full filename of the icon.

Windows Live Folders is now Windows Live Skydrive and the beta has been extended to locales outside the US. The service provides a free 500mb of online storage for you to use however you want. Beyond the new look and feel and new name there is one great addition - a drag and drop upload tool which makes it much easier to upload multiple files. Previously you had to browse for files individually and upload in batches of 5. This is a great addition to the other Live services and gives you somewhere handy to store your own files online, as well as share public files with others.

On the newsgroup somebody asked how to have multiple lines of text on a .NETCF Button control. The native control supports this but the appropriate style is not set by default. The following code snippet shows how to enable this:-

private const int BS_MULTILINE = 0x00002000;
private const int GWL_STYLE = -16;

[System.Runtime.InteropServices.DllImport("coredll")]
private static extern int GetWindowLong(IntPtr hWnd, int nIndex);

[System.Runtime.InteropServices.DllImport("coredll")]
private static extern int SetWindowLong(IntPtr hWnd, int nIndex, int dwNewLong);

public static void MakeButtonMultiline(Button b)
{
    IntPtr hwnd = b.Handle;
    int currentStyle = GetWindowLong(hwnd, GWL_STYLE);
    int newStyle = SetWindowLong(hwnd, GWL_STYLE, currentStyle | BS_MULTILINE);
}

The usage is simple, just pass the specific Button control to MakeButtonMultiline:-

Every version of POOM (Pocket Outlook Object Model) brings great improvements, however there are always a few things which just have you screaming "Why!". One of those examples is the implementation of IItem::Edit. This method is used to open an item in edit mode, and is implemented on Windows Mobile 5.0 and above, with the exception of Appointments on Smartphone (Standard) devices. This makes no sense because otherwise the Appointment item follows the same pattern as the other item types. A dialog is implemented on the Smartphone/Standard platform and this has a perfectly usable edit screen - why this wasn't implemented in the API beggars belief. Below is a table of supported configurations for the various display methods:-

*WM5.0 Smartphone Tasks application doesn't support editing

I'm now a member of the CodePlex workspace for the Facebook Developer Toolkit. I've been working on porting across my modifications into the codebase. The .NETCF v2.0 version uses a project called Facebook.Compact but refers to the existing source files from the desktop project. Then some conditional compilation is used to hide a few unsupported features from .NETCF and implement some workarounds for missing functionality. This will be a familiar technique if you've been to Daniel's sessions (or read his blog posts on the subject). It's not quite working yet since my code made use of a couple of my own libraries for speed, so I'll need to implement a few of the features within those in the Facebook.Compact project.

The Facebook API allows third-party web and desktop applications to interact with Facebook features. There is an excellent shared-source library for .NET to wrap the Facebook calls but currently it only supports the full framework. I did some work converting this source to compile and run on .NETCF v2.0. There are some example screens here of the login process, and pulling back information about our book group.

Since the login screen uses the same page as the desktop it's not a great fit on a Pocket PC screen, so that's an area for improvement.

As I walked to the local Tesco's to pick up something to eat for lunch today it was, unsurprisingly, raining steadily. Keeping my head down and a stiff upper lip etc I kept going. As I looked down at the pavement to avoid the puddles I spotted a metal drain cover with the words "Wash Out" on it. This basically sums up the summer so far...

(When the weather is slightly more clement I plan to take a camera out and get a picture for my collection)

One of the features of Mobile In The Hand is the ability to add context menu extension handlers for the PIM applications from managed code. One of the problems with implementing this feature is that the behaviour of these applications varies subtly between versions and these differences are rarely documented from the developers perspective.

One of these issues is the way that context menu extensions work with regard to multiple item selection. In Windows Mobile 2003 the Tasks and Contacts applications allow the user to select multiple items on Pocket PC using the stylus. When the context menu extension is called you can get the Oids of all the items selected. However in Windows Mobile 5.0 the Contacts user interface was changed and no longer supports multiple selection, but Tasks still behaves as before (Tasks has always been the neglected application of Pocket Outlook - just look at how limited Tasks was on Smartphones prior to Windows Mobile 6 Standard). However if you select multiple tasks on Windows Mobile 5.0 or 6 the context menu will only get the Oid of the first item. You therefore need to set your (and your users) expectations when using Context Menus within your solutions.