Gorkem Ercan

Slideset for New Features of Series 40 JavaME Platform

noreply@blogger.com (gorkem) — Tue, 06 Dec 2011 05:20:43 PST

This is the slideset that I have used for JavaOne and the İstanbul developer day event. It highlights some of the major features introduced with Java Runtime 1.0 for Series 40 and Java Runtime 1.1 for Series 40.

More information including the tools and documentation for Java is available on the Nokia Java site.

The More Capable Series 40 Java Platform

View more presentations from Gorkem Ercan.

What Angry Birds Is Using on Series 40 Phones

noreply@blogger.com (gorkem) — Thu, 27 Oct 2011 06:06:27 PDT

Rovio's Angry Birds made their entrance to the Series 40 with the Asha lineup of devices announced on Nokia World. If you have missed it Engadget has a post and video that features the mighty eagle showing off Angry Birds on Asha 303.

Angry Birds performs so well on these so called feature phones that it got people puzzled. I guess many people do not expect much from JavaME, therefore there had been questions whether this is actually a JavaME application or did Nokia open up its C libraries, or some other secret API to Angry Birds.

It is a well developed JavaME application! It does not even need access to APIs that are available to manufacturer/operator signed MIDlets. Below is a list of usual suspect APIs that Angry Birds uses as you can see it is a list of APIs that are available to any JavaME developer that targets Series 40.

CLDC(JSR-139)
MIDP (JSR-118)
MMAPI (JSR-135)
M3G (JSR-184)
Nokia UI API

So people, there is no mystery to Angry Bird's performance on Series 40, It is just an amazingly well developed JavaME application.

Nokia SDK 1.1 for Java available now.

noreply@blogger.com (gorkem) — Thu, 27 Oct 2011 04:56:03 PDT

At the NokiaWorld, Nokia announced Asha lineup of devices. There are extremely well built Series 40 devices that are likely to form a big market for developers quickly. Today, we are releasing the Nokia SDK Beta for Java 1.1 so that Java developers can start working on their applications right away.

Nokia SDK for Java 1.1

SDK is based on my favorite of the announced phones, Asha 303. Since the SDK is available today, you can develop and test your applications and be ready when devices are available on your target market.

Testing Support for In-App Purchase in Different Stages

As we are starting to accept applications that use the new in-app purchase functionality on Series 40 Java, we have enhanced the in-app purchase tools on the SDK. The IAP simulator, that was introduced on the earlier 1.0 release, now supports both offline and online testing for in-app purchase applications.

In the offline simulation mode, in-app purchase APIs will simply return the values that you have entered on the simulator to your application. This is particularly useful on the early stages of your development since it will allow you to start testing before even submitting the application to Nokia Store.

The online simulation and the test mode on the device is very similar. In this mode, SDK or the real device will communicate with the back-end servers. No monetary transactions will occur in this mode. It is possible to try out different scenarios such as failure of a purchase with the online simulation as well. The Nokia SDK manual that is installed together with the SDK provides more information on how to enable these modes.

This new emulator also significantly improves the system properties that you can access and simulate during development. All the Nokia system properties that were opened are now available on the SDK. In addition, you can simulate different values for the com.nokia.mid.batterylevel sysyem property and the com.nokia.mid.mnc and com.nokia.mid.countrycode values from the preferences.

The improvements and features are not limited to these, you can find the gory details on the Nokia SDK project. I have been using the SDK for my daily development for a while and it is already good for daily use. and available for download .

Speaking at JavaOne 2011

noreply@blogger.com (gorkem) — Sun, 25 Sep 2011 03:15:10 PDT

This year, I will be hosting a session in JavaOne titled "Getting the Most Out of the Series 40 Java Platform". As the title suggests, The talk is about the Java platfrom on Series 40 devices. I will be focusing around three topics that I believe will be interesting to JavaME developers. (1) Series 40 APIs for creating superior apps. for Touch & Type style devices. (2) Location features on Series 40 devices. (3) Monetization opportunities with the Nokia Store.

My talk takes place on Wednesday (Oct. 5) at 11:30 AM. It is at the Powell I/II room on Parc 55.

If JavaME solutions, such as the Series 40 platform enables, is in your interest, I recommend the following sessions.

Small Screens Playing a Big Boys' Game: A Playbook for Java ME in Emerging Markets (24101)
Time and Venue: Tuesday 06:30 PM, Parc 55 - Cyril Magnin I/II/III
Java Moving Out of the Box in Emerging Markets (22700)
Time and Venue: Tuesday, 07:30 PM, Parc 55 - Mission-
Open Discussion on Emerging Markets (22721)
Time and Venue: Tuesday, 03:00 PM, Parc 55 - Mission-

For those interested on the quality of the JavaME applications, my colleague Risto Helin is hosting a session together with a bunch of quality enthusiasts called Unified Testing Initiative (JavaVerified for you and me).

Why Operators and Manufacturers Are Passionate About Application Quality (25021)
Time and Venue: Thursday, 11:00 AM, Parc 55 - Mission-

Have a nice JavaOne and see you there.

Time To Renew Your Midlet's Icon

noreply@blogger.com (gorkem) — Mon, 05 Sep 2011 01:32:08 PDT

All Nokia platforms have received updates to its launcher icons recently. The common element introduced with the new iconography is the surround background shape. That means that the new icons for Nokia provided applications do not have pointy corners anymore. I guess the sharp pointy corners do reach out to human psyche and remind us of sharp dangerous objects, thus they feel unfriendly to many. If you have applications that are published on Ovi Store, I think this may just be a good time to renew them. Otherwise, the pointy corners of your icon may just stand out.

To make it as easy as possible for you, the good folks in Nokia design have prepared detailed guidelines for creating icons that matches the new surround iconography. I strongly recommend reading through the material. It covers Series 40, Symbian and MeeGo devices and also provides Adobe Illustrator (AI) and Adobe Photoshop (PSD) templates to get you started.

You will quickly notice that the guidelines recommend using 43x43 PNG images on Series 40 and 96x96 SVGT images for Symbian phones. One may think that two different icons would require two versions of the Java application. Thanks to some magic with JAD attributes, you can bundle multiple icons into a single application JAR file.

Java applications on Symbian have supported SVGT icons for a long time, you can read from the Scalable icon support document the details of how this works. In short, in your JAD file you specify the Symbian SVGT icon name in Nokia-Scalable-Icon-MIDlet-1 attribute whereas the Series 40 PNG icon is defined in MIDlet-1 attribute. On Symbian devices where Nokia-Scalable-Icon-Midlet- attribute is supported, the SVGT icon will be used. Since Series 40 does not support the Nokia-Scalable-Icon-Midlet- attribute, it will be ignored and the PNG icon specified on the standard Midlet- attribute will be used

The resulting JAD file should have entries similiar to these.


MIDlet-1: HelloWorldMIDlet, /series40_icon_43_43.png, example.hello.HelloWorldMIDlet
Nokia-Scalable-Icon-MIDlet-1: /symbian_icon_96_96.svg

If you lack the Adobe photoshop/illustrator skills, there is also an online tool that you can use to convert your existing icon. Tool generates a SVG file which you can use directly on Symbian devices . Using a tool like the inkscape, you can convert the same SVG file to PNG for Series 40 devices. Although the resulting icon is OK for Series 40 use, the result may not be as favorable for Symbian devices. This is because the tool embeds our original icon into the SVG file, which may be somewhat unscallable. For best results using a pure SVG icon is recommended.

New SDK for Series 40 Java

noreply@blogger.com (gorkem) — Wed, 08 Jun 2011 06:49:37 PDT

Beta version of the Nokia SDK for Java 1.0 is now publicly available. This new SDK is the replacement for the older Series 40 SDKs. It supports the development of the Series 40 touch and type applications. This new SDK is an initial step on the right direction for creating a better development environment for Series 40 developers.

The first thing to note about the SDK is the new installer and the SDK manager. This new infrastructure will allow developers to receive updates to the SDK. My favorite feature is the diagnostics window. Most of my development uses cloud services. The new diagnostics window allows you to monitor the network traffic. This new feature already saved me a lot of time while using some REST services.

Diagnostics window

If you have a webcam on your developer desktop, you can now use it together with the SDK to test camera applications. Keep an eye on the diagnostics window while testing your camera application, you will notice instructions to press CTRL+W when your application needs to use the camera. You need to do this only once.

In addition to these new SDK features, there are the added tools for the new Series 40 features. SDK not only introduces the route editor for simulating location data but also provides additional support for cell-id based location inaccuracies.

Also introduced the in-App purchase simulator. Yes, Series 40 is about to get new APIs for supporting in-app purchase, but more about that later. The simulation tool is not yet complete on the beta release and is provided as an alpha level tool to get early adopters to get familiar with the tools and API.

I think even in its beta release SDK provides a good alternative Java ME emulator with some bells and whistles. So give it a try, provide some feedback to the team.

Cultural implications on localization

noreply@blogger.com (gorkem) — Tue, 03 May 2011 00:38:08 PDT

An emerging pattern on mobile application stores is developers which target a limited local market initially, seek to expand their market after reaching a good amount of penetration on their initial market.

Reaching a new local market requires localizing your application however localization is not just about providing the strings translated to the local language. It gets much detailed quickly and touches cultural issues. These issues should be taken into consideration on all stages of the localization work. Here are a few tips, I have picked up regarding cultural issues on different stages of a localization project.

1. Define what should be localized

User visible text is the most obvious to localize but you should also look beyond text. Images and sounds should be considered as localization candidates as well. Unfortunately, the reasons for localizing images and sounds are usually cultural and harder to detect. For example, your great sports game may use the charge fanfare to indicate an offensive move, however on many parts of the world charge fanfare is not played on the sporting events and on those markets users do not associate it with an offensive move.

Here is a few cultural implications to consider when looking at what to localize.

Do not assume certain experiences such as the meaning of charge fanfare I have mentioned above.
Do not assume a certain history knowledge. Believe it or not but Boston tea party is for many represents a party in Boston that tea lovers attend.
Do not assume certain opinions, prejudices. Patagonia may represent a distant place for someone in Eurasia but someone in South America will have a completely different opinion about it.
Be respectful to religious and political beliefs.

2. Localize

It is essential that your localization specialist knows the target language well. I also recommend working with a specialist who is multicultural as well. Someone who does not only have a good understanding of the source and target languages only but also knows both cultures. I know on many occasions it will be hard (and expensive) to find multicultural talent but it is worth it. After all, it is the localization process that will ensure that the users on your new market will get your product and accept it.

In some cases, you should be ready to have localized versions of your sounds, images, icons in addition to text. You should leave room in your planning for the creation of these resources. It is also a good idea to implement a localization framework on your application that will allow you to easily use different versions of resources on different locales.

In my experience, for developers who use Latin characters daily, even when they pay extra attention to mirrored and double character languages, there are usually some details that were not right initially. If you are targeting one of those languages be prepared to handle them. I think the best help for mirrored and double character languages is to choose a UI technology that provides mechanics to handle them.

3. Test

It is best if the testing is done by people who are native to the target language and culture. This way you may also test if your localization was culturally successful besides being technically correct.

What I am going to work on

noreply@blogger.com (gorkem) — Sun, 17 Apr 2011 22:58:36 PDT

Every now and then, I get an email telling about a colleague has moved to "new challenges" in the company. Personally, I do not like the use of word challenge to describe a new position. It somehow resonates negative on me. Nevertheless, about a month ago my colleagues also received an email announcement of my move to Forum Nokia. Happily, my manager chose not to use the challenges cliché when announcing my new position.

Forum Nokia is the developer relationship organization of Nokia. My new job can shortly be described as creating a bridge between Nokia's R&D teams and the developers. In my case, I will be working for Java developers.

No job is interesting if there are no challenges in it, so the use of word challenge on those emails is correct. Mine is to help create a fun, profitable development platform based on Java for low end phones. A good part of my time will be spent on making Series 40 the below 100 euro phones that are based on it, a more favorable choice for Java developers. This does not mean Symbian Java is completely ignored but Java is the central development environment for Series 40, it will probably need more of my attention.

I did move to work with one of the most interesting challenge on the mobile world today.If you are interested in the opportunities that Nokia's Java platforms can provide you, keep on following and commenting to this blog and my twitter account.

MTJ release 1.1.2 is available

noreply@blogger.com (gorkem) — Wed, 09 Mar 2011 05:35:30 PST

Together with the rest of the Eclipse Helios SR2 release, MTJ project has also made its 1.1.2 release available. Unlike most Eclipse projects MTJ project introduces new features on SR releases as well. You can find the information on the new features in the new & noteworthy page. Equally important to the features is the list of the bugs that were fixed in this release.

Please note that MTJ project recently had a project move. As part of the move, the URL for its web site has been changed to http://www.eclipse.org/mtj the changes have also affected the update sites and the download sites and the /dsdp/ has been removed from them. Project team has updated the website and all the references that we are aware of, however if you notice that some link has been missed and is still pointing to the old URLs please report them.

What Nokia announcements did not change?

noreply@blogger.com (gorkem) — Tue, 01 Mar 2011 01:50:11 PST

You probably know about Nokia's announcement on its strategic direction. It is very likely that you have also read some analysis that has an analogy involving fire, platform and icy water. Unfortunately, neither those analysis nor the Nokia's own announcements did little help to software developers that are trying to understand the impact to them. So after listening to all that is happening inside Nokia as well, here is my assessment.

If you are a software developer that is targeting only MeeGo devices unfortunately Nokia will release limited number of devices using MeeGo. Unless other manufacturers can release MeeGo devices comparable to Nokia volumes, this will in turn cause the MeeGo application market to be small. You will need to decide for yourself if it is small enough to be negligible.

If you are a developer targeting on Symbian devices, very small has changed for you. Nokia is going to release as many Symbian devices as she can sell as long as it is (surprise!!) profitable. Also the current plans for improving Symbian will remain unchanged. These plans do not only involve only upcoming models but also include updates to the Symbian^3 phones that have been already sold. I can say that the development of improvements are commencing full speed.

If you are a Qt developer, it is true that you are possibly loosing some possible future devices because of the MeeGo connection. However Symbian is and will continue to provide a very large market for mobile Qt applications.

If you are a Java developer, you are not impacted at all. Just carry on, enjoy the largest device reach provided by S40 and Symbian phones, try to seize opportunities provided via Ovi store. Both S40 and Symbian Java platforms will continue to receive improvements as before.

If you have Java or Qt skills then you still can combine your skills with the Ovi store and have a reach that no other platform can provide. Or you can choose to worry about changes that may happen in years to come and do not seize the opportunity.

Be a Platform Java Developer

noreply@blogger.com (gorkem) — Wed, 08 Dec 2010 03:10:31 PST

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.

The point for JavaME developers to leave their cross-platform ambitions behind has already passed and it is time for a mindset change. Now is the time to concentrate on bringing the best possible platform user experience. Most of the time, this will force applications to utilize platform specific extensions and APIs. A big portion of the code will still be cross-platform but applications will have to create platform specific versions.

It can be argued that this is actually limiting your application's reach by choosing to optimize for selected platforms. That argument would probably hold true in the era before the app. stores. Today app. stores are the most competitive market places. An application's success on these markets depends more on the quality of the experience rather than the number of devices it can run.

JavaME developers are still luckier with regards to cross-platform use of their code. They can still share a big portion of their JavaME code for Symbian, S40 and BlackBerry versions of their applications. With the right architecture, can even reuse some of it for their Android applications.

I think JavaME developers will benefit more from their proficiency, if they learn about the platform specific features on their target platform(s). Use the platform specific APIs, attributes, system properties to create the best experience. I am very well aware that it is more work but after all satisfied users is the best way, that I can think, to make profit from your applications.

Apple deprecates Java what about Nokia?

noreply@blogger.com (gorkem) — Sun, 24 Oct 2010 10:39:08 PDT

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.

At this time details are very sketchy and decisions are still floating around but here is what I know. Nokia will continue to support JavaME on Symbian. Java's goal will be about compatibility. Ovi store will continue to publish JavaME applications. There is bad news as well. Nokia's investment to Java platform will decrease further. This will most likely effect the JavaME roadmap but as I said details are extremely sketchy.

Over the years, JavaME was overly neglected by Sun. Oracle acquisition has not changed that and Oracle continues on the same path and tries to milk the JavaME licensing cash without putting much investment on enhancing the platform. As a result, Java on mobile is not getting any innovation from that direction. On the other hand, It was already difficult for other companies to do anything on JavaME due to a pile of legalities.It is event more difficult, after the Oracle's move to sue Google over Android. Companies that has a legal department and access to alternative technologies are likely to shy away from making any major investment to improve JavaME. In the case of Nokia, Qt provides a much better alternative as its strategic development platform. However, Nokia over the years have invested a lot to JavaME and it has an established developer base. Hence, JavaME on Symbian is likely to continue as long as there are enough developers using it.

Dear developers, it is actually your call now, whether JavaME lives on or not. If you keep developing good applications on JavaME and publish them on Ovi store, it will, otherwise...

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

noreply@blogger.com (gorkem) — Fri, 22 Oct 2010 07:24:46 PDT

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.

When Qt arrived to Symbian, it did not have a look and feel suitable for mobile. It was using its default windows style and on a phone that actually looked horrible. This alerted the people who are responsible of the welfare of the Symbian's UIs. Since the former employees of the Trolltech were still probies on Nokia, they turned to the only people they knew for a solution. More or less the same group of people that tried to provide the earlier solution started to build a UI toolkit using mainly the basic graphics capabilities of Qt. The resulting work was later named Orbit UI.

Orbit was so dominant on Symbian organization that Orbit was synonymous to Qt. I recall explaining over and over to people the difference between Orbit and Qt back then. It was actually around those days when my boss.probably affected by the propaganda and the amount of resources put behind Orbit, asked if we should start using Orbit to implement Java UIs instead of Qt. My reply was, "No, we are better of with Qt".
I have steered away from Orbit for several reasons, its cross-platform story was unclear, Orbit development team did not have a history of making good APIs, it was missing functionality that was important to implement eSWT. More important from all these. Orbit was the result of human factors and did not provide a superior solution to a technical problem. Hence, It is not amusing that Orbit UI and its sister MeeGo touch (which also has a similar story) now vanishes and Qt and the new Qt Quick becomes the main developer focus for Nokia's internal and external developers. Now, Nokia's developer story becomes one that I can trust to have the eSWT implementation on.

Update: The good folks on Forum Nokia has informed me about MeeGo touch. Appearently, MeeGo touch is not going away immediately in Harmattan, however it is not the recommended UI toolkit.

New MTJ release available

noreply@blogger.com (gorkem) — Mon, 27 Sep 2010 05:58:36 PDT

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.

Oracle's dislike of MIDP 3.0

noreply@blogger.com (gorkem) — Wed, 20 Oct 2010 06:59:32 PDT

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.

The licensing terms of MIDP3 is what really troubles Oracle. MIDP 3.0 TCK is licensed under Apache License (APL) v2.0, but there is a catch. In order to gain access to MIDP 3.0 TCK, a letter agreement must be signed and accepted by the JSR lead Aplix. So what is in this letter agreement? If you do not license and JSR TCKs yourself the terms of the agreement does not affect you at all and you get access to the TCK under APL terms for free. If you do license JSR TCKs, which is the case with Oracle, then a set of conditions apply. These conditions are listed by Brian Deuser (MIDP 3.0 specification lead) on the JSR 271 final vote as follows:

No per unit royalties payments are required.
No more restrictions (or less) will be offered to Aplix.
Payment for each TCK shall not exceed $50,000/yr.
No more than usual & customary terms for the TCK are given.
No extra conditions are placed on an Independent Implementation by using the TCK outside the scope of the Specification License terms for Independent Implementations

These terms is mostly about Aplix trying to ensure a better deal for the TCKs licensed especially by Oracle. By just looking at the Oracle comments on the final approval ballot, you can see that Oracle strongly refuses the licensing terms of MIDP 3.0 TCK. As a result, Oracle, which controls the Java ME SDK and NetBeans IDE (which is open source right?), try to ignore MIDP 3.0.

Improved Opportunities for JavaME developers

noreply@blogger.com (gorkem) — Wed, 20 Oct 2010 07:00:15 PDT

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.

The first announcement of the week is about a cheaper and lighter testing for Java Verified approval. Applications that fulfill the new "Simple App" criteria can get approved for as little 75 euros. I think this is a wonderful step from Java Verified, kudos to them. As far as I can see from the tone of the FAQ and announcements, Java Verified is working on different angles to ease the approval process. Although, I am pleased with the steps that Java Verified is taking, I am not fully satisfied. I think the definition of "Simple App" should be more precise. For example the definition could just list a set of JavaME permissions that does not require full testing.

The second announcement came from Ovi store, Ovi store started accepting individuals as publishers. Earlier developers had to be associated with a company to become a publisher. This will make it much more convenient for individual developers and hobbyists to introduce the long tail applications that seems to be missing from Ovi store at this time.

The costs for getting a simple app to the store is still not within the range I would like to see. Good news is this fact is well understood by the Ovi store people as well. The steps to reduce the costs for Symbian and Qt apps are already in place. JavaME though presents complex challenge with all different parties involved that will take more time to resolve.

A Numberic Retrospective of Pulsar Galielo release

noreply@blogger.com (gorkem) — Sat, 19 Jun 2010 03:47:41 PDT

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.

No OSGi on your phone

noreply@blogger.com (gorkem) — Fri, 28 May 2010 03:50:48 PDT

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.

Mobile phone is the new browser

noreply@blogger.com (gorkem) — Tue, 18 May 2010 14:17:42 PDT

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.

noreply@blogger.com (gorkem) — Tue, 11 May 2010 03:32:16 PDT

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.

Your mobile App. in minutes

noreply@blogger.com (gorkem) — Tue, 04 May 2010 06:49:39 PDT

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

Changes on this blog's Planet Eclipse participation

noreply@blogger.com (gorkem) — Mon, 03 May 2010 03:37:55 PDT

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.

Threading on Symbian eSWT

noreply@blogger.com (gorkem) — Mon, 19 Apr 2010 05:33:42 PDT

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.

Use ImageLoader with extra caution

noreply@blogger.com (gorkem) — Mon, 15 Mar 2010 11:38:13 PDT

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.

eSWT and Java vs. Qt on Symbian

noreply@blogger.com (gorkem) — Mon, 25 Jan 2010 12:58:09 PST

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.