Despite my aforementioned enthusiasm for the phone’s functionality, I was a bit skeptical about developing for Android, especially when I heard that we needed to write Java code to access some of the functionality and for making a test application. I haven’t written a lot of code in Java. In addition, it didn’t seem straightforward for us to build our code like we usually do. The examples showed how to write java programs in a tool called Eclipse, and the sample code was built using a pre-made makefile structure which assumes that you put your application in a certain folder. The C++ support looked limited and we were unsure if the communication between our native code and java would work well enough to be able to call all our APIs and give real-time performance for the communication with the components that need to be written in Java. 

But the more I have learned about Android, the more positive I have become. This is also the case with my other colleague who works with Android. It was easy to install the SDK, NDK and the Eclipse tool by following the instructions on the Android developer web pages. It was also easy to start making a java test application by looking at the included examples, and the java language itself is fairly easy to understand for an experienced C++ programmer. In addition, Eclipse actually tells you what you are doing wrong while you write the code and gives suggestions on how you should do it instead! Overall, I found that Eclipse is a very useful and powerful tool to work with. The Android plug-in for it is also really good. Executing an application on a device and debugging it works great- much better than when developing for Windows Mobile in VS2005, which has a really slow communication between a device and the host PC.

When I started developing for Android, I was positively surprised by all the functionality that is available to a developer. Android is obviously made for application developers and I’m impressed by the performance of 3rd party applications on Android phones. Functionality which is commonly not available or hard to implement on most mobile phone OSs is available through well designed APIs. The APIs are not always well documented on the Android developer site, which is something that Google obviously needs to improve, but overall it is pretty easy to understand what each function does. I really think that the fact that the phone manufacturers and operators don’t “own” the OS is a path to success. The number of available applications is one of the reasons for the success of the iPhone, but Android has the advantage of being supported by a number of phone manufacturers, and by being more open than OSX. In the end, users choose a phone because they want cool features and open access to a number of applications, just like they are used to on a PC. I guess I’m becoming more and more of and Android fan!

The Java subject has been discussed before on this blog, so I’m not going to repeat why it’s not a good idea to use pure Java for building a VoIP application; let’s just say it’s going to be a challenge for those who try. But if someone has got a Java based architecture and wants to enable or improve VoIP, will they have to throw their existing code away? Of course not – Java can utilize native, capable C++ libraries through the Java Native Interface (JNI) as long as this is supported by the JVM in the target environment. I wanted to ballpark the effort this would require, so I started hacking with the goal to make a VoIP call using a Java application.

I started out by downloading and installing the latest Java SDK for Windows from Sun. I then used a C++ VoIP library that I happen to have access to and chose the API functions I thought I was going to need to reach my goal (information hiding comes as a bonus – you don’t bring stuff into your Java class until you need and fully understand it). After copy/pasting these API functions into a new Java class, making some small adjustments to parameter types and adding the “public native” keywords in front of function declarations, I could use the “javah” tool to generate a C++ header for the glue code.

Some design decisions needed to be made, for example deciding where object specific information should be stored – I for one wanted to keep the data stored in the C++ glue code to a minimum and chose to retrieve member variables from the Java object when needed (JNI provides special C++ functions to do this). Callbacks, i.e. letting the C++ library call into the Java object, also required some thought (I won’t go any deeper here, but I tried it and it worked great). Basically, when all functions in the header file had been implemented by just making the corresponding call into the C++ library we started out with, the C++ glue code could be compiled/linked into a dll and used from the Java class we just wrote through the System.loadLibrary() call. And we’re done!

To conclude, it was only a matter of hours after downloading the JDK before I had made a (very) basic Java based integration of a VoIP library. This is not rocket science and a successful result was expected, but I still got a kick out of being able to type

 
 java MyVoipApp 192.168.200.41

from a command line to get a high quality VoIP call going on the local network. And now that we are in a Java environment, adding a nice GUI should take like 5 minutes, right?

After watching the BCS Championship game I am in a good mood for a short post. On that topic I start with:

Congratulations Gators!             

Every time there is news about a new Java based VoIP client for mobile phones I get questions about what this really means. This happened again today after it was revealed in recent news that Skype are about to release Skype Lite for Android and other Java enabled phones.

If you read the information closely you will notice that Skype Lite actually doesn’t support VoIP calls at all. For calls even between Skype users it is using the regular cellular voice network. The same is true for other similar offerings by e.g. fring (minifring). This is because it is far from a trivial task to design a generic Java based VoIP client.

Before addressing this topic I will comment on what I wrote in a recent blog entry where I talked about how to create a download free VoIP solution:

“Building a solution that doesn’t require a download is actually practically impossible because of the limitations that a Java Script cannot access audio and video captured on the PC. I.e., only one way streaming is possible for a Java Script based solution. “

It is easy to confuse the Java Script based solution with a plain Java solution, which is what we are talking about here. A Java client can utilize the full Java stack that is supported on the device and hence is not limited to streaming applications only, as the Java Script based client would be.

In theory Java, using the Java Media Framework (JMF) can be used to write a VoIP application but codec support is very limited and significant latency issues do exist, even on powerful PC platforms. This is due to the inefficiency of the Java model (running a virtual machine) as well as the fact that JMF has been developed with focus on streaming applications.

So to answer the question why is it so hard to build a generic Java based client for VoIP several factors have to be mentioned.  Maybe the three most important ones are:

1.   A fully Java based solution will be too slow to run in real time or take up all available CPU on the mobile device. It is possible to circumvent this issue by using a native library in C or C++ but that requires a library for each platform.

2.   Different devices are so different that any attempt to make a generic solution will still need device specific optimization for optimal performance

3.   Lack of support in the Java stack for certain important voice related features or poor implementations of the same. These issues are typically related to the sound drivers and network socket drivers and will be device dependent