New Orleans, March 20, 2003 - After a good night sleep and returning in time to the Ernest Morial Conference Center I agree more and more with yesterday’s keynote presentation in which Bill Gates said that we are only at the beginning of mobile computing. The people here are indeed pioneers, and it could be very well that the companies they represent will be successful with new, exciting applications over the next couple of years. After all, it needs people actually developing software for devices before mass market adaptation will happen. Thinking back to the early days of Windows things were certainly more primitive. For the first Windows applications we did not have great graphical development environments, everything was still MS-DOS based. We did not even have C++ but had to program Windows applications using C in combination with the Win16 API. Putting that in perspective, we surely have a head start developing applications for mobile devices, but there is much room for tool improvement. Also there is much room for device improvement. Memory is still scarce. However the biggest challenges are increasing battery power and having true standards for connectivity. They will come, I am sure, but maybe it takes us a couple of years.

The limitations of mobile devices surely bring developers a lot of challenges. The biggest rule of thumb, developing applications for these devices is: “Don’t use the CPU and don’t use memory unless there is absolutely no way to avoid it”. Of course that is a blunt statement, but there is a lot of truth in it.

Interesting are the differences between the current generation of Smartphones and PocketPC’s. A Smartphone has a slower processor and less RAM than a PocketPC. The Smartphone makes use of flash for persistent file storage. Due to the nature of a Smartphone, after all it is a phone, the device will never go to standby but remains idle. Device developers are trying to save as much power as possible in idle mode, but developers have a responsibility as well. Suppose you have an application that wakes up every 100 ms to check a variable. Basically that would only mean executing a limited number of instructions at a slow interval. However, to get the device out of its idle mode, more things have to be done like starting timers, activating operating system threads etc. Now imagine that a phone company requires a phone to have a stand-by time for at least 90 hours. If a polling application runs for all that time, a lot of power is consumed by that application, even though it only runs once every 100 ms for a very short time. Something current PocketPC developers and desktop developers don’t really deal with is stopping all kinds of screen activity when the application is not visible. For Smartphones however this is essential. One simple way to do so is checking WM_ACTIVATE messages sent to the application. On reception of this message the user interface is visible and screen updates should happen. To find out if the application has no area visible on the screen at all, it is not enough to take action on WM_INACTIVATE because parts of the application might still be visible in the background (in case of PocketPC’s at least). In situations like this, in the WM_INACTIVATE handler it is advisable to call the API GetClibBox. If this API returns NULLREGION it is guaranteed that nothing of the user interface of an application is visible to the user and all screen activity can stop. As the demand for longer battery life gets bigger and bigger, “simple” things like these will have to be used in our applications.

Many companies are already realizing 3^rd party solutions to extend the functionality of mobile devices. Most of them work close together with Microsoft in the mobility partner program. During one of the presentations here at the Mobility DevCon some of Microsoft’s partners showed their products. All these products can be easily integrated in managed applications. They are exposed as objects and most of them integrate nicely in Visual Studio.NET. The products that are around right now fall into different categories. The most obvious ones are user interface components. A nice example of ready to use components is available by ComponentOne. Their flex grid component proofed to be very flexible in a demonstration. Not only does this component provide full grid functionality, but it has some nice added extra’s like a tree view within a grid.

Another company really has a component available that many developers using managed code have asked for. IntelliProg has focus on developer controls. All of us writing managed code know that at least one important PocketPC control is missing in the managed world, the Date/Time Picker. Intelliprog has created wrappers around the exisiting unamaged Date/Time picker so it can be used from within managed applications.

Other products by third party companies are for instance components for credit card processing by NSoftware and products for guaranteed transactions, even if a device is not always connected, created by Odyssey Software.

Hewlett Packard showed a creative solution towards security on PocketPC’s. Originally PocketPC is an unsafe device. Imagine that you have credit card information stored on your device when it gets stolen. The iPAQ 5455 PocketPC is a very complete device. Not only are Bluetooth and 802.11 built-in, but the device also built-in biometrics support. All kinds of secure data can be protected by fingerprint signatures. The device has a fingerprint scanner and HP also provides supporting software.