Tzah 2.0

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.