J2ME, Symbian C++, QT or Android :: Why & Where?

"Once upon a time there was a language called J2ME", you will not be surprise if you hear this few years later. But it should not be forgotten that each of these languages have its own context or domain which can vary according to the needs of the customer.

Why & Where...

A well known truth about J2ME is that it is a sandbox language. I.e. It always needs to stand on top of a another language stack (OS) & hence J2ME is always restricted to access some kernel level functionalities of limited devices because of this 3rd party behavior. For instances one can not write an app which can be auto-started in device boot up without using some other party interaction like push registry. Of course by using push registry one can write an app which will auto-start but via a timer, sms or http like interaction signaled by an outsider. Therefore without any interaction auto-start in boot up is impossible in J2ME. Another scenario is accessing device key pad for locking and unlocking purposes is also impossible as J2ME is not allowed to access locking API of the device. Actually J2ME does not even has such an API for locking. One more thing to notice is that every mobile device has a settings programme which is responsible for managing installed applications. In J2ME context you can never write an app to get the control of this settings app which is silently handled as a device kernel level programme.

As mentioned the primery reason for this is J2ME is a third party language pre-configured and installed on top of another core language stack of the device. For example simply consider Nokia mobile phone which claims to support for J2ME. But the fact is Nokia has its own language stack as the core of the device called Symbian.  Symbian OS has its own rich APIs to directly interact with hardware level and other core functionalities of the device. Symbians S40, S60, Symbain 3 are examples for such Symbian OS APIs equipped with SDKs to leverage developers for developing apps. Both the carbide.C++ and the later added framework called QT C++ can be used for writing applications for Symbian OS. Above mentioned impossible scenarios in J2ME can be achieved via these two implementation frameworks.

But as J2ME hides internal complexities from developer, for developing some typical enterprise level apps, J2ME is apparently efficient and easier than using Carbide or QT. Hence language depends on requirements as always. Focusing on Android here is irrelevant because it is that big buzz word everybody talks about these days. To be it as this much of huge buzz, its complete OS stack has played an incredible role. Because of this perfect organization from ground level APIs to higher level APIs in its OS stack, developers have been able to develop apps without considering dependencies, hardware abstractions, library couplings etc. But there is an one little problem with Android. I.e. its fast growing development life cycle. Not like any other OS versions of other devices, Android does not provide long term service for once released version. They tend to grow fast and if earlier version can not tolerate with the later version, bad luck for the users those who have that earlier version of device. But generally people rarely open their mouths up on this.

Therefore Why and Where is a decision made by developers.

Checking out and setting up QJSON for QT symbian

Generally JSON is simple data exchange format like xml but more simple and flexible than it. Specially when transferring data in XML format, it adds more weight to the actual information we want to transmit as information is overwhelmed by opening and closing tags. This can sometime be useful and sometime be an overhead. To avoid or reduce that overhead we can use JSON. It stands for Java Script Object Notations which can be used to transmit data over http as JSON object. There are many JSON related online references are availble in internet. Therefore What we are focusing is QJSON which is QT based library that maps JSON data to QVariant/QMap objects.

We will consider making qt lib and setting up the path properly via QT creator IDE.  qjson library is not implicitly available with default libraries comes with QT. Therefore you have to checkout qjson project source separately and then build it and generate a qjson lib file. One thing to notice is do not try to download qjson source from source forge because due to some reasons it is not the complete project for one to develop lib file they need easily. That source hides some essential files like .pro file etc which are useful to generate lib file directly by using QT Creator IDE.

For checking out the latest version of qjson, first you shoul have a git client installed in your machine. Git is a FOS distributed version management system that can be downloaded from official git site. qjson repository is hosted here. For checking out this as online from downloaded git client, usegit clone git://gitorious.org/qjson/qjson.git command and import complete latest qjson version to your local disk space.

Then open this qjson project via QT Creator and build it. It will create qjson.dll.a lib file under build/lib folder of qjson source. It is like your_disk_name:/qjson-0.7.1/qjson/build/lib/qjson.dll.a. Now all you have to do is to tell QMake in your .pro where is located your header files and lib file.

Ex: type as following in any where of your .pro file

INCLUDEPATH += "c:/qjson-0.7.1/include"

LIBS += "c:/qjson-0.7.1/qjson/build/lib/qjson.dll.a"

That's it. Enjoy qjson in QT. Some initiative code snippets on qjson for qt can be found here.