Dec 8, 2010

Be a Platform Java Developer

Java developers expect that when they develop applications, the end result is a cross-platform binary that will work on all platforms with a Java VM (the WORA promise). However, for JavaME, even on its best days, this was accomplished only partially. Now that the innovation of JavaME through standards has been halted for a while, JavaME has drifted even further away from its cross-platform goals.
Read more →

Oct 24, 2010

Apple deprecates Java what about Nokia?

On a recent announcement, Nokia announced that she will be concentrating its focus to Qt and Qt Quick as the development platform for its internal and external developers. Furthermore, Nokia announced layoffs of as much as 1800 of its personnel. Almost simultaneously, Apple announced that it is deprecating the Java on Mac OS and will not be accepting Java applications to its newly announced MacOS App Store. If you recall Apple does not support Java on its iOS platform either. From the questions that I have been receiving, it looks like these news. although not related, caused concerns about the future of JavaMe on Nokia platforms, especially on Symbian.

Read more →

Oct 21, 2010

My boss asked me to use Orbit UI and I said No

You may have heard the announcements from Nokia that "Nokia Focuses on Qt to Extend Reach for Developers". This sentence actually does not make sense to those who are not familiar with the matter. Why should it? One would assume that Nokia, which acquired Trolltech -the maker of Qt- and became the maker of Qt, would be using Qt for all its internal and external development needs. Well, one would be wrong.

At the time, when Nokia acquired Qt, Nokia was in immediate need for a good looking, finger touch enabled UI toolkit with a complete API set. There were already efforts within Symbian organization to create a solution. This effort was fairly resourced and did have limited success. However, this solution did not really provide the ease of development, or a complete API set and we all know that getting those right requires a lot of work. As a result, Nokia did the best acquisitions of its history.

Read more →

Sep 27, 2010

New MTJ release available

Slowly but surely Eclipse Mobile Tools for Java (MTJ) project continues to improve. In coordination with the Eclipse Helios SR1 release, we had the MTJ 1.1.1 release.

If you have received MTJ through Pulsar package, you can receive your update for the new release from within Eclipse using Help->Check for Updates. Pulsar SR1 release can be installed from here. MTJ 1.1.1 is also available as a separate download and update site as well.

This is a bug fix release, notably it fixes the bug 312045 which was causing problems on the preverifier builder for some. Also improved is the Javadoc detection for most SDKs. The complete list of bugs fixed in the release is here, and the new & noteworthy has some details on the SDK detection. I am particularly happy about the improvement this feature brings to MTJs use with the Nokia Symbian SDKs.
Read more →

Aug 31, 2010

Oracle's dislike of MIDP 3.0

The final release of the JSR 271 Mobile Information Device Profile 3 (MIDP 3.0) specification was done on December 9 2009. Unlike the earlier specifications, Sun, uhm... well Oracle, is choosing to remain very low profile about MIDP 3.0. Oracle's Java ME SDK (which replaced WTK )have not yet rushed to implement MIDP 3.0 and the NetBeans IDE seems to ignore it. What really is the reason behind Oracle's silence over MIDP 3.0?

One may quickly assume that it is because the world has moved on and Android is the future representative of the Java language on mobile phones. Hence the lack of attention from Oracle about MIDP. Although, it is true that the attention of the Java world is upon Android and not on MIDP. I believe the reason is not simply about lack of attention.

Read more →

Jun 24, 2010

Improved Opportunities for JavaME developers

There were two separate announcements this week that are both positive news for JavaME developers that are hoping to publish applications on an app store, especially Nokia's Ovi store.

On an earlier post, I had tried to explain the signing and testing criteria for JavaME applications on Nokia's Ovi store. In short, applications have two choices, the first one is to sign the application with a content signing certificate and submitting to Ovi store for testing. The second choice is submitting a Java Verified approved application which gets published without the Ovi store testing.

Read more →

Jun 19, 2010

A Numberic Retrospective of Pulsar Galielo release

Now that Eclipse Helios is just around the corner, and the hectic days of getting the release ready is over, I thought this would be a good time to look back at what was achieved on the very first Pulsar release. Predictably, I took a moment to harvest the download statistics of the Eclipse Pulsar Galielo simultaneous release to come up with some numbers that are easier to consume.

If you are not familiar with the download statistics of Eclipse, these numbers represent the downloads that went through the Eclipse.org infrastructure. That means, if you have downloaded Pulsar directly from a mirror site without the mirror redirection from eclipse.org, your download is not counted in these numbers. Unfortunately, these numbers do not include the p2 installs and updates either, because Pulsar did not enable p2 download statistics on Galileo release. This is something we are fixing on Helios.

Here is some notes about the Pulsar. Eclipse's mobile development packaging is called Pulsar. On Galielo release it provided mainly the tools for MIDP development. So it is safe to assume that these download numbers reflect mostly an audience of MIDP developers. Eclipse Mobile Tools for Java (MTJ) is the project that produces the development tools for JavaME development. Although the main distribution of MTJ is through Pulsar, MTJ also produces downloads that are independent from Pulsar. The downloads for MTJ’s direct downloads are not part of this report and the MTJ 1.0.1 release did receive an additional download of 18927 to date.

 
As you can see from the above numbers win32 is by far the most popular development platform for Pulsar. It is probably even more so than other Eclipse packages because the platforms supported by the mobile emulators are still limited. Also you will notice a drop on the number of downloads between SR1 and SR2 release. I guess, without any evidence, this is because many of the SR1 users updated through P2.

A look at the top 10 countries for the downloads reveals that a huge majority of the Pulsar users are from China. I was expecting to see China as the top country but the gap between China and other countries really surprised me.

The overall numbers indicate that despite all the excitement around the Android, iPhone application development, MIDP still has one of the largest mobile developer community on earth.

Pulsar's  first year reach performance seems to be quite satisfactory. I expect a slightly better reach with the Helios release because Pulsar is better known by developers this year. I do not expect a big jump though because Pulsar does not yet provide a well integrated solution for mobile development other than MIDP.

Read more →

May 28, 2010

No OSGi on your phone

OSGi was initially created for mobile and embedded world. I think it is the dream of an every OSGi geek dream to develop applications. for a cool OSGi engine that is bolted together with the operating system of your phone. An OSGi phone that would provide access to everything your phone can do together with all the goodness that comes from OSGi. A dream phone that would allow you to bring in your OSGi service that integrates with your cloud service, over the air when declared as dependency. Although, OSGI had a few attempts to really break into mobile phone world it is unfortunate that OSGi phone will remain a dreams for foreseeable future.

Nokia did work on an OSGi based Java environment for Symbian phones. Nokia even went to the trouble to create a JSR for it. It established a pretty ambitious R&D program around OSGi. It was actually these ambitious goals that eventually caused it to fail. The R&D program was ambitious because it not only promised to provide OSGi but it also tried to get Midlets to work together with the OSGi engine. However, OSGi aware midlets model especially the MIDP security did not fit to OSGi and the R&D effort was never able to deliver a solution that was acceptable. In my personal opinion the main flaw was on the effort was treating OSGi as another runtime on the device rather than the main engine.

Most of the effort did not get wasted on Nokia's effort though. On the older MIDP environment all the pieces of the Java environment (all JSR implementation etc..) was compiled into a single binary together with the VM and was loaded together with it. OSGi model required a flexible architecture so almost all the pieces of the Java environment was re-designed for it so that they would be separate libraries consisting of a jar and possibly a native dll. These pieces are compiled separately and are loaded on demand by VM. This architecture later converted into MIDP environment as well. The Java environment of S60 3.2 and later devices and the Java environment currently available as part of the Open source Symbian foundation code carries this architecture. A few advanced APIs such as eSWT was also created in this era.

A second opportunity was when Google started working on Android. The goals of the Android was almost a perfect match with OSGi. And this time OSGi would be the engine that runs all the services and applications of the phone which lacked on the earlier Nokia attempt. It is also known that there were members of the Android team who did know well about OSGi. It is hard to know as an outsider what really went but Android did not use OSGi and build its own version of concepts to provide similar functionality.

Although there were later attempts like the Sprint Titan platform to bring OSGi to mobile phones, they also failed when the smartphone market changed rapidly to different directions. Unfortunately, in the current climate it looks very unlikely that anyone will bother to spend the time and energy to make OSGi part of mobile phones.
Read more →

May 18, 2010

Mobile phone is the new browser

Internet, especially web has changed our world. It has become a major part of how we shop, have conversations, have relations, learn, teach etc... Web browser has been the principal tool for most of the interaction with Internet. Viola was the first web browser I have ever used. Regardless of many advances on the web technology and many browsers and browser versions that accompany them, the main capability of the web browser stayed constant.

Internet, on the other hand, did not remain constant, continued to be part of our work and leisure life. When we moved into the cloud computing era, a mindset change of how we think about computing also accompanied it. Our interaction with Internet evolved to be two way, creating content, taking part in the social networks became the normal interaction. Using cloud services for all sorts of computing needs started to be the primary choice.
The new Internet experience and cloud services, to enable their full potential, require a new browser. A browser that is not made only for consuming content but also for creating it. One that can be an almost natural part of our daily life. Our current browsers do provide a limited way to participate on the web mostly in a textual manner, It is a better than nothing interim solution. They fail completely on becoming a natural part of our life. I believe, the new browser is the mobile phone, and I do not mean just the mobile browser that comes with your phone.

I think it is easier to understand why we need a new tool for easier content creation. Active contribution has been central to Web 2.0, the concept that has been shaping the web for the last decade. We are at a point, that we expect to be able to contribute to web applications that we use. Most mobile phones already include great content creation tools on board. Camera, video, GPS capabilities already provides opportunities for content creation. Web sites like CNN's iReport do benefit from these capabilities. A quick visit to Flickr's camera finder reveals that at least one of the top five cameras on the Flickr community is a cameraphone. GPS is also another mobile phone built-in feature that is having an impact on content creation. Panaromio, is a good example of how geotagging the content, in this case photos, innovates what can be considered a legacy content. An excellent example of how mobile phones can serve our needs for content creation in new and innovative ways is the Ocarina app. for iPhone. An application that allows you to create music using the sensors of the phone and then share your creation. Applications like Ocarina is a precursor of how our new browser can innovate our latest addiction.

Of course, a mobile phone because it is mobile and with us all the time is already part of our life. However, its communication capabilities is what makes mobile phones eligible to be the browser of our life. Broadband 3G and WLAN is crucial for communicating with the cloud services. Besides its various built-in sensors, its further communication technologies, such as bluetooth and NFC, allows mobile phones to act as a gateway for all kinds of remote sensors. What do I really mean by browsing your life and how it relates to sensors, let me try to explain by some examples. An already widely used example of such applications is the Nike+ products where the data collected by sensors during sports activity is uploaded to a service using a mobile device, in this case iPod. Another similar service that I enjoy using is the sports tracker, where data is collected for outdoor sports through GPS and optionally a heart rate monitor by a mobile phone and uploaded to a cloud service. This technology can easily stretch beyond sports. Another product that consists of a wearable monitor for collecting medical information such as the hearth rate, respiration, body fluid status already exist. The product uses its own separate transmitter to transfer the collected data to the web service for further processing. I think, in the future, this transmitter will be replaced by a mobile phone software and which in turn will make the service more affordable and common. I believe what we see today are just the beginning of the kind of services that will be built around the life browsing capabilities of mobile phones.

I hope this gives another perspective on why the traditional consumer electronics companies are less relevant to mobile phone market. Mobile phones are not about consumer electronics anymore it is about the next and possibly the final round of browser wars.
Read more →

May 11, 2010

I have mentioned on the earlier post about the ovi app wizard and my brief experience on creating an app for this blog with it. Now the approval process is done and it is now available on Ovi store. Although there are a couple of annoyances with the final application that is related to my app's icon, and the web runtime on E75, I think the resulting app is a convenient way to reach to content.Please do give it a try and let me know what you think.


Also note that the above banner and the ones that I use on this site are also provided by Ovi marketing tool.
Read more →

May 4, 2010

Your mobile App. in minutes

Back in 2008, I was using a Nokia service called WidSets to provide access to the content of this blog from mobile phones. When Nokia's application store Ovi was announced, WidSets was actually discontinued and was "evolved" into Ovi Store. Until recently, evolved actually meant disappeared. Ovi did not provide the same easy and quick content publishing to content owners that WidSets provided. A few days ago, Ovi started a new service called Ovi App wizard. It is an online service that allows you to turn the RSS feed of your content into an Ovi App. After the usual Ovi store approval process it becomes available to the Nokia devices via Ovi store.

I was a big fan of WidSets and I was looking for a replacement for it ever since it discontinued, so I did immediately tried to create an App. Ovi App wizard allows you to define up to 4 feeds, a logo and an icon for your application. I have actually used my blog, twitter and slideshare feeds. The whole process of creation took about 20 minutes to complete and most of it was about creating a proper icon for the app. Currently, I am waiting for approval for it to become available on the Ovi store (approval is supposed to take a day or so ).

I am sure that some will claim that this service is just about Nokia trying to boost the number of applications on Ovi store. I personally think this is more about making the Nokia devices the preferred device to consume web 2.0 content. Considering that iPhone is the device choice for consuming web, this service, even if it has no chance of matching iPhone, is not a bad move on the behalf of Nokia.

If you are a content owner, like myself, this is another channel to distribute your content (you want to reach more people right?). And preparing your content for this channel costs nothing, not even a significant amount of your time..
Read more →

May 3, 2010

Changes on this blog's Planet Eclipse participation

If you have been following this blog through Planet Eclipse, you should be aware that the full content of this blog will no longer be available on Planet Eclipse. This blog started its life with the intention to provide information and updates around the Eclipse projects I am involved with and grew from there. Lately, the developments on technologies that I am working with and interested in are more frequently outside the scope of Eclipse. Since I want to blog about mobile and web software technology happening outside Eclipse and out of respect to the Planet Eclipse readers, I am replacing my feed on Planet Eclipse with one that carries only posts labeled for Eclipse. If you are a Planet Eclipse reader but still would like to read all the posts, you can subscribe to the full feed.
Read more →

Apr 19, 2010

Threading on Symbian eSWT

eSWT, just like SWT, implements a single threaded UI model (single-threaded apartment model). And just like SWT it provides access to UI functions from this thread only. This does not mean that you can have only a single thread on eSWT/SWT applications it means that the GUI interaction is exclusive to a designated thread. You can read more about SWT threading model in SWT FAQ. In this post, I will compare the implementation details of this model on eSWT port for Symbian and the new Qt port.

Avkon UI, that is used to implement the S60 port of eSWT, also have similar restrictions on threads. So one would think that eSWT S60 port just wraps the native Symbian UI thread since we have matching behavior. However, this is not the case with the S60 eSWT port. eSWT on Symbian actually creates two threads. Thread one runs the Symbian's UI environment which within the team we refer as the native UI thread. Thread two runs the eSWT's UI thread which is referred as main thread. Although, from an eSWT developer perspective, main thread is eSWT's UI thread but it actually has nothing to do with the native UI resources. The implementation of LCDUI on the same platform also has a similar architecture. LCDUI is specified to be a thread-safe API so in LCDUI's case the second thread (that hides the native UI thread) is more or less a necessity where eSWT's second thread is a design decision.

This design, as with any design. comes with both positive and negative consequences. The main benefit of the two threaded solution is because the real UI is run by a thread that is not directly accessible for Java applications, it is not possible for a poorly developed application to freeze the UI and eventually get killed by the Symbian OS. However, this security comes with a performance penalty. A two thread design translates to a lot of thread switching and thread switching is costly. In theory, for every call that you make to UI components, even simple things such as setting the background color for a line makes a thread switch. In practice, however both eSWT and LCDUI tries to reduce the number of thread switches especially for primitive graphics drawing by introducing command buffers etc. in the implementation. eSWT buffers all GC calls that are possible to buffer during a paint event and passes them to the UI thread at the end of the event. LCDUI also does similar on paint callbacks.

When the new implementation of eSWT port for Qt started, it was decided that the performance penalty was too much to dismiss for the gained robustness. So eSWT port on Qt is designed and implemented to have a single thread that wraps the Qt's UI thread. As a consequence of the simplified design, the implementation ended up to be identical to any other SWT port. In fact,it borrows much of the code from SWT win32 port. I see that this contributed a big deal to the maturity of the Qt port. In the earlier testing we have also noticed some performance gains. it is really unfortunate that LCDUI implementation is not able to take advantage of a similar architecture because the thread safe nature of LCDUI forces the implementation to use two threads.

If you are an application developer using eSWT or LCDUI on Symbian platform this is probably some geeky extra information that you should not worry much about and the eSWT and LCDUI implementation will care about it for you. If you are interested in the actual implementation of the toolkit, you should keep this information at the corner of your mind.
Read more →

Mar 15, 2010

Use ImageLoader with extra caution

The ImageLoader class of eSWT and SWT is a utility class for loading and saving images. At a first glance, it is a very useful little utility class. Unfortunately, it is one piece of SWT/eSWT API that gives the implementation teams a performance headache. SWT is a well performing API because it delegates most of the work to the native services. eSWT implementation also follows this legacy and because they are meant to run on more resource constraint environments they take it a step further.

Unlike the rest of the SWT, the meat of the ImageLoader is actually implemented on Java, SWT packs Java implementations of all the image codecs that it supports. According to some, Java implementation is around 20 times slower when loading an image compared to an image loaded by native means. For the best image loading performance, it is recommended to use one of the Image constructors, which loads the images natively. This advice holds true for eSWT applications as well. Do not use the ImageLoader for loading images because it will not only be slower but will also consume more memory.

So why do even the eSWT implementations fail to optimize ImageLoader? ImageLoader has a misleading name. In practice ImageLoader has nothing to do with Image it actually loads and saves ImageData. While doing that it exposes the ImageData it loads or saves on a public field. This gives no choice to the implementation but to make the whole data available up front. Furthermore, ImageData also exposes all its fields and that also has to be initialized fully when created. So what happens when on a typical scenario of loading and using an image through ImageLoader? First, the whole ImageData is loaded into these fields. This reading and encoding is done on Java and is slower. Then this data is passed to the native toolkit which also doubles the amount of memory used for that image at least until the ImageData is released. Using Image constructors works around both defects, image is loaded and encoded natively and the data is not copied to Java fields limiting the memory usage.

One option for optimization is loading the ImageData through native code, but this actually triples the amount of memory used and copied around. The image data gets created first on the native code and then gets copied to Java and copied back to native to create the native image. As a result, this is not an option used by the SWT/eSWT implementations at least for now.
Read more →

Jan 25, 2010

eSWT and Java vs. Qt on Symbian

If you are considering to develop an application for the Symbian platform there is a great chance that you have been recommended (especially by Nokia) to use Qt for the task. I have a somewhat different recommendation for you, I actually advise to use eSWT and MIDP.

It is true that Qt will be the primary technology for applications starting with Symbian S^4 release. However, according to the Symbian roadmap, S^4 release is due end of this year, and the handsets based on the release will start to sell on 2011. The good people on the Qt software actually made the Qt 4.6 release compatible with Symbian/S60 devices with the 3rd Ed. FP1 and later releases. Furthermore, .sis packages that you can bundle with your application for those earlier platforms are available. Of course, that means that you need to get your users to install a few MBs of Qt with your application. Naturally, you may actually assume that a Qt based application would have the benefit of covering both Symbian and Nokia's exciting new Maemo based devices. That is not entirely possible either because both platforms have chosen not to use Qt's widgets (QWidgets ) and build their own separately (which is explained better here).

On the other hand, eSWT is available on board for all the S60 3rd Ed FP2 and later devices and will continue to exist on Symbian S^4 based devices, so your application does not need to bundle any additional .sis files. Although we are adding new features on Symbian S^4 release, eSWT API is always backwards compatible and your code will work. I believe eSWT together with MIDP provides a good and lasting solution if you are targeting Symbian devices. _Unfortunately, eSWT solution is not without its flaws as well. eSWT is not as feature rich as Qt. Although eSWT will be adding new features constantly, eSWT team and Nokia investment on eSWT is tiny compared to Qt so it will not get as feature rich as Qt anytime soon. Tooling support is lacking with eSWT. It is the MIDP Java tooling so you will not get visual editors as you would with Qt. Although Qt's documentation may seem better than eSWT, I think SWT documentation will help you most of the time. And yes, Qt is in fact the determined future platform for Nokia and Symbian.

If I was given the task of developing an application for Symbian today, I would first look at eSWT and Java MIDP to see if that satisfies my requirements and use them if it does. And I would asses if It would be beneficial to make a Qt version of my application when Symbian S^4 becomes available.
Read more →