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.

Let’s say you built an application that need to know when certain keyboard buttons are pressed. Let’s say you need to get such events even while running the application in the background and some other application is running in the foreground. Well, there’s an easy to use native API that does that: SetWindowsHookEx. There’s an excellent post by Alex Yakhnin on how to use and integrate the method to managed application.

However, before using the method, you should consider the following. The method is a private API. Meaning, it can change or even remove in the next CE version. More over, OEMs can decide to remove it themselves. The result is that you have angry customers complaining about your application and you have no idea why. For more information, check this post from Raffael Limosani of Microsoft CSS (Customer service and support). BTW, I highly recommends reading Raffael’s posts. They are very informative and to the point.

So, you read the disclaimers and decide to continue and use the method. Alex’s code is excellent but there’re couple of points you need to consider. First of all, each button press initiates at least two events for the button. The first is for the state where the key is pressed (down). The other is of course, when the button is released (up). I decided to handle the down event in order to catch the event before other applications.

That brings up to the second point. Other programs are also hooking. Usually, you don’t mind. Every time the hook procedure you set in SetWindowsHookEx is called, you do your stuff. When finished, pass the event to the next hook by calling the appropriately named method CallNextHookEx and return its result. However, if you wish to prevent the key event to pass to other hook, then don’t call CallNextHookEx. Instead, just return 0. Blocking other programs from these events is not very friendly behavior so thing carefully before doing it.

On some cases, avoiding the call to CallNextHookEx might not be enough though. For example, the green (send) and red (end) buttons. It seems that the phone application catches events when these buttons are pressed even if you don’t call CallNextHookEx. If you wish to block that as well, have your hook procedure return -1. If you do return 0, expect the phone application to send another key up event upon completion of event processing. Don’t take my word for it. Try it for your self.

Finally, don’t forget to call UnhookWindowsHookEx before closing your application or you’ll get a nasty error about WinCe5011bException.

This post is aimed to windows mobile developers looking for a profiler for their mobile application. I came across EQATEC profile. This tool is great! You can run it on all .NET apps including .NET CF 2.0 and 3.5.  The usage is quite simple:

1. Compile your application as usual. If you wish, you can later add profiler-attribute later for fine tuning the profiler.
2. Use the profiler to build a profiled version of your application. The profiled assemblies are typically 30% larger than the original and runs 30% slower. I believe that for most apps that is acceptable.
      
3. Deploy the profiled version and run it on your device. Your device doesn’t have to be connected via the ActiveSync for this step. After the application finished, find the report file. Usually, it will be be on ‘Temp’ folder or on SD card if you have one.
4. Drag the report file to your desktop, and from there, to the profiler viewer.
5. After a few minutes, people around you would probably find you mumbling “OMG, what the…?, I didn’t believe it takes so much time! And why the hell this method is called so many times”.

I found the viewer useful for the following points:

1. Find out your bottle-necks methods. This could be methods that takes long time to execute, or relativity fast methods that are called numerous times.
2. Find out what happens inside your code. You might realize that you overlooked some calls to method that consumes most of the application time.
3. Prioritize your work. The 80-20 rule will work here. You’ll find out that most of the delays are trackable and easy to resolve.

For more information and understanding on how to use the profiler, go to the guide.

BTW, EQATEC also have a tracer tool. However, it is an on-line tool that drastically reduces the performance of your application. For example, the bubbles example application rate was reduced from 54 frames/seconds to 3!

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.

This posts is dedicated to all developers that banged their heads trying to realize why their System.Thread.Timer doesn’t work.

The timer class is very useful as long as you know how to use it. First of all, make sure to keep a reference to your timer object. Otherwise, the big bad wolf, garbage collector, could grab it even if the timer is still active. Next, the class is, well, threaded, so keep in mind it is reentrant. Be careful not to have the execution callback lasts longer than the timer’s period. If you don’t, or the callback can be accessed from other threads, mainly the GUI thread, make sure to use protection (that’s always a good advise. Ye. OK.).

Last, but not least, we should realize how the timer works. The timer works in application time and not device time. If the device has entered sleep mode where all threads are paused, the timer behavior might not be as expected. Example. Suppose you have a timer object that fires-up every 20 minutes. You start it at, let’s say, 08:00 AM and after 5 minutes the device goes to sleep mode. You wake up the device at 08:30AM. Should the timer fire now? No! As far as the timer is concerned, only 5 minutes has passed and not 30 minutes. The next time it will fire would be at 08:35AM.

Delegate in C# is a nice function wrapper. Similar to function pointers in C/C++, it references a method and then you can use as a callback function. Every once in a while, a developer will need to call a managed-code delegate from a native code. For example, our mobile SIP client application we developed for eMobile is written mostly in managed code, but, is also using SIP stack libraries written in native code.

We needed a way to pass events from the SIP stack to the application layer. So, we had to transform a managed code delegate into a C function pointer. It turns out that’s very easy. If you know what you’re doing that is.

First thing to do is to declare the delegate in the managed code:

public delegate void OnIncomingCallDelegate(string aCallerID);

Now you need to declare its equivalent function pointer in native code:

typedef void (CALLBACK* NATIVEINCOMINGCALLUPDATE)(char* aCallId);

Alrighty then. Next step is to pass the delegate to the native DLL. That’s actually easier than you might think. You’ll need to pass the managed-code deleagte to the native-code DLL.

[DllImport("SipStackMvDriver.dll")]
            public static extern void
                SetupCallbackFunction(OnIncomingCallDelegate aOnIncomingCall);

The declaration on the native header file will look like this:

SIPSTACKMVDRIVER_API void
    SetupCallbackFunction(NATIVEINCOMINGCALLUPDATE aIncomingCallback);

where SIPSTACKDRIVER_API is a macro for DLL import/export declaratrion:

#ifdef SIPSTACKDRIVER_EXPORTS
#define SIPSTACKDRIVER_API __declspec(dllexport)
#else
#define SIPSTACKDRIVER_API __declspec(dllimport)
#endif

Guess what? you’re done!

Well, actually, almost done. You just have to do some preemptive work to prevent the delegate from being collected by the garbage-collector.

OnIncomingCallDelegate voipIncomingCallDelegate = new OnIncomingCallDelegate(OnIncomingCall);

GCHandle.Alloc(voipIncomingCallDelegate); // preventing the Garbage-collector from disposing the delegate

Now you’re done. Your delegates might require some marshalling tweaking but that’s an issue for another post.