Tzah 2.0

Windows Mobile 6.5 is done and that’s a good opportunity to provide a quick jump-start to developers wishing to learn more about the OS.

Microsoft has a tendency to overload developers with abundant API of its various platforms and technologies. Windows Mobile is no different. Managed and native API, .Net, MFC, ATL, Win32… it’s all there for the confused developer. Luckily, Microsoft has recently published an article discussing APIs for Windows Mobile 6 and later, and how to select the best fit for your application needs. BTW, don’t be tempted to choose managed .Net API before fully understanding the functional requirements from your application and the devices it needs to run on. Win32 is better if you wish the application to run on as many devices as possible. 

A good place to learn Windows Mobile development is MSDN’s ramp up which is a community-based learning program, teaching various aspects in development for WM. Another excellent source for learning and help is blogs of mobile gurus. I recommend subscribing to the following blogs: Raffaele Limosaniblog, Alex Yakhnin, Christopher Fairbairn, Windows Mobile team blog, Reed and Steve blog, the Moth, and finally, Chris Craft (especially his 30 days of .Net series).

OK. You’ve done your reading and fill ready to start developing? hold on. Make sure you took into account globalization and localization issues. Simon Judge lists many of them.

Once done development, you need to QA your application. If your application aims for numerous devices in many countries, involving different networks, you should consider using DeviceAnywhere or maybe even Mob4Hire.

Finished the cycle? congratulation! Now you can go and publish your application on Windows Marketplace.

I’m sure all of us developers has stories where they submitted code, after carefully debugging and testing it, only to get 5 minutes later rejects from QA and you’re clueless for the reason. This is one of those stories.

We’re developing a VoIP client. One of the features is letting the user know if she missed calls while the client was off-line. In order to do this, we ask for the mobile’s time. Problem is, mobile devices has a tendency for not having an accurate time. It might be because mobile users adjusted the time but keep using manufacturer default time zone. It can also happen that you forgot to adjust the time properly while traveling abroad. In some cases, your fancy device might just decide to reset itself for no apparent reason. At any case, chances are that the device’s time is not the same as your server. This is obviously true when dealing with global service provider like JAJAH that supplies services to users around the world.

Back to the the client. We decided to send the local time of the device over a Web-Service and have the back-end server send back missed calls and adjust time of call with the client’s local time. All went nice and dandy on our development environment. Results came back as they should have, edge cases were also tested and worked flawlessly. Then, we gave the client to our QA team.  After a while, they came back telling that there’re inconsistencies with the missed call features. So frustrating!

I won’t bother you will all the details. Eventually, it turned out that DateTime is a wise-guy object. It has a kind property which affects the result of WS de-serialization. The local device-time we sent from the client was de-serialized to UTC time on the server side. So, everything worked fine as long as the device and the development environment were both on the same time zone (GMT +2). Once we moved to an environment in New-York (GMT -8), the server thoughts we’re looking for missed call that are due in 10 hours. Indeed, quite a paradox.

In order to fix the issue, and make sure that the DateTime objects is not converted to a UTC format, simply make sure use the unspecified kind.  For example:

DateTime myDateTime;
myDateTime = DateTime.SpecifyKind(DateTime.Now, DateTimeKind.Unspecified);

This post is dedicated to Boaz for his great help in solving this problem.