Gorkem Ercan

What else have been keeping us busy

noreply@blogger.com (gorkem) — Mon, 02 Nov 2009 13:14:23 PST

Nokia’s Java UIs team has been quite busy getting the eSWT port on Qt ready for the last 18 months, however what we have been working on has not been limited to eSWT port on Qt. We have been running a parallel project called OpenLCDUI. The goal of the project is to create an open source ready implementation of MIDP’s GUI toolkit (LCDUI) using eSWT.

Initially, the development is done using eSWT on Symbian while the rest of the team is getting the Qt port ready. As a result, OpenLCDUI is proven to be able to bring MIDP UI support to any platform that has eSWT. Since eSWT’s Qt port can run on any platform that Qt can the list of possible platforms is quite extensive. This implementation will be open sourced together with the rest of the S60 Java Runtime as mentioned here and will provide a cross-platform alternative to developing mobile Java UIs.

Nokia’s Java UI team also has some other interesting stuff cooking up that I will be posting about soon.

So the future mobile Java…

noreply@blogger.com (gorkem) — Mon, 12 Oct 2009 12:36:35 PDT

About a year ago, I have blogged about the future of Java on the mobile which also triggered ideas whether Android is going to replace mobile Java. I can not tell if Android will be the only mobile Java platform in the future but I think it is going to be a major factor while defining the future mobile Java. So what does the future hold for mobile Java?

Nothing else is as certain on mobile development as the developers need to deal with different operating systems, programming languages and APIs in the future. Android applications will be developed mostly using the Android flavor of Java, iPhone will have Objective-C, Nokia will push Qt to Maemo and now open source Symbian, there will be Palm, RIM and of course Windows Mobile. All pushing its own programming language, API etc.. There will be fragmentation, or it will be labeled as choice and claimed that it is good. So the future mobile Java does not really have to think about the fragmentation, the fact that it is the same programming language is defragmantation already.

Curiously, developers do not seem to mind the diversity of development platforms on mobile as long as it provides the features needed for good applications. For years Java ME had been used analogous to MIDP and MIDP meant limited. Now that the JCP for Java ME is on a complete halt, MIDP will become obsolete. So the future mobile Java should be feature rich and extendible, much more than MIDP, at the level of what Android APIs provide.

And the open source thing. Nobody should have the illusion that my grandfather, an enthusiastic mobile phone user, will pull the Symbian or Android code and start fiddling with it. Most of the developers in the industry won’t do that either. Then how come open source matter to mobile platforms? The main reason is most mobile platforms are not enough to be competitive (iPhone is one of those exceptions). Adopters of the mobile platforms needs to develop differentiator features on top of them and sometimes add enablers to the platform for those features themselves. Collaborating on those easily is made possible with open source. Since the base platform is not really the differentiator then it makes more sense to share the cost of developing them. Today Java MIDP has a similar situation, MIDP platform itself is not competitive and it would make sense to share the costs of developing and extending it. So the future mobile Java should have a commercial friendly open source license and a community that allows open collaboration.

Java is the most familiar programming language. Familiarity with the programming language is a major factor for developers when choosing a technology for a project. Google Application Engine, Google Web Toolkit and Android is a good demonstration of taking advantage of the Java programming language (as opposed to Java Platform). The ability to use the latest and the greatest language features, together with the APIs that are familiar to developers is an exceptional advantage for technology adoption. So the future mobile Java should include the latest language features, together with a larger enough subset of standard libraries that will allow developers to use what they are already familiar with.

I think without such a Java platform for mobile, mobile Java will cease to exist on mobile. Android will be the only platform that will be attracting the Java developers. I guess this alone should make the other mobile platforms and especially the Symbian foundation be interested with a new generation mobile Java. Symbian Foundation has not yet announced a Java Platform from Symbian foundation so we are yet to see their move but I think Symbian would possibly be a good host for a mobile Java environment.

This post is dedicated to Snoopy who had been part of the family for the last 16 years until last Saturday. Thanks for your friendship, sleep well.

New release for eRCP on Qt

noreply@blogger.com (gorkem) — Tue, 06 Oct 2009 08:33:12 PDT

There is now a new eRCP for Linux Qt release available from eRCP downloads. This release includes bug fixes for the eSWT port on Qt. Rest of the eRCP plugins have no changes. You can see a list of changes from release notes.

As always we would like your contributions, the easiest way to contribute is to download the release, test and report bugs. For those that would like to get their hands into the water, we are posting bugs with “helpwanted” keyword to bugzilla. If you would like to help with implementing the full SWT on Qt this bug may be interesting for you as it is the first step towards the SWT implementation.

Eclipse eRCP 1.3 on Linux Qt

noreply@blogger.com (gorkem) — Wed, 09 Sep 2009 05:05:22 PDT

eRCP team have been working day and night with eSWT port for Qt. We have resolved some of the immediate problems and integrated with the eRCP builds. An early access package for eRCP on Linux Qt now exists. You can download it form the usual eRCP downloads page. This is the very first attempt to create an eRCP package using our new Qt port, this means that it has problems. We want to fix them so please take time to report them.

Also under discussion, is creating similar eRCP distributions wherever Qt is present. However, we need help. We are short on people who can help with the packaging, testing and fixing stuff for other platforms. If you think you can help please drop a line to ercp-dev mailing list.

If eRCP is not your thing but you think that a Qt port for SWT would be great, that idea is still on the table looking for backers. Please use the ercp-dev mailing list again to express your interest to help. I know that it is odd to express interest for full SWT on eSWT mailing list but until SWT community picks up the idea this will have to do.

OpenVG on Eclipse eRCP

noreply@blogger.com (gorkem) — Thu, 20 Aug 2009 04:43:18 PDT

I have posted earlier eRCP project is getting a Qt port for eSWT as a contribution from Nokia. The contribution is on its way and you should expect the first experimental eRCP builds on Linux soon. Qt announcement is an important one which enables that eRCP on more platforms. It also provides Eclipse community with a starting point for a full SWT port on Qt.

While the news of the Qt port is fresh, eRCP project received a new contribution for another UI technology. Microdoc is contributing Java bindings for OpenVG to eRCP project. OpenVG is an API designed for low level hardware accelerated 2D vector graphics. OpenVG is essentially a mobile device technology utilized mostly by cell phones and handhelds, therefore it is a good match for eRCP.

Contribution also includes samples for OpenVG. Once the contribution is blessed by the Eclipse legal process the team(with its new member from Microdoc) will work on it to integrate it with the existing eSWT ports and will create OSGi bundles for it.

Joy of sharing

noreply@blogger.com (gorkem) — Thu, 30 Jul 2009 05:14:13 PDT

I am having my longish summer vacation and having a good time (even started worrying that it is going to end). I have been using this music service called Spotify during my holiday so far and it has been serving me well. I like to share it with the readers of this blog so I will be giving away a Spotify invitation. Please tweet me if you are interested but before you do be absolutely sure that Spotify is available on your location.

Nokia Test for Scrum

noreply@blogger.com (gorkem) — Tue, 21 Jul 2009 05:33:35 PDT

I have seen several references to this test that Nokia uses to identify the progress of Scrum practices on her development teams. The test is genuine. In fact, when Nokia decided to use agile software development processes for all its software development on a bold move I was interviewed for a video that introduced Scrum to the Nokia organization.

S60 Java team, which I was part of, was already using Scrum at that time. Incidentally, I was the scrum master of the eSWT team. Having scrum master experience was a rarity in Nokia back then and several member’s of the team had taken the test at that time. After a few years later, scrum masters are no longer rare and I am glad to see that Nokia’s huge effort and experience started to become valuable for others outside Nokia.

Uhh… yes, eSWT scrum team scores around seven on the test.

What happend to eSWT port on Qt

noreply@blogger.com (gorkem) — Fri, 10 Jul 2009 04:18:13 PDT

In case you are wondering what happened to Nokia's contribution of the eSWT implementation using Qt here is an update. If you are hearing about such a contribution for the first time, you can read the details in this earlier post.

The legal check for the contribution has been completed and we are now clear to check the code into CVS. However, we have a slight delay now. All the developers of the Nokia's eSWT team that have commit rights are on vacation (as illustrated by footage). Our original plan was to complete the contribution before the summer holiday's started but the legal check took longer than we have expected. Nevertheless, the code will be available in late August, and will start spreading the eSWT love to new platforms.

New Java for S60

noreply@blogger.com (gorkem) — Wed, 01 Jul 2009 01:09:15 PDT

Nokia Java Runtime 2.0 for S60 (JRT 2.0) has been released for beta testing and now available from Nokia beta labs site. This is a package that upgrades the Java runtime on the phone (tested with Nokia 5800 XpressMusic, and N97) with this new one. This is the first time we are testing the independent release/upgrades of Java Runtime from S60 releases. In the future this will allow us to deliver the latest and greatest JRT to older phones.

Some of the new features and improvements that will be noticeable (also listed on release notes) are one-click application installation, application launch user experience, and execution performance. I must tell about a feature that I am proud of and can be interesting to the readers of this blog. The Java installer in JRT 2.0 (the application that installs midlets) is itself a Java application. In fact, the UI(prompts etc. ) for the installer is developed using eSWT. I am very excited about the new installer because it proves that eSWT can be used to create native looking UIs, even ones that are integrated to the system.

CSS support on Qt port of eSWT

noreply@blogger.com (gorkem) — Wed, 10 Jun 2009 06:48:43 PDT

As I have blogged on my earlier post, we are replacing the eSWT implementation on Nokia S60 with a Qt based one. As part of the port we have experimented with some new cool features. One of them is the CSS styling support.
Here is a video of a demo that is showing the feature. Some of notable things on the demo are linear and circular gradient backgrounds and rounded corners on all widgets. Also styles actually set a top margin to some of the widgets and that works perfectly together with GridLayout used.

Of course no eSWT demo is complete without running the same on mobile. Here is the same example application running on Nokia S60 SDK.

The current state of the contribution is it is submitted to Eclipse for IP check. We are hoping to make the code available as soon as that completes. In the meanwhile, we are looking for individuals and companies who are willing to contribute to the effort to complete the implementation to SWT level APIs.

Comments Open for eSWT-LCDUI bridge API

noreply@blogger.com (gorkem) — Mon, 08 Jun 2009 04:53:42 PDT

I have posted the draft API for using eSWT widgets with LCDUI on a bug report. This is one of the features that I have blogged about on my earlier post and it has been a desired feature for LCDUI developers on MIDP platforms since the day Nokia started shipping eSWT. The API has a similar structure to SWT-AWT bridge API and allows embedding of eSWT widgets into LCDUI components.
This API not only aims to provide LCDUI based applications a path to gradually move to eSWT but also enables the platform vendors to gradually implement eSWT APIs on their plarforms as it hides the details of eSWT.

Reflections of Symbian Foundation and Nokia S60 Java Runtime Roadmaps on eSWT

noreply@blogger.com (gorkem) — Sun, 07 Jun 2009 01:08:13 PDT

I have been meaning to write about the future plans around eSWT for a long time. The recent announcements of Symbian Foundation roadmap and Nokia S60 Java Runtime roadmap has presented the perfect opportunity so here it is.

Let’s start with the major change. As stated on the Symbian roadmap, with Symbian^4 release, a Qt extension called Orbit will replace the existing Avkon UI library of the Symbian. Therefore, Nokia’s eSWT team had been working on an eSWT port using Qt for some time now. We now have full eSWT libraries implemented and running on several platforms including Linux, Maemo, Nokia S60 and win32 (probably runs on Mac too but it is never tested). We intend to make the implementation available as soon as we can on Eclipse eRCP CVS.

I know that there are many in Eclipse community interested on a SWT port on Qt. I have both good and bad news on that. The Qt implementation is done with a different approach compared to earlier eSWT ports. It is implemented in a very similar way to SWT ports rather than eSWT implementations. We have always considered that this implementation would be completed to extent full SWT APIs hence the existing code is suitable for extending to SWT. The bad news is, Nokia’s eSWT team will not do it. We would really like to complete it to SWT ourselves but our expertise and priority is on running eSWT on mobile devices. This does not mean we will not work with people who would like to contribute to a full SWT port. We also want to see a full SWT on Qt and will cooperate with contributors towards that goal. If you would like to contribute to such an effort please come forward and let us know.

A quick look at S60 Java Runtime roadmap reveals some of the features that are planned for eSWT. These features are going to be available on devices together with the Qt based eSWT. I will not go awfully detailed with all those features but rather introduce what is planned but expect detailed posts about them in the future here.

Improved MIDP interoperability: This work is divided into two areas. Improving the coding experience of MIDP developers by introducing new APIs. These APIs will hide some of the common tasks of developing eSWT based UIs by providing utilities.The second part enables the use of rich eSWT widget set within MIDP’s LCDUI components. This works in a similar way to SWT’s AWT bridge. Some of these APIs are drafted and will be open for comments this week on Eclipse bugzilla.

CSS based styling: E4 project is also introducing CSS styling to Eclipse as well. Current eSWT approach is different from e4, though. Current implementation is providing widget level CSS styling via the method Widget.setStyle(String css). I will be posting a demo video and more information about this. Stay tuned.

Animations API: At the moment, this is an early implementation of the SWT animation APIs drafted as part of e4 project. These are implemented using the Qt’s new Animation Framework.

Multi-touch and gestures: No mobile UI toolkit is complete without these nowadays. The details on these are sketchy at the moment. We are investigating several platforms and APIs to come up with an API that can be implemented on all platforms easily.

If you are willing to participate on any of the work that is happening around this new eSWT platform or any of the new APIs. You can contact and become part of the developer community from the eRCP mailing list.

Nokia Ovi store and Java verified confusions

noreply@blogger.com (gorkem) — Wed, 27 May 2009 03:41:28 PDT

Nokia has launched is application store called Ovi store yesterday. Store seems to carry a lot of good content even today. I was browsing some of the content yesterday and I have even marked one or two applications which I am planning to purchase on the next convenient time (read when I can play with them). I guess this the whole idea about application stores.

I believe Ovi store is the first application store to carry Java ME applications. Therefore, if you are a Java ME developer the chances are you are interested on publishing your application to Ovi store. It seems like there had been a confusion among the Java developers about the acceptance criteria for the Java ME applications. Frankly, I have read the guidelines provided and I was confused as well. So I asked the guy who knows the guy to clarify. Here is what I have been told.

Java ME applications are accepted to the Ovi store only if they are able to meet Java Verified criteria. If your application is tested and verified by the Java Verified program, Ovi store will accept it. This does not mean that going through the Java Verified testing is the only option. You can also submit any VeriSign signed Java ME midlet to Ovi store. You still need to make sure that it meets the Java Verified criteria because it will be tested by the Ovi store before being accepted. Before anyone asks, I do not have any information if there are additional costs involved with Ovi store testing and also do not know about the time it takes for testing.

I hope this clears the confusion a bit. I somehow think that I would lean towards going through the Java Verified process if I was allowed to publish to Ovi. But I have no experience with the Java Verified so the comments are open for opinions on that.

Of course, this post would not be complete without hooking it to the eSWT. You can also publish eSWT based midlets to Ovi store. eSWT is supported by all these Nokia devices. And if your eSWT application makes it big, remember we love (chocolate)doughnuts over here in eSWTland.

eSWT features on Eclipse MTJ RC1

noreply@blogger.com (gorkem) — Tue, 19 May 2009 05:09:09 PDT

Eclipse MTJ project has done the MTJ 1.0 RC1 release yesterday. MTJ team has been working on bringing in new features and completing the initial set of APIs. RC1 release marks the feature freeze for the MTJ 1.0 release and this is a good time to test MTJ and report any bugs.

A couple of new eSWT features are also included in this release that makes me smile. The “New Midlet Wizard“ now includes an option for creating a Hello World eSWT midlet. When this option is selected the wizard will create a simple midlet that uses eSWT.

There is also code assist template support for eSWT’s mobile extension widgets when using the java editor. This feature extends the SWT templates to include the eSWT specific widgets.

I hope, you have as much fun using the new features as I had when developing them. Please keep the bug reports and enhancement requests coming.

Follow @GorkemErcan

noreply@blogger.com (gorkem) — Mon, 18 May 2009 02:33:23 PDT

Yeap, you guessed it, I was a late comer but like most of the free world, and Oprah. I am on Twitter. Come follow me on Twitter! @GorkemErcan

Barcode scanner RCP application example is on GitHub

noreply@blogger.com (gorkem) — Sun, 10 May 2009 09:38:37 PDT

A few weeks ago, I have blogged about a RCP application of mine that demonstrates barcode recognition with a webcam. I have developed the application using Java Media Framework(JMF) and zxing library together, you can read the details from my earlier post. Anyway some people reacted to the post and wanted to have a copy of the code. I finally got the time to share the code on github. Code is basically an example that demonstrates how it works. I am not sure at this time if I will enhance the application and to what direction however I am open to suggestions. One idea is to create a eRCP/RCP and possibly RAP single sourcing example application.

Also I should note that this is the first time I did something useful on GitHub and I must say I am impressed.

Is Java ME staging a comeback?

noreply@blogger.com (gorkem) — Tue, 05 May 2009 04:18:25 PDT

It has been said that Java on mobile phones is on its way out. Frankly, the odds were not on the favor of Java ME on a rapidly changing industry. Java ME is old, carries a lot of excess for the sake of compatibility, innovation is slow, it is not as feature rich and fragmented and so on... Lately, I have started to observe a tune change from a hating old lover to a sorry one. Curiously, change is not happening because there had been great changes on Java ME.

Unfortunately, opinions are changing because alternates to Java ME are not able to provide a solution or years away from presenting a credible solution. Today, Java is the only technology that provides a working solution for cross platform mobile applications. I think industry is also starting to realize the fact that despite all its faults, Java was able to provide some solution. It is discovering, as it becomes familiar with the new technologies, behind all the shine and promises, the same or worse problems of the Java exists.

I am basing this suggestion to several of my observations. I have seen an increase in the number of Java ME developers using eSWT. This is significant because eSWT is relatively new and developers are usually choosing to use it for new and more capable applications. Another observation comes from my conversations with ISVs. Although numbers vary, one ISV told that about 75% of the new work they got was on Java so far this year. Also, Java ME remains the first client choice for server based applications, such as the one I have blogged about earlier or the mobile maps applications from Ericsson.

As I have said earlier this is not happening because the existing problems are solved. Alternate technologies are good technologies as well, there is nothing fundamentally wrong with them. Eventually, they will be able to fulfill their promise. This comeback however may provide Java technology providers a signal that it is worth to make the investment to solve the remaining problems and enhance further the mobile Java. So what do you think? Will/should the industry respond to the call or just let time do its thing?

A MIDP cloud platform

noreply@blogger.com (gorkem) — Wed, 22 Apr 2009 05:02:57 PDT

I was an early previewer for the Nemo platform from Everypoint. Everypoint is a mobile startup company from Boston. Their platform is based on MIDP 2.x so it is probably usable on most of the mobile phones today.

Platform includes a scripting language and a vector graphics engine for creating the UIs for applications that are based on this platform. Actually, there is nothing impressive about a scripting language on MIDP nowadays. Nokia’s own Widsets platform had that for a long time. Also the current version of the JavaFx mobile is mostly about scripting combined with vector graphics. Before anyone asks, I do not believe these vector graphics or graphics emulated UIs are the viable answer to the UI problem on mobile Java. The native smartphone UI is really powerful today and the real answer lies on APIs to unlock the native UI to Java applications. If you have been following this blog you know that is the definition of eSWT.

What is more interesting about the Nemo platform is the cloud computing capabilities that they have baked into the platform. They have a bunch of Cloud Services which runs on Amazon’s EC2. These services provide push notification and synchronization of content to the client. Although I was not able to test it extensively myself but service is claimed to be very efficient. I know, Widsets platform I have mentioned above, also have some similar services but Nemo cloud services seems to aim a broader range of applications.

I believe that the mobile cloud computing is a somehow forgotten area where large companies barely exist. It is pleasing to see that startups are discovering this and moving into it.

Zebras on my Eclipse RCP

noreply@blogger.com (gorkem) — Sun, 10 May 2009 09:41:15 PDT

I have been working to create a MIDlet demo application that demonstrates a web hybrid application using eSWT’s Browser. My initial idea for the demo was simple, using the camera on the phone, MIDlet would scan a barcode for a book and gather and display information with JavaScript on the eSWT’s Browser. Unfortunately, things did not go as I have expected. Although the camera integration works pretty good on eSWT as I have explained on my earlier post. The multimedia API on Nokia S60 does not implement the necessary stuff for focus control so it is not possible to focus enough to barcode and get a clear picture. To cut a long story short, I had to change my demo so that it does not need barcode scanning. It is still using the camera, but this time it integrates with Flickr using JavaScript on the Browser. There are many cool details to this application and I will have posts on this demo application later.
However I have become familiar with a very useful library called zxing (Zebra Crossing) while working on the original idea. It is an image processing library for 1D/2D barcode images. It supports all the major barcode formats and recognizes them magically. Since zxing is originally targeted for mobile phones it is a very small and good performing library.
Since I found this library amusing next thing for me was to create an RCP application that is capable of recognizing barcodes. So I have turned the zxing into an OSGi bundle, also implemented a piece so that it can work with SWT/eSWT images as well. The bundle can now be readily used both on Eclipse RCP and eRCP applications including Sprint’s Titan.
The next step was to use a library so that I can use the camera attached to my PC to capture images and scan the barcode. I have used Java Media Framework(JMF) API to do the job. Although the API is big and complicated once you understand the API (which takes hours of reading) it does the job. I have also created an OSGi bundle out of JMF but since the API requires native code and some initialization/installation step, I still need to work on it to make it work smoothly.
As you can see from the above screenshot my RCP application is an experiment to prove that it works. Overall, I am satisfied with my home made barcode scanner application and even started to make plans for creating a library application for the family library (or the automatic shopping list application my wife has been asking for).

UPDATE: Code for this application is now publicly available, see details on this post.

How to use Mobile Media API with eSWT

noreply@blogger.com (gorkem) — Tue, 31 Mar 2009 05:13:58 PDT

On mobile Java world Mobile Media API (MMAPI, aka. JSR 135) is the API to use for playing videos and music as well as accessing the phone camera. Basically all the multimedia development is done through this API on mobile phones.
Video support and the camera support requires the MMAPI to be used together with the UI toolkit. Although there is plenty of information on the MMAPI, because eSWT is a young toolkit, it is hard to find information on how to use it together with eSWT.
The cue for using MMAPI and eSWT is in the way the VideoControl is initialized. The rest of the use is similar, if not same, to other toolkits. Below is a snippet that shows how to initialize the VideoControl to use an eSWT Control. If you pay attention to line 5 of the snippet there is a call to Control.setParent(). This method must be called, regardless if the eSWT implementation supports reparenting or not. The actual initialization of the video to control actually takes place in this method. Initialization is delayed until this method is called because MMAPI does not provide a mechanism to provide arguments during control initialization and eSWT requires at least the parent Control to properly initialize.

1: Player player = Manager.createPlayer("capture://video");
2: player.realize();
3: VideoControl videoControl = (VideoControl) player.getControl("VideoControl");
4: Control vControl = (Control) videoControl.initDisplayMode(VideoControl.USE_GUI_PRIMITIVE, Control.class.getName());
5: vControl.setParent(shell);

A complete example that shows how to take a picture using eSWT and MMAPI can be found here.

Ada Lovelace Day, an Eclipse community version

noreply@blogger.com (gorkem) — Wed, 25 Mar 2009 06:52:14 PDT

I was reminded that yesterday was Ada Lovelace day. On Ada Lovelace day bloggers are asked to post about women they know and admire in technology. So I would like to use the opportunity to highlight some of the women that I have met and\or witnessed the excellent work they are doing in Eclipse community.

Kathy Chan from the Eclipse WTP web services
Veronika Irvine of the SWT project
and last but not least Kim Moir

This is by no means a complete list and it is not intended to be. Please feel free to enhance the list in the comments or through your blog.

BiDi support on eSWT

noreply@blogger.com (gorkem) — Thu, 12 Mar 2009 05:27:22 PDT

Bi-directional (BiDi) language support is one of the rare areas where eSWT acts different from the desktop SWT. Mobile phones are personal devices where it is desired that the language selected for the device determines the language for the applications. On the other hand, it is more common on desktop PCs that some applications, and IDEs especially fall into this category, are desired to have a different language support than the platform’s selected language.
BiDi support in SWT and eSWT is specified to be supported through the use of SWT.RIGHT_TO_LEFT flag on Control creation. The difference on eSWT is it really does not. eSWT implementations currently do not support explicitly setting of the SWT.RIGHT_TO_LEFT flag on Controls. So it is not possible to force orientation on eSWT Controls at this time. There are currently plans to support these flags in the future on platforms where it is possible.
The second difference is the default orientation. eSWT implementations inherit the language direction from user selected language of the device. That means, on a mobile phone that has Urdu as the selected language, the orientation will be right to left. This is different from SWT where directionality is determined by use of command line parameters or system properties as explained in here. There are also plans to support a system property to determine the default language direction for eSWT. Of course, such a property will not make too much difference in platforms such as MIDP but it can get handy for eRCP applications.

Eclipse marketplace inspired by the gaming industry

noreply@blogger.com (gorkem) — Mon, 02 Mar 2009 13:21:47 PST

I have blogged about the need for an Eclipse marketplace on an earlier post. Since I am a techie who knows about bundles, I have called it “bundle marketplace” but Eclipse marketplace is more friendly. The post revealed that others in the community were supportive of the idea. Moreover, I have discovered about the renewal of the EPIC, which can present an opportunity to make the marketplace happen.
I have started with the marketplace idea initially when the Equinox application model demo was made available two years ago. The demo shows the use of OSGi Application Admin Service specification to manage Eclipse applications. I was suffering from several Eclipse installation for different purposes syndrome back then. So I decided to put together my personal RCP application to manage those instances.
My inspiration for the RCP application was actually the Steam gaming platform that I used to use actively. This is an application platform that let’s you buy and download full games. It also keeps them up-to-date and informs you about the changes and releases. Sounds familiar? Here is how it works. On most of the time, the application is an icon on the tray. It manages the game updates, installs when idle. It also provides a menu as you can see on the screenshot below to reach your games and other stuff.

If you click the Games menu it opens up your list of games ( read applications here ).

There is also the store view which is essentially a web application in the embedded browser.

So I decided, I want the similar kind of experience for my Eclipse installations. So I started coding a RCP application that would most of the time sit on the tray and would launch my applications. Actually that part went smoothly and I was able to do the listing and launching of the applications. Introducing different Eclipse configurations as applications was a bit pain but it worked. Then, I have turned my attention to installing, and updating but remember this was two years ago, there was no P2! So that’s where I have stopped.
After the talks about the marketplace started I have checked back to my SVN and I still have the code. If a project to mix the capabilities of P2 and the EPIC to create a client is started I would be willing to contribute this work. Further, with the use of new SWT Browser APIs (for cookies and calling Java from web pages) on 3.5 stream, I think it would be possible to create web hybrid application as the front end for the Eclipse marketplace that integrates with this client and therefore with P2.

Eclipse Mobile Industry Working Group

noreply@blogger.com (gorkem) — Thu, 19 Feb 2009 06:33:23 PST

I am very pleased about the progress that have been made on the very first industrial working group of Eclipse. The initial discussions about a “Mobile Industry Working Group” was started during EclipseCon 2008. This time he initial discussions did lead to some progress and EMIWG got established with its initial participants as Nokia and Motorola with this charter.

Recently, RIM, SonyEricsson and IBM have also announced their participation on the working group. With their participation, I think the working group is now covering a good portion of the industry. Come to think of it, it covers most of the manufacturers that carry Java ME, however I must note that the group’s scope goes beyond Java ME and covers mobile web and native. Currently, an effort started for defining a “Mobile Application Development Kit” that aims to define and package Eclipse projects for mobile development. Now that the momentum is growing around the working group, I think we will possibly see some goodness coming from this very first Eclipse industry working group. If you are interested to see what is it about, or participate, you can find information including the participation information on the wiki.

Before anyone asks; yes, “Eclipse Mobile Industry Working Group“ is a bad name also the “Mobile Application Development Kit” is no good either. There are a few new names proposed for them and new proposals are welcome.

Touch enabling Java ME applications

noreply@blogger.com (gorkem) — Mon, 09 Mar 2009 02:29:23 PDT

I was reading a mini review of the Nokia 5800 xpressmusic phone. Blog entry complains some that even though the phone has a big screen, the virtual keypad takes a lot of space and the Java applications can not really take advantage of the screen estate. I think the below screenshots of the same MIDlet with and without the virtual keypad illustrates the problem. Actually, this problem is not entirely phones fault.

One interesting fact about the Nokia 5800 is it is the first touch phone that carries eSWT on the device. If you are a developer who is using eSWT to develop Java ME applications, (or a user using only eSWT applications), you can stop reading here and enjoy your favorite beverage. eSWT does not have a virtual keypad that takes screen estate so the below explanation does NOT apply to eSWT applications.
I should first start by explaining why do we have the virtual keypad anyway. The main reason for Nokia to carry eSWT as an alternate UI toolkit on devices is MIDP’s UI toolkit (LCDUI) lacks the flexibility and the features that are available on modern smartphone platforms. In order to overcome the lack of features, MIDP developers create their own UI components using the basic graphics drawing capabilities of LCDUI on a full screen Canvas. Many of the applications (GMail mobile client, Opera mini etc. ) today draw their widgets. There are even UI toolkits that are build on the same design. These applications and frameworks are not based on the components of the platform, as a result they need to handle the touch interaction themselves. Since the size of the touch enabled Java ME device market was small, most applications ignored touch and did not have this support . Hence, the virtual keypad was introduced to touch devices so that the applications would still work even if they were not adjusted to touch use by its developers.
Now the instructions on how to get rid of the virtual keypad on a Nokia S60 device?"
As a user, there is a well hidden preference that you can use to disable to keypad. It can be reached from Settings –> Application Mgr. –>Installed Apps. then select your MIDlet from the list and goto Suite Settings, On Screen Keyboard is the first option.
As a developer, If you have enabled touch for your application then you can use the Nokia-MIDlet-On-Screen-Keypad attribute to configure the virtual keypad feature. More information on the attribute is available in this wiki article. Another good resource for touch enabling Java ME applications is this JavaOne presentation that I and Aleksi Uotila presented last year.