I thought I would pass along a “good news/bad news” experience I recently had with regards to Windows Mobile 6.5, the .NET Compact Framework 3.5 and ActiveSync. Hopefully, it might serve to help someone in avoiding some coding and testing frustration.
I have been working on a project that requires responding to new incoming messages on Windows Mobile 6.5 devices. Fortunately, the State and Notification Broker API (“SNAPI”) made this simple enough. Now, my C# code needed to play a sound if certain conditions were met. Simple enough – the System.Media.SoundPlayer class in the .NET CF 3.5 would do the trick. Once the code was written, it was time to test.
The first test went according to plan. Use an emulator, deploy in debugging mode, set a breakpoint to ensure that I was hitting the correct branches in application logic and run with it. Sure enough, everything performed as expected. The next test was essentially the same, with the exception being connecting an actual Windows Mobile 6.5 device for testing. Again, there were no problems.
For the next test, I decided to remove the breakpoint in Visual Studio. I run the code and… no sound. My intellectual response - “WTF?!?!?” ;-)
I’ll keep the story brief here, omitting all the second-guessing and testing that went on up until my finally figuring out the root cause of the problem. The issue, as it turns out, is that -
- SNAPI and the .NET Compact Framework 3.5 work very well. By “well”, I mean “fast”, especially when running on the latest hardware with Windows Mobile 6.5.
- ActiveSync runs… well… about as fast as it always has on Windows Mobile, despite OS and hardware improvements.
Keeping in mind that ActiveSync and my application run on different threads, here is what I was able to determine:
- ActiveSync begins a synchronization operation. As part of this sync, a new email arrives. Based upon device settings, ActiveSync prepares to play a sound and grabs resources.
- At around the same time, my application receives the notification from the broker about a change in the unread email count changing. My logic has to do quite a bit of processing, but still managed to get to the point of playing a sound while ActiveSync still had a hold on resources. Result – my sound wouldn’t play.
“Fine”, I thought, “This is strictly a timing issue.” When I was in debugging mode, the stepping through the code and the latency associated with running in debug mode gave enough time for ActiveSync to complete. As a result, I decided to add code to pause my code to give time for ActiveSync to release resources. Here is where the real surprise came into play.
I spent quite a bit of time tinkering with the amount of time my application had to sleep in order to be able to play my sound. It took upwards of ten seconds for ActiveSync to release the resource I needed. When you consider the fact that ActiveSync had a “head start” on my code (AS was the cause of the SNAPI event firing, mind you), the amount of time from start to finish for AS was, well, A LOT. Ten seconds?!? Needless to say, I was very surprised and disappointed. This wouldn’t have surprised me a few years back, when slower hardware and slower network speeds could be the culprits. But today? With faster hardware and networks?
I guess the moral of this story is… If you are coding for Windows Mobile with a dependency on ActiveSync, NEVER assume performance. Code for the worst case and hope to be pleasantly surprised.