This is the first in a series of tips in windows mobile development.
When I was first asked by my client to pick up the windows mobile development part of a project I was already working on, after another developer had left the project, I thought, “sounds cool.” I’ve done a lot of Microsoft development, but never mobile. Starting with VB4 and classic ASP through to modern development in WinForms, ASP.Net, and SilverLight, I thought my extensive experience would give me a leg up on mobile development. In retrospect I suppose that was true, but I was unprepared for the hard knocks of mobile development. So here is some overall development advice. While the tone may seem negative towards Windows Mobile, the intention is to prepare the new developer. If you have to build for Mobile, Win Mobile is a great choice compared to the alternative OS platforms for many reasons. But keep the following advice in mind.
Windows Mobile is not a Platform for Enterprise Software
With the exception of a short, failed attempt to develop on the Palm OS nearly a decade ago, Windows Mobile is the only mobile platform with which I have experience. However after speaking to those that have experience on both Win Mobile and the Apple or Symbian OS environments, it sounds to me as if .Net mobile is a comparative cake walk. So if you are targeting a mobile environment based on ease of development, my impression is that the compact framework is the way to go. But, just because it is easier than the alternatives, it doesn’t make it “easy”. One of the largest hurdles you may need to overcome is a built-in “feature” of windows mobile. The application I was asked to build was an application what will run all day, collecting data via Bluetooth, and sending to a server via mobile WCF services.
Unfortunately after many weeks of trying to figure out why my application kept “crashing”, I ran into a MSDN article that explained that windows mobile “reclaims” resources from running applications when needed. In other words, if the phone runs low on memory (below 2MB by default, but varies by OEM), it will shutdown running applications to regain memory. There is no way to prevent the shutdown of your application, you can only prepare yourself to recover, which will be discussed in a later post. Nonetheless, as an application developer, how do you build an application that is supposed to run all day, on a platform that is not intended to have long running applications? The prototypical Windows Mobile applications is one that is run only when the user needs it and is “dormant” or unnecessary when in the background, and therefore if the application is shutdown by the OS, no big deal, the application can be restarted when the user requests it and the user can do what they need to do.
Virtual PC is a No-No.
I started doing the development on the larger project in a Virtual PC environment. This was primarily due to the fact we started the Silverlight development in the Beta 1. Virtual PC made a lot of sense in this case. However Mobile development in a virtual PC presents a problem. Virtual PC doesn’t have access to the USB ports, so there is no chance to deploy the code and debug on a real device. Additionally, the device emulator is really a virtual PC environment. So, in effect, you have a virtual PC environment running inside another Virtual PC environment. Not very speedy and a huge memory hog.
Setting up a deployment package
The deployment package project is not terribly intuitive. Don’t waste your time trying to figure it out on your own. Go find a step by step guide, or online demo. It isn’t that complicated if you don’t need to package multiple cabs, but just the same, find a tutorial.
Resources are difficult to find
I asked the exiting developer what books and resources to take a look at. I was told that the Microsoft Press, Microsoft Mobile Development Handbook by Wigley, Moth, and Foot was about the only good book available. That was definitely true in March of 2008, when I got this advice, but the book was already somewhat out of date since we were targeting Win Mobile 6. Unfortunately there isn’t a large selection of books that have been written in the last year, but a few more are now available. I don’t have recommendations on any yet.
The web is an even more frustrating place to seek help for windows mobile development. If you encounter an issue and perform a web search to find the answer, you’ll undoubtedly find a whole slew of results. Unfortunately my experience has been that many of the articles you find are not dated and don’t specify a version of Windows Mobile under discussion, or worse don't work on the compact framework. Subsequently, you can spend a lot of time implementing a solution or work around that turns out not to apply, or is the long way around an old problem. When searching for online resources, be sure to make sure the version of windows mobile applies to you and find other search results to backup any solution you find. There are many fewer online resource for mobile development compared to all other aspects of Windows development.
Debugging is slow
This can be somewhat dependent upon the speed of you development machine. But there are a few things that will always be slower than debugging a win-forms application. You must first deploy from Visual Studio to the device emulator, this can take up to 30 seconds or even a minute or more depending on the size of your application, amount of available RAM, or speed of your host machine. Stepping from one line of code to the next is also much slower than you would expect. Remember that your development environment is crossing a Virtual PC environment into the Device Emulator and back again to Visual Studio. When I was developing with my Visual Studio running in a VPC, it would take several minutes to get through my initialization code as the application grew (see the section above, “Virtual PC is a No-No”).
Estimate with generous padding
I missed several of my first estimates by a wide margin. After expression the frustration of the situation to a very smart man, he said, “You need to think about this project as if you were back writing software for Windows 3.1.” That was a very helpful piece of advice.
- The feature set is small.
- The environment can become somewhat unstable if you push too hard.
- It is hard to the find the code you need to do the things you want.
- Sometimes you need to write API interface code.
Many of the same principals of early windows development applied to mobile. If you’re lacking experience developing against the mobile platform, take your best guess based on your win forms experience and double or triple it.
Don’t forget about the SmartPhone
If you thought developing for the mobile platform was restrictive, you’ll be in for a tough lesson if your experience is based on a Pocket PC (PPC) application. The Smartphone has a much smaller resolution, no button control, and no tab control. In most SmartPhone UI designs, all actions are achieved through the menus under the “soft keys”. Make sure you identify which platforms you need to target before you start designing your UI. Due to the vast difference between UI design for the SmartPhone and PPC, you very well may need two different UIs. So leveraging a Model View Presenter or Model View Controller pattern is a very good idea.
Do I need to build a Win Mobile 5 version for older phones
If you build a cab with Win Mobile 6 Professional (PPC) as the target platform, you can install and run the application on a Win Mobile 5 SmartPhone, as long as you haven’t used any controls (buttons, tab controls, etc) not available on the SmartPhone, and the latest version of the .Net Framework is installed on the phone.
Future posts will cover development advice for SQLCE, how to manage threading on the Compact Framework, and one solutions to making applications that must run “all the time”.