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.

Technology is fast-pacing. It’s all around us. 3G networks are deployed world-wide (although at small percentage of overall networks) and the battle is already on for 4G between LTE and WiMax. The new annunciation of is here as an answer for the fuel crisis. Digital photos and web-sharing has only recently (I’m talking years-scale) become common and now we witness amazing ways to combine the two and . Mobile and VoIP. Need I say more? These two technologies are always revolutionized. VoIP is becoming widespread  in more and more businesses, homes and various vertical markets. Mobile is constantly surprising us. iPhone, Modu, GPS-integrated phones.

But still, we’re not there. Not from an innovation point of view.  It seems that in our vanity and ambition to become leaders in this technology race, we forget something. That something is stability and reliability. Technologies  are evolving but can the family next door use it?

High availability of day-to-day infrastructures and commodities like water, Gas, PSTN lines, electricity and TV is perceived as self evident. We open the TV and "Lost" is on, we click a switch and let there be light.  Why can’t we have the same availability and reliability on more advanced technologies?

Yesterday, was not a good day for me. I woke up late because the alarm in my cellular didn’t work. My other cellular, top of the line HTC TyTN 2 decided to quit charging for some reason. I picked up my laptop bag and found out it’s hot. why? my laptop  didn’t go to sleep mode when I shut it down so it continued to exhaust  the battery while in close bag. I quickly went down to my car, and… Yes, the battery is gone. And on top of things, the   on facebook was going through upgrade.

High-level technology is just not there. Take for example a recent report that demonstrated that only 3 of top 20 most popular web sites achieved the mythical 5 9’s of reliability. At the beginning of the year 4 undersea communication cables were cut crippling international communication in countries like India, Qatar and United Arab Emirates.  These examples are annoying but not harmful (unless you just have to update the entire world on what you ate for breakfast). A much more alarming example of why reliability is important came just at the beginning of this month were a Canadian toddler died after VoIP 911 dispatched an ambulance to  the family’s former home, more than 2500 miles away.

I hope that top-level technology companies will quickly realize that amazing gadgets and cool features are nice, but reliability is more important. Until than, we can only backup our and go outside to real friends the next time that our favorite social network is done.

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.

Hi there! My name is Tzahi Efrati and I’m manager of mobile & tools development here at JAJAH. The mobile market has changed dramatically over the last years and continues to present new functionality every so often.

Over the last 6 month, two major events happened concerning the mobile industry. The first is of course the release of Apple’s iPhone. What I like most about this phone, besides its functionality is the one-touch-screen-fits-all approach. The user is not constrained to physical keypad and buttons. The phone enable the application to present the user interaction of their choice. I’d imagine that somewhere in the near future, iPhone 2.0 will enable the user itself to choose the UI he/she wishes to use. For example, left-handed people could choose the layout of game controls according to their needs.

The second major event is Google’s announcement of of the Android, the open software stack for mobile devices. The announcement, although not backed-up by actual phone models had already caused fundamental change of hearts with major operators like Verizon and AT&T. These two giants has declared their intention to open up their cell phone network.

Although it still remains to be seen the concrete implications of these announcements, one thing is clear. Mobile phones are becoming more and more a “one size fits all” machines. It already started with the introduction of camera and music players to the phones. The iPhone and android present a notion of having a device that can do almost everything. Want to hear your favorite song? Go to the iPod on your device and finger-scroll your way. Interested in checking how much your stock did lat night? open up the stock widget. Care to change the layout of the phone software? use your mobile browser to find and download the latest calling application.

Still, a couple of questions rise from this “all-you-can-swallow” wonder machines. “Can we handle it?” and “do we really care?”. Talk to your parents and your friends and I’m sure most of them will tell you that all they want is a simple device to make calls and send SMS. Anything else just complicates. Let’s face it, even technophiles, who take their cereals with a GigaOm.com on the side don’t master the entire functionality of their gadgets or the latest cool addition to their Firefox browser (so 2006).

I’m not sure that even teenagers who has more virtual friends on facebook than actual homosapien could master so much technology in one device or even care to use it. What do you think? is it just the beginning? should we expect mobile devices in the near future to be even more featured-pack? Or perhaps, this will cause the exact opposite. People will become so antagonized that they’ll stick to their old mint-condition 2G phones?