Archive for 2007

Beginnings of a 70-540 Study Guide

Wednesday, July 18th, 2007

Late last year I sat and passed the Microsoft Certified Professional exam 70-540 while it was in beta form. Passing the exam is enough to qualify for the Microsoft Certified Technology Specialist: Windows Mobile 5.0 Application Development certification.

While I was studying for this exam there was little study material available. The recent posting on handling the Software-based Input Panel was the start of a series of posts which I hope will act as suitable study material for those wising to take the 70-540 exam. Over time I plan to update an index of relevant posts on the 70-540 Study Guide page within this blog.

If anyone is interested in discussing the 70-540 exam or has feedback on how I could improve the suitablity of study material presented in this blog please feel free to get in contact with me.

For those interested in starting to study for this exam I would recommend to start out by:

Detecting button presses

Tuesday, July 17th, 2007

My post introducing the .NET Micro Framework covered how to use the OutputPort class to interface to a single GPIO output pin as part of an example to blink a LED.

The matching class to interface to a GPIO input pin, is not too surprisingly called the InputPort class. The InputPort class functions very similar to the OutputPort class discussed last time, in fact they share a common base class.

The constructor for the InputPort class has a couple of additional parameters, in addition to the one which specifies which GPIO pin it should be connected to.

The first is a boolean parameter which enables a glitch filter. Mechanical switches can be “noisy”, meaning that a single press by the user could translate into multiple open and close events, which digitial hardware can potentially detect. This problem is commonly refered to as Contact Bounce or Switch Debouncing. At this stage I have not current managed to find out what technique the .NET Micro Framework utilises for glitch filtering, or even if this is device specific (I suspect it is).

The second parameter is of much more interest, since it deals with setting the type of internal pull up resistor present on the GPIO pin. It can have one of following values from the ResistorMode enumeration:

  • ResistorMode.PullUp – A resistor internal to the CPU is connected between the GPIO pin and VCC, i.e. the pin is pulled up to the positive supply rail.
  • ResistorMode.PullDown – A resistor internal to the CPU is connected between the GPIO pin and GND, i.e. the pin is pulled down to ground.
  • ResistorMode.None – no internal resistor is enabled. In this mode if a pin is left unconnected, it could produce spurious readings due to noise induced into the pin.

The pull up and pull down resistor modes can be handy when interfacing to external hardware, in particular push buttons. By relying upon the internal pull up or pull down resistors, you can get by without requiring additional components, as shown in the following schematics.

Schematic showing pull up and pull down resistor configurations for push button interfacing

It is important to note that if a push button is connected with a pull up resistor, it’s logic levels will be inverted. I.e. the GPIO pin will read a logic high (true) logic level when the push button is not pressed, and will read a logic low (false) logic level when the push button is pressed.

Code Sample
Here is a sample program which will write a message to the debug window each time a push button connected to the GPIO_Pin3 pin is pressed.

To reduce the amount of log messages written to the Visual Studio output window, we only sample the push button once every second. This means we do not need to enable the glitch filter because we are sampling it at a slow enough rate that it should not be a significant issue.

using Microsoft.SPOT;
using Microsoft.SPOT.Hardware;
using System.Threading;
 
namespace InputTestApplication
{
  public class Program
  {
    public static void Main()
    {
      // Monitor the "select" push button
      InputPort button = new InputPort(Cpu.Pin.GPIO_Pin3,
         false, Port.ResistorMode.PullDown);
 
      while (true)
      {
        // Test the state of the button
        if (button.Read())
             Debug.Print("The button is pressed");
 
        // Wait 1 second before sampling the button again
        Thread.Sleep(1000);
      }
    }
  }
}

NOTE: The GPIO pin used for this sample program has been selected for use with the .NET Micro Framework Sample Emulator. If you attempt to run this application on your own .NET Micro Framework module, you may need to adjust the GPIO signal utilised to suit your hardware.

Push Buttons within the Emulator
The “Sample Emulator” released with the .NET Micro Framework SDK has 5 push buttons “wired up” into a D-PAD configuration.

An interesting aspect to the emulated hardware is that the push buttons can be made to act as if there were wired up with pull up or pull down resistors (as outlined above) depending upon the state of the ResistorMode parameter passed into the constructor of the InputPort instance which accesses them. Typical hardware wouldn’t have this flexibility, with the incorrect ResistorMode choice potentially rendering a push button unreadable.

The mapping of emulator buttons to GPIO pins for the Sample Emulator is as follows:

  • Select – GPIO_Pin3
  • Up – GPIO_Pin2
  • Down – GPIO_Pin4
  • Left – GPIO_Pin0
  • Right – GPIO_Pin1

The code sample provided in this blog posting constantly polls the state of the push button. This is not power efficient. It is better to request that the hardware notifies you whenever the GPIO pin changes state. Next time I will discuss how you can use the InterruptPort class to achieve this.

Manage soft input panel (SIP)

Sunday, July 15th, 2007

One final finishing touch to Windows Mobile applications is the proper handling of the Software-based Input Panel (SIP), this can help differentiate your application, and thus your company as one which truely understands the Windows Mobile platform.

The software-based input panel (also known as the popup or software keyboard) allows touch-screen enabled devices that do not have a hardware keyboard to simulate keyboard input by using an onscreen keyboard.

The SIP is a common piece of UI, which enables the use of one or more Input Methods (IMs). Standard Input Methods include Keyboard, Transcriber and Block Recognizer, but additional OEM specific IMs may be included on a given device.

This architecture is extendable, and third parties can create their own IMs by implementing a COM object, as outlined in the book Prorgraming Microsoft Windows CE, Second Edition (see the free sample chapter for step by step instructions). One interesting third party input panel is the Smilies Input Panel by Yin-See Tan which is designed to help users enter similies into MSN messenger.

Tight integration of the SIP within your application typically boils down to handling two scenarios well:

  • Automatically displaying the SIP when keyboard focus passes to a control which requires keyboard data entry.
  • Ensuring all controls are accessible when the SIP is visible.

SIP support within the .NET Compact Framework
Within the .NET Compact Framework the software-based input panel is wrapped up by the Microsoft.WindowsCE.Forms.InputPanel class, which is present in the Microsoft.WindowsCE.Forms.dll assembly.

In order to interact with the software-based input panel, the user can drop the InputPanel component from the Visual Studio toolbox onto a form. A reference to the Microsoft.WindowsCE.Forms.dll assembly will be added automatically to your project.

Most applications utilising the InputPanel component will make use of the following four members of the class.

  • Enabled – A boolean property. If true the SIP is visible (on the screen), if false the SIP is hidden.
  • EnabledChanged – An event which fires whenever the Enabled property changes value.
  • Bounds – A rectangle detailing the amount of screen real estate the current input method occupies.
  • VisibleDesktop – A rectangle detailing the maximum size the current screen real estate the form can cover without being partially covered by the SIP.

Automatic SIP Popup
Within the .NET Compact Framework the easiest way to automatically display the Input Panel is to explicitly enable and disable the input panel whenever a control which requires keyboard focus is activated.

private TextBox txtUserName;
 
private void Form1_Load(object sender, EventArgs e)
{
  txtUserName.GotFocus += txtUserName_GotFocus;
  txtUserName.LostFocus += txtUserName_LostFocus;
}
 
private void txtUserName_GotFocus(object sender, EventArgs e) 
{ 
   // Show the input panel
   inputPanel1.Enabled = true; 
}   
 
private void txtUserName_LostFocus(object sender, EventArgs e) 
{ 
  // Hide the input panel
  inputPanel1.Enabled = false; 
}

Notice: Usually the event hook up code shown within the Form1_Load event handler would occur within the designer generated code. It is only shown here to aid in understanding how this sample code functions.

Dynamic Dialog Layout
Since the SIP is displayed on screen it covers part of your form when visible and potentially makes some of your controls inaccessable. A quality application will alter the layout of its form when the SIP becomes visible to ensure all controls are accessible at all times. There are numerious techniques that can be utilised to achieve this goal.

Technique One:
One approach is to listen to the InputPanel’s EnabledChanged event. This event will trigger whenever the SIP’s visibility changes. Within the event handler we can move controls around to ensure that they are visible within the current space available to the form.

private void InputPanel1_EnabledChanged(object sender, EventArgs e) 
{ 
  int y;
 
  if (inputPanel1.Enabled)
    // SIP visible - position label just above the area covered by the input panel  
    y = Height - inputPanel1.Bounds.Height;
  else
    // SIP not visible - position label just above bottom of form
    y = Height;
 
  // Calculate the position of the top of the label
  y = y - lblMessage.Height;
 
  lblMessage.Location = new Point(0, y);
}

This approach is the most flexiable, but it can become tricky depending upon the number of controls which need to be moved around. Coordinate calculations are never fun, especially when multiple device resolutions etc have to be taken into account.

Technique two:
Another technique which doesn’t involve explict coordinate calculations is to take advantage of the Docking and Anchoring functionality present with .NET Compact Framework v2.0.

The trick is to dock a control to the bottom of the form, and to resize this control’s height to match the current height of the SIP. This has the effect of pushing the rest of the content docked to the bottom of the form to be above the SIP.

This approach is shown in the following example:

private void InputPanel1_EnabledChanged(object sender, EventArgs e) 
{ 
  // Resize the panel docked to the bottom of the form to be
  // the same height as the SIP. This moves other controls also
  // docked to the bottom of the form to be above the area covered
  // by the SIP.
  SuspendLayout();
  panelSIP.Visible = inputPanel1.Enabled;
  panelSIP.Height = inputPanel.Bounds.Height;
  ResumeLayout();
}

This approach can also be extended to cope with larger forms, where the only real solution is to place a vertical scroll bar onto the form. If all the controls are placed onto a panel, you can configure the panel by setting the following properties:

  • AutoScroll – true
  • Dock – fill

With these properties set, you will find a vertical scrollbar automatically appears when required (due to the SIP becomming visible).

An added finishing touch to this technique is to ensure that any controls on the right hand side of the form has the Anchor property set to “Right”. This ensures that the controls are not obsecured by the vertical scrollbar when it is present.

Selecting Input Methods
The InputPanel component can also be used to enumerate a list of available Input Methods, and to determine which one is currently active.

// List the name and class id of each input method
// registered on this device
foreach (InputMethod im in inputPanel1.InputMethods)
{
  MessageBox.Show(im.Name, im.Clsid.ToString());
}
 
// Display the name of the currently active input method
InputMethod currentIM = inputPanel1.CurrentInputMethod;
MessageBox.Show(im.Name, "Current Input Method");

The InputMethod class is a simple key, value pair containing the name of the Input Method (a string shown in the SIP popup menu), and the matching class id. Class identifiers are a COM specific concept which uniquely identify different types of object, and since the software-based input panel architecture is COM based, each input method can be uniquly referred to by its clsid value.

Code Sample
A sample project which demonstrates all the techniques discussed in this article is available for download, and should help clarify the behaviour of the InputPanel control.

VB.NET and InputBox()
Recently a software-based input panel related question came up within an online forum I participate in. As part of answering the question I learnt of a VB.NET function called InputBox. InputBox is a function which provides a basic data entry mechanism, similar to how MsgBox displays simple messages to the user.

It turns out that Microsoft’s implementation of InputBox does not deal with dynamically moving the OK and Cancel buttons around to ensure that they are visible if the software-based input panel is visible. It also does not look too nice on VGA resolution devices.

I have written a replacement InputBox implementation which resolves these issues. My new and improved InputBox, including a sample project is available for download. I hope this control is of use to those wising to utilise InputBox within their applications.

Introduction to the .NET Micro Framework

Sunday, July 15th, 2007

As I mentioned in an earlier posting I have started to become interested in Microsoft’s latest EMCA Common Language Infrastructure (CIL) implementation, aka the .NET Micro Framework.

The .NET Micro Framework is designed for devices where even the .NET Compact Framework requires too many system resources to be feasible. It’s original design specification was to run on a custom ARM7 ASIC running at 27Mhz with 512KB ROM, 384 KB RAM and 8KB EEPROM, without an form of Operating System.

Operating Environment
One feature that makes the .NET Micro Framework unique is it’s ability to optionally run on hardware directly without the need for a traditional operating system. This is achieved by providing two levels of integration within the porting kit utilised to port the .NET Micro Framework to a new device. An OEM may decide to provide support for the .NET Micro Framework, by hooking in at one of two levels, depending upon the capabilities of their device:

  • Platform Adoption Layer (PAL) – This layer is a high level interface which provides a set of high level primitives such as timers, memory management and data structures. These are typically features provided by a host operating system, leading to a reasonably transparent PAL being developed by the OEM.
  • Hardware Abstraction Layer (HAL) – If no host operating system is in use on the target device, the OEM can utilise a standardised PAL, which hooks into the functionality provided by a hardware abstraction layer. The HAL provides a standardised interface to low level hardware features such as GPIO signals, interrupt handlers and power management etc, which the PAL uses to implement it’s own OS like functionality.

Implementing a Hardware Abstraction Layer can lead to the situation where the .NET Micro Framework is running directly on the CPU as the only “process”.

Compilation Process
Another unique feature of the .NET MIcro Framework, is that it has no Just In Timer (JIT) compiler. The framework instead interperts the MSIL bytecode, in a similiar manor to Mono’s mint interpreter.

Similar to the Java Micro Edition platform, the standard bytecode format utilised on the desktop is not understood by a .NET Micro Framework device. Instead, as part of the compilation process, the bytecode is passed through a pre-verification and optomisation stage, which produces an optimised representation of the bytecode understood by the .NET Micro Framework device.

Hello World – Software Developer style
The traditional first program for a software developer learning a new language or development environment is to write an application which simply prints “Hello World” and then exits. This tradition has it’s roots in an example provided in a book called “The C Programming Language” and was apparently sourced from a 1974 Bell Laboratories internal memorandum written by Brian Kernighan (one of the book’s authors).

Within the Visual Studio 2005 environment for the .NET Micro Framework, a Hello World application may be written as follows:

using Microsoft.SPOT;
 
namespace HelloWorldApplication
{
  public class Program
  {
    public static void Main()
    {
      Debug.Print("Hello World!");
    }
  }
}

The Microsoft.Spot.Debug class is somewhat similiar to the System.Diagnostics.Debug class present in the full framework in its intent.

The Debug.Print method can be utilised to emit a string to the standard output stream, which by default is routed to the Visual Studio IDE from the development board while debugging an application.

This code sample is fairly similiar to that produced by the Micro Framework Console Application project wizard within Visual Studio 2005. The main difference being that the project wizard emits code which utilises a string resource to store the string, this aids in internationalisation of the application.

Hello World – Hardware Engineer style
The equvialent to a “Hello World” application for a hardware engineer bringing up a new microprocessor based board is to flash a LED connected to a GPIO pin.

using System.Threading;
using Microsoft.SPOT.Hardware;
 
namespace HelloWorldApplication
{
  public class Program
  {
    public static void Main()
    {
      // The LED is hooked up to GPIO Pin 1. The second parameter
      // within the constructor indicates to set the pin to logic high
      // initially
      OutputPort led = new OutputPort(Cpu.Pin.GPIO_Pin1, true);
 
      while (true)
      {
        // Sleep for 5 seconds (5000 ms)
        Thread.Sleep(5000);
 
        // Toggle the state of the LED
        led.Write(!led.Read());
      }
    }
  }
}

NOTICE: If you attempt to run this sample application on actual hardware, you may need to alter the GPIO Pin assignment to suit your hardware, and add a reference to a device specific assembly.

The Microsoft.Spot.Hardware.OutputPort class accesses a specified pin on the physical hardware and can toggle the pin between the high and low logic levels.

The Read() method queries the pin for it’s current state, while the Write(bool) method allows the user to explicitly set the pin’s current state. For those familiar with traditional Micro-controller firmware development, you will notice that the hardware is accessed in an abstracted sense, where all the bit twiddling typically required to set or reset a single GPIO pin is hidden behind the scenes. This makes for a nice portable application, but is not suitable in applications which need precise real time functionality etc.

Trivia
I initially wondered why the .NET Micro Framework related classes were in namespaces starting with Microsoft.SPOT. SPOT which is an acronym for “Smart Personal Object Technology”, was the Microsoft Research project which initially produced the technology that became the .NET Micro Framework. The Microsoft SPOT group developed a range of devices, with the most well known probably being the smart watch.

One of the proof of concepts the research team produced was a tiny CLR to allow a managed software development environment for their projects. They named the initial namespaces after their group, since this was a technology for internal use only. When it was decided to commercialise the .NET Micro Framework as a seperate product, they decided to keep the namespaces, since a number of internal and external projects were already using them and it helped with backwards compatibility.

I also assume this is why what appears to be the first publically available version of the .NET Micro Framework is versioned as version 2.

It’s a small world after all

Sunday, July 15th, 2007

I have been subscribed to Dale’s blog for the last few days. His blog contains an interesting mix of technical information and ???? about his volunteer work.

Today I was surprised when his post “Windows Mobile has a ‘Run…’ dialog” made reference to my blog. This was a nice warm fuzzy when I stumbled upon it.

It is quite bizarre how small the world is. What are the odds of me finding his blog, and him finding my forum posts within a few days of each other? I would imagine in a world of 6.6 billion people, it would be quite, small.

This is one of the main reasons I started helping out on the MSDN forums, and started my blog, I want to connect with other software developers through-out the world, and share my knowledge, in the hope that it helps others. It is my way to contribute back to the community.

It has also given me an idea for an extra category of posts I can blog about. I am going to start a new category of posts, which briefly cover hidden features (or atleast not well known ones) of Windows Mobile. I will start off by re-blogging the tip I posted to MSDN Forums which Dale found useful.

Development Tools for Windows Mobile Devices

Sunday, July 8th, 2007

Photo of box for Microsoft Windows CE Toolkit for Visual C++ 6.0 productA common question asked in online support forums is which version of Microsoft development tools are required for a device powered by a particular version of Windows Mobile. With the pace technology is changing, there are numerous Microsoft products which can be utilised to develop mobile applications.

Native Development
If you are developing in native code (C or C++) you have a number of choices. Back in the early days (before Pocket PC or Windows Mobile), development was achieved via an extension to the desktop version of Visual Studio 6.0. This extension was called the Microsoft Windows CE Toolkit for Visual C++ 6.0.

The first Microsoft development environment targeted specifically for mobile developers was called Embedded Visual C v3 (EVC3). This IDE was specifically designed for developers working on Windows CE and Pocket PC devices. The functionality and UI was very similar to Visual Studio 6.0, but was slightly extended to support development against multiple device types and deployment/debugging on actual devices. Embedded Visual C version 3, via the installation of additional SDKs supported producing applications for Pocket PC 2000 and 2002 devices as well as older Handheld PC (HPC) and Palm PC platforms.

The next upgrade was to Embedded Visual C v4 (EVC4) which was released in 2003, and only supports Windows Mobile 2003 devices. This is not to say that applications developed with EVC3 would not run on Windows Mobile 2003 devices, the Windows Mobile operating system is highly backwards compatible, meaning that applications developed for previous versions of the operating system will in most cases still run on newer versions of the operating system unmodified.

However developing applications for newer versions of the operating system using older tools which don’t explicitly support them has two main problems.

  • Lack of debugging and deployment support – you can compile applications which will run on the new operating system version, but the IDE will not be able to automatically deploy your application to a device, and you will not be able to debug your application running on a real device.
  • Lack of access to new APIs and features – For example Windows Mobile 2003 SE introduced dynamic screen orientation support (toggling between landscape and portrait), but if you use EVC3 and utilise the Pocket PC 2002 SDK you will not have easy access to the APIs which support this, since the Pocket PC 2002 header and library files will not include the information required to use them.

EVC3 and EVC4 are very old tools, which are reasonably unsupported by Microsoft at this stage. EVC3 is effectively unsupported and EVC4 is very close to being near the end of it’s mainstream support life-cycle (see Microsoft Support Lifecycle for Development Tools page for further details). They are fairly non functional under Windows Vista for instance, with Microsoft’s recommended practice being to use the tools within a Virtual Machine running a copy of Windows XP, which has its own problems.

The replacement for Embedded Visual C has been Visual Studio 2005. Visual Studio 2005 is the first version of Visual Studio .NET which has included support for C and C++ development for smart devices, which is Microsoft’s current term for PDAs and embedded devices running Windows CE. While EVC3 and EVC4 were available as free downloads, Smart Device development is not available in the free versions of Visual Studio (such as Visual Studio 2005 Express), meaning developers must purchase a copy of Visual Studio 2005 Standard or higher to develop for Mobile devices (see Microsofts’s Product Feature Comparision page for further details on the various SKUs of Visual Studio 2005).

Out of the box Visual Studio 2005 only supports developing applications for Windows Mobile 2003 devices. However additional SDK downloads enable you to develop applications targeting the additional features present in the Windows Mobile 5.0 and Windows Mobile 6 releases of the operating system, with full debugging support etc.

In summary for native development you are best to

  • use EVC3 for Pocket PC 2000, 2002 (and older)
  • use EVC4 for WM 2003
  • use VS2005 for WM2003, WM5.0, WM6

Managed Development
Visual Studio .NET 2002 saw the start of Compect Framework support within Visual Studio. Support was included via an additional download which was called the Smart Device Extensions (SDE) which was only available as a beta. This development environment supported development for Pocket PC 2002 devices which utilised Compact Framework version 1.0.

Visual Studio .NET 2003 was the first version of Visual Studio .NET to officially support the Compact Framework, having the Smart Device Extensions functonality included in the core product. Although it was functional it was not tightly intergrated, for example the GUIs designed in the form designer had little resemblance to the look and feel of the controls used on the actual device.

Visual Studio 2005 introduced a number of improvements for managed developers, as well as a significantly improved forms designer which had the same look and feel as actual devices, it also included additional support for Compact Framework version 2.0, as well as the existing support for version 1.0.

Visual Studio 2008 will support Compact Framework v2.0 and Compact Framework v3.5 which will be released in the same timeframe. For those wondering, there will be no version 3.0 of the Compact Framework. The Compact Framework team decided to skip version 3.0 in order to keep “in sync” with the versioning of the desktop variant of the .NET framework which has already had a version 3.0 release.

In summary for managed development you are best to

  • use VS2005 for CF1.0 and CF2.0
  • use VS2008 for CF2.0 and CF3.5 (when it becomes available)

Summary
Most development tools support atleast two versions of the Windows Mobile operating system. The latest version and the previous one. As new versions of the Windows Mobile devices become available your applications should run on the devices, but you will not be able to debug your applications via the IDE. You will typically need to upgrade to the latest version of Visual Studio for this to function.

The Windows Mobile Team Blog has a posting which manages to condense the information I have outlined here into a neat looking table in a posting titled “Windows Mobile Tool Support Matrix“.

Introductory Compact Framework Presentation – coming soon

Sunday, July 8th, 2007

On August the 8th at 6pm I am presenting at the Christchurch branch of the .NET User Group. I am providing a presentation which is an introduction to development on the .NET Compact Framework aimed at existing desktop developers.

Ths is my first public speaking oppertunity so I am sure closer to the time I will become more nervious etc, but at this stage I am fairly excited about the oppertunity and hope that is is not the last.

If anyone has any tips on public speaking or in creating presentation content I would be glad to hear from them. I like the notes John-Daniel Trask has posted on his blog about his initial experiences in a similiar situation.

Further details, including a registration form should be able to be found on the .NET User Group website within the next few days. I look forward to seeing you there.

Vodafone v1210 – The device which defies description

Wednesday, July 4th, 2007

Vodafone v1210 SmartphoneOne of the disadvanages of leaving Blackbay earlier this year was having to return an iMate KJAM PDA I had been using for a year or so. Wanting to replace my dying personal cellphone I decided I wanted to purchase a Windows Mobile 6 Professional device, the only problem being such devices had only just been announced and devices hadn’t became available yet. What is a geek without geek toys meant to do?

In the end I decided to purchase a Windows Mobile 5.0 smartphone for the short term, to give me time to wait for a desierable Windows Mobile 6 Professional device to reach stores. After some market research I settled on a Vodafone v1210 (also known as a VDA IV) which turned out to be an interesting choice.

Cost
One of the attractive features of the v1210 is the cost. The recommended retail price of $569 NZD is approximately half that of other common PDA devices such as the iMate SP5. This makes it competative against tradditional cellphone offerings from the likes of Sony Ericsson etc. However the decrease in list price didn’t come about by magic, as several interesting design tradeoffs have been made to reach it. These tradeoffs help give this device its character and make it hard to describe.

Connectivity
The phone supports bluetooth 1.2 with a number of profiles that allow use in a number of scenarios (bluetooth headsets, dial up modem scenarios etc).

USB is provided as the primary way to activesync the device to a desktop PC. However it is only USB 1.1 which is slower than the USB 2.0 present on most devices. It does make up for this by theoretically having USB host functionality, a feature not present on almost every other PDA – but more on this later…

The lack of any 802.11 WIFI functionality is a little disappointing. While in Las Vagas earlier this year it would have been very handy. I had forgotten to pack the USB sync cable, and although the place was full of free wifi hotspots, they were not able to be used. Global roaming on the 3G cellular network was going to cost approximately $40 NZD per megabyte which made it too prohibitive to deploy the 6 to 8MB worth of CAB files I desired to deploy to my device, leaving me frustrated that I couldn’t transfer files the couple of inches between my laptop and cellphone.

Another thing which surprised me was the lack of infrared support aka IRDA. Although the device has a user interface setting to “receive incoming beams”, the manual does not mention IRDA at all, and it appears not to be supported. This was a pity as recently I had an opportunity to develop some low level OBEX code, and I was surprised when I couldn’t get this device to cooperate.

User Interface
A smartphone is meant to be a cellphone first, PDA second, while a Pocket PC device is tradditional viewed as having these roles reversed. With no touchscreen and only a numeric keypad for user input the navigation of the smartphone’s user interface is all the more important…

The device has a 2.2″ QVGA (240 x 320 pixel) screen which is very clear and bright to read in most lighting conditions, which gets the device off to a good start.

Most navigation within the smart phone user interface is made via the D-Pad, which is in the center of the buttons above the number pad. Items are selected by pushing in the stick. This works reasonably well, but it can be difficult to accurately select specific icons quickly due to the sensitivity of the D-PAD. An alternative mode of navigation which I got used to very quickly was to use the numeric keypad. When presented with a menu or list of icons you can press the 1 key to select the first entry, 2 to select the second entry and so on. I quickly found this to be the quickest and easiest form of navigation, however it has not been applied consistently throughout the operating system and built in applications. For example it cannot be utilised within Pocket Outlook to switch between SMS folders such as the inbox and sent items etc. These inconsistencies are quite jarring when you are utilising the device, especially in situations where you can not place your full attention on your phone, such as when chatting to others at the same time.

Software Packages
The standard Windows Mobile 5.0 platform for Smartphone does not support Pocket Word, Excel or Powerpoint. To cover this discrepancy the device from Vodafone comes pre-packaged with ClearVue’s document viewer applications for Microsoft Word, Excel, Power Point and Adobe PDF file formats. These are ideal applications for displaying the contents of files emailed to the device etc, but do not provide any ability to author or edit content.

Likewise a licensed copy of Opera’s web browser is included, which some people prefer when compared against the standard Pocket Internet Explorer which is also present.

Special Features
The one thing which defines the Vodafone v1210 is the lack of features and choice of components.

The device uses an Intel PXA270 running at 312Mhz and had 128MB Flash coupled with 64MB RAM. Storage memory can be expanded by a microSD card slot situated underneath the battery compartment (near the SIM card).

No camera means no photo blogging applications are viable, and video calls which are often a selling point for 3G phones are not available. I don’t personally count this as a negative for this device as I haven’t heavily utilised the feature on my earlier PDAs, and on the odd occasion where I have the quality of the pictures has left much to be desired.

One feature which the geek in me was very excited about was the fact that the device apparently has a USB host. This capability should mean that USB pen drives, keyboards, mice and other devices should be able to be connected to the phone, provided you find a suitable USB cable to connect the two devices together. I have a number of interesting electronics projects I would like to investigate if I can succeed in getting this feature working, however so far I haven’t managed this. Although the marketing material, user manuals and device appear to confirm that you should be able to connect a pen drive or keyboard I have not succeeded in getting the device to detect them when connected. Peeking into the windows directory and system registry of the device appears to confirm that the device drivers required for this functionality are present, but to my knowledge no one has got this feature to work, as others have tried and failed as well.

Use as a cellphone
The phone is a GSM tri-band device (900, 1800 and 1900 Mhz) for voice, and GPRS/UMTS (2.5G / 3G) for data. Without a camera the 3G data capabilities are really only of use for internet access, either for built in applications or for when the device is used as a modem for a laptop or UMPC etc.

This device was the first time that I have utilised the Smartphone variant of Windows Mobile operating system outside of the device emulator. My initial opinion is that the operating system is not as polished as some other cellphone operating systems. For example the process of canceling out of creating a text message is kind of naff, until you get the hang of it, requiring a couple of key presses which are not really necessary.

Audio quality etc is about average. My biggest complaint of using the device as a cellphone would have to be volume. The ring tones, alarm and in call audio is quiet even at the loudest volume settings. I find it quite easy to sleep through the alarms for instance, and there doesn’t appear to be much I can do about it at a device wide level.

Other Reviews
A couple of New Zealand bloggers have also written reviews of the Vodafone v12110 including Mauricio Freitas’s review on Geekzone and Lukas Svoboda. Both of these reviews come up with similiar conclusions on this device.

Summary

This is a device which I would definitely purchase again. The device’s price makes it hard to beat at present, and it’s easy to dismiss most of it’s negatives due to this.

Three pluses

  • Low cost
  • Excellent LCD quality
  • Good value added software

Three negatives

  • Very quiet – easy to miss alarms/calls and low battery warnings
  • Lack of knowledge of product within retail stores.
  • Haven’t managed to get USB host functionality working

My experience purchasing this device wasn’t too difficult, but I did struggle to describe to the shop assistant what product I was looking for. After asking if they had any Vodafone v1210s available, I was told “all phones sold here are Vodafone phones, who is the manufacturer of the phone you are looking for?”. Explaining that the phone was branded as a Vodafone device, and it’s ODM was ASUS only made the situation worse. Eventually I managed to explain the situation sufficiently, and after checking with the manager of the store they discovered they had some in the stock room. I imagine this situation may have improved now, as at the time this was a relatively new device (which was why there were none on the shop floor), and staff now have knowledge that Vodafone actually sell cellphones under their own brand etc.

With Vodafone New Zealand informerly announcing that a Windows Mobile 6 upgrade will be available later this year (see first comment in the GeekZone review) this device is only going to improve with time. The largest negative is perhaps the lack of wifi.

PS: Has anyone managed to get the USB host functionality working? I am very very keen to hear from anyone who has success with this, as being a true geek at heart I have a lot of ideas for devices to interface to this port and I’m itching to work on them…

Google Gears – Progress over the weekend

Sunday, June 24th, 2007

I had a little bit of spare time over the weekend to start debugging some of the problems my initial builds of Google Gears for the Windows CE platform have had.

With reasonably minor tweaks to the source code to work around some differences between the Win32 API implementations for desktop Windows and Windows CE (HWND_MESSAGE doesn’t exist and you can’t create windows with a client rect of 0×0 pixels) I have managed to get the ResourceStore and ManagedResourceStore demos working.

A very alpha version can be installed by downloading the cab file available at http://google-gears-ce.googlecode.com/files/gears-win32-dbg-0.1.51.0.cab. This is a debug build which explains why it is so large.

Remember this cab file will only work on devices which use the Internet Explorer 6 for Windows Embedded CE web browser and not Internet Explorer Mobile, which is the web browser found on Windows Mobile powered Pocket PC and Smartphone Devices (see http://msdn2.microsoft.com/en-us/library/aa908125.aspx for further details). If you try this out on your device, please ignore the two ATL Asserts which occur while Internet Explorer initialises the Browser Helper Object – these are something I have yet to debug.

After getting a complete port to Windows CE devices running the full Internet Explorer 6 for Windows Embedded CE web browser, it is my aim to continue the porting effort to support the popular Windows Mobile powered PDAs, but since a number of required interfaces are not supported by this browser, it will involve more porting efforts which is why I am leaving it until the Internet Explorer 6 for Windows CE Embedded port is more functional.

The current list of features which are non functional or need improving in this port are:

  • Worker Pool – at present attempts to create worker pool tasks fail. I have not investigated why this is occurring but since I have used the Script Engine hosting APIs to hsot the Javascript interpreter in the past I don’t imagine it’s a major problem.
  • Local Server – This seems to be caching files properly as evidanced by the Resource Manager demos working, however the Asynchronous Pluggable Protocol implemented by Google Gears to intercept requests for URLs starting with http:// does not intercept requests while offline. Again I have not investigated this one yet, but at present this means Google Gears won’t operate in offline mode.
  • HTML Dialogs – Google Gears uses HTML based dialogs for permissions prompts and administration, currently these are failing to display properly. To work around this presently I have disabled then, meaning Google Gears allows access to the Google Gears API to any website which requests it.
  • Build Scripts – The main build script “build-wince.bat” needs improvment to make it work in more systems. Likewise the changes to the main makefiles need tidying up/rationalisation to make it easier for the main google-gears project to eventually accept the patches.

I am keen to hear from anyone which is interested in contributing to this porting effort in any size, shape or form.

Hello World – Hello Google Gears!

Saturday, June 23rd, 2007

Google Gears Database Demo running on a Windows CE device.

I have been making a bit of progress on the Google Gears port for Windows CE. With a little bit of debugging and rework of some directory creation functions I needed to write yesterday, I have managed to get the Google Gears Database Demo working on a Windows CE powered device that uses the full internet explorer web browser as can be seen in the screenshot.

It’s still very early days, but it has been really exciting getting this initial functionality operational.

Things to investigate (and hopefully resolve) in the short term include:

  • The meaning of two ASSERTS which trigger when the Browser Helper Object is created
  • What is stopping the HTML based dialogs (such as the permissions prompt which asks the user if they want to grant a particular website access to using Google Gears) from displaying – at present I have had to disable these dialogs and temporarily hardcode the logic to allow all websites access to using Google Gears.
  • Determine why the default code for determining the directory where Google Gears should save database and local cached files is failing. Again I have temporarily hardcoded the path to match the installation folder for Google Gears.

Initial tests running this on a Windows Mobile device are not too flash (as expected). It seems a more significant porting effort will be required to get Google Gears operational on a Windows Mobile powered PDA or Smartphone. I am very keen to eventually get to this stage (if possible) but want to get this initial port operational first, since it should require less code changes, and will help iron out the majority of platform specific changes required.

PS: The other demos (local server and worker pool related) currently do not function properly in my port. I’m hopeful that they’re reasonably minor problems to fix, but won’t know until I investigate them further. A potentially more difficult problem which will need investigation is that offline mode currently doesn’t operate correctly, since requests for HTTP://… are not passed via Google Gears first, I’m hoping this will be due to the asserts I mentioned I am getting above.