Skip to main content

Articles

Featured Products

Windows Mobile Developer Controls
Windows Mobile Developer Controls
Stay in touch using the DEVBUSS RSS feeds.
 

News

Windows Mobile Developer Controls
Windows Mobile Developer Controls

The Challenges of Pocket PC Development

Written by Derek Mitchell  [author's bio]  [read 48914 times]
Edited by Derek

Page 1  Page 2  Page 3  Page 4 

SECURITY

This is an area that the industry is very focused on at the moment and IT security policies need to be amended to address the additional exposure that results from using Pocket PC’s to store corporate data. Although corporations went through similar exercises bring notebooks and laptops into their security schema, the capabilities of the Pocket PC are less well understood and there is a tendency to treat them as PC companions or sophisticated organizers. IT management needs to be aware and prepared with a solution to provide Pocket PC’s with authenticated and secure access to corporate resources.

How can you secure your application? Firstly you need to consider the security of the actual device since it’s not physically tethered to the work place and secondly the security of the communications between the device and the server based data.

Securing the device

Pocket PC 2002 introduced strong password support that is especially appealing to enterprise developers. Pocket PC devices are intended to be mobile data stores and the new security dramatically enhances the device security by introducing an exponentially increasing time delay between incorrect password entry efforts. This means that the password cannot be cracked via a brute force method. It is important to enable this feature and live with the small inconvenience of having to enter a password every time you power up your Pocket PC. For virus protection the new anti-virus API (AV API) introduced in Pocket PC 2002 generates a file system change notification every time a file or folder is created, modified or deleted, or storage media is inserted. The idea behind this API is that with the increasing number of connectivity options available to the Pocket PC – desktop anti-virus protection will not be adequate – we will need to have on device options as well.

If Pocket Internet Explorer is part of your development solution and the data transactions are of a sensitive nature use digital certificates since PIE does support SSL versions 2.0 and 3.0.

If you are using a wireless access point disable the SSID broadcast and enable WEP 128 security – it is vulnerable but every step helps discourage accidental exposure of secure data; and if Pocket PC’s are to be granted dial-up access then use the built in VPN support.

Sidebar: As a side bar it is important to note that the Pocket PC 2002 specification also calls for all devices to host a 128 bit “universally unique” DeviceID. This DeviceID is unique for all Pocket PC devices regardless of manufacture. Aside from the obvious use of this feature for Digital Rights Management, this feature should also be embraced by developers as a way to combat software piracy as well as enforce data integrity issues when it comes to sharing information between devices.

CHOOSING APPROPRIATE TOOLS

A brief history of where we are today…

Recent months have heralded some interesting developments for the Pocket PC Development community. A year ago the Microsoft tools offerings in the Pocket PC development arena were essentially limited to the eMbedded Visual Tools suite consisting of the eMbedded Visual Basic 3.0 and eMbedded Visual C++ 3.0 which were released in April 2000. These stand-alone tools combined with the appropriate Software Development Kits (SDKs) allow you to develop applications for Windows CE based Pocket PC, Palm-size PC and Handheld PCs. This was a milestone for programmers since it encompassed all the tools required for Windows CE application development "under one roof". eMbedded Visual Basic (eVB), included with MS eMbedded Visual Tools 3.0 (eVT) probably offers the easiest path to developing Pocket PC applications and is the logical starting point for desktop VB developers.

eVB or eVC++?

If you have any Visual Basic programming experience you will find the eVB development environment very familiar, both in terms of functionality and workflow. In fact one of the reasons eVB is such an exciting phenomenon is that it significantly reduces the learning curve typically associated with handheld programming. The same visual development paradigm that has made Visual Basic the most popular programming language in the world is now available for the Pocket PC. However when it comes to Pocket PC development eVB is not the universal panacea. eVB is an interpreted language which means that when eVB programs execute they are interpreted a code section at a time by the runtime environment. In contrast eVC++ compiles to an executable file which will run much faster, however the learning curve for new developers is steeper. If you are looking for a way to extend the reach of your enterprise applications I would prototype it in eVB. If you're after speed and low level API access use eVC++.

The Limitations of eVB

eVB has several well known bugs and is missing key ActiveX control functionality which VB programmers would take for granted, for example the date time control. Many of the currently supported controls fall short of the mobile user’s expectations. It surprises many first time users of eVB that there is no native date time control and that you either have to jump through hoops to create a date time picker or purchase a third party control to provide that user friendly date picker interface. In addition functionality that you would expect to be relatively easy to implement using a language such as eVB, like creating menu bar controls and tap and hold menus requires a bit of sleight of hand and detracts from the rapid prototype niche that we have come to expect from VB derivative languages. Some of the other idiosyncrasies of eVB are:

  • no support for user-defined types
  • no support for control arrays
  • the emulation environment was slow and did not mirror the device as well as it should nor did it provide adequate support for ADOCE data sources. In fact early on in my Pocket PC development I made the decision to test solely on a device and purchased an 802.11 card to speed up the process. Pocket PC 2002 emulation is a big improvement.

Then came Pocket PC 2002…

In September 2002 the Pocket PC 2002 platform was launched. Pocket PC 2000 had been around since April 2000 and the investment of application development on that specification mandated that Pocket PC 2002 maintain as much backwards compatibility with Pocket PC 2000 as possible. One of the most important changes to the Pocket PC 2002 specification was that Pocket PC 2002 would only support ARM based Pocket PC’s.

Other Pocket PC 2002 enhancements included some interface style changes; such as the lack of the File menu in all applications on the device as well as the tap and hold animation which provides more immediate feedback relating to the target of the tap and hold event. The HTML control now included hooks to allow developers to use the control inside their own applications.

The introduction of the Smart Minimize button also made the Pocket PC interface more closely mirror the desktop environment with the ability to “close” windows, although this was more for appearances sake (and probably to quiet the loud desperate cries of people accustomed to having to close windows they were not using) since the windows are not really closed but rather become invisible and stay resident in RAM.

For developers moving forward this meant that if their applications were required to run on non-ARM based platforms then they need to stick with the Pocket PC 2000 implementation. So what were the compelling reasons to develop against Pocket PC 2002? Well aside for the new interface enhancements, developing for Pocket PC 2002 would dramatically reduce the testing permutations for multiple platforms and there were some new Pocket PC 2002 features which would meet critical application needs; such as applications utilizing the inbox message store or requiring a universally unique device ID. However, applications that used the City List or API’s to access the inbox message store would need to be modified to run on Pocket PC 2002 since these features had been modified.

Previous Page  Next Page