Tzah 2.0

One of the group sessions that were held last week in MoMo TLV was focused about Network monitoring and “Big Brother”. The group itself talked for about 15 minutes before we switched to other groups, but it was enough to raise some intriguing points.

The demand for monitoring is triggered by two distinctively opposite sides: government and facebook-like users. Following 9-11 and local crime events, governments began to tap more and more on their citizens. Although we see many groups opposing it, I think that the fear-factor will overcome and we’ll see more monitoring on a bigger scale. Obviously, that includes mobile calls, SMS, IM and VoIP.

On the other hand, there are those who freely give away information about themselves: GPS data of current location is uploaded to the web. Blogs, pictures and twitters are common ways to share friends but also complete strangers about our personal lives. That got me thinking. Perhaps there’s a business opportunity for these open-life people? There are already companies with contextual-oriented ads platform that can be used in exchange for free or subsidize calls. This is, in fact, a nice way to say that your calls are monitored so you’ll get ads that relates to topics you talked about. Let’s say you talk about how nice Rome is. Don’t be surprise if you’ll see an ad offering you a deal for a trip to Italy.

Indeed, the concept is not new. GMail is doing this for several years now. I’m not sure people are giving a second thought about the fact that Google is going over their mails. Still, GMail demonstrates that free services in exchange for some privacy-compromise is working. This approach can be expended even further from saving money to making money. Perhaps Big brother-like shows where listeners subscribe to channels where people talk to their friends and family over the phone. This can be a phone-equivalent to web cams.

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 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.

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?