However, that's not the major pain point when developing for Windows Mobile. Yes, the user interface is the major pain point for users when dealing with Windows Mobile but not for developers.
The real issue for developers is deployment. That's right, when developing for Windows Mobile, you have basically 3 options:
- Java ME
- .Net Compact
- Native
Java ME, when present, is usually the CLDC variant. Meaning it's a pain, it's light, missing many important classes, has pre-Java 5 syntax which means you can't use the majority of 3rd party libraries on it, open source or otherwise, and well, usually, not even loaded on the phone to begin with. Furthermore, if you don't have it on your phone, there isn't a convenient way to get it or upgrade it. What ships with the phone is what dies with the phone. Again, deploying a JAD file isn't terribly difficult, that is, if the phone has a Java VM to begin with and that Java VM is of decent quality. As it turns out, most Java VMs that ship on Windows Mobile aren't worth the bytes they fill up.
The last choice is .Net Compact. This one isn't too bad except for the fact that most phones don't ship a recent version of .Net Compact. Usually, you'll find .Net Compact 2 with no service packs, which is a total mess, or .Net Compact 1 ranging from service pack 3 to no service pack at all. The minimum that is actually usable is .Net Compact 2 SP2. So the problem you have now is upgrading .Net compact. The only official supported way of doing this is to download an MSI package to Vista/XP and the next time your phone connects to your PC, your desktop will upgrade your phone. Not very useful if you want to deliver applications on the show room floor.
So keep going Microsoft, keep going, and maybe someday you'll look back on this and say, what were we thinking?
No comments:
Post a Comment