Gorkem Ercan

MTJ release 1.1.2 is available

2011-03-09T15:35:00.000+02:00

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.

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

2010-10-22T01:17:00.003+03:00

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

2010-09-27T15:58:00.000+03:00

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.

A Numberic Retrospective of Pulsar Galielo release

2010-06-19T13:47:00.000+03:00

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

2010-05-28T13:50:00.000+03:00

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.

Changes on this blog's Planet Eclipse participation

2010-05-03T13:37:00.000+03:00

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

2010-04-19T15:33:00.000+03:00

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

2010-03-15T20:37:00.001+02:00

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.

Eclipse eRCP 1.3 on Linux Qt

2009-09-09T15:05:00.001+03:00

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

2009-08-20T14:43:00.001+03:00

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.

What happend to eSWT port on Qt

2009-07-10T14:17:00.001+03:00

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.

CSS support on Qt port of eSWT

2009-06-10T16:40:00.005+03:00

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

2009-06-08T14:53:00.000+03:00

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

2009-06-07T11:06:00.002+03:00

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.

eSWT features on Eclipse MTJ RC1

2009-05-19T15:09:00.001+03:00

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.

Barcode scanner RCP application example is on GitHub

2009-05-10T19:38:00.001+03:00

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.

Zebras on my Eclipse RCP

2009-04-06T14:10:00.003+03:00

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.

Ada Lovelace Day, an Eclipse community version

2009-03-25T15:52:00.001+02:00

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

2009-03-12T14:24:00.002+02:00

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

2009-03-02T23:18:00.002+02:00

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

2009-02-19T16:33:00.001+02:00

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.

Bundle Marketplace

2009-02-05T21:39:00.001+02:00

How come there is NOT as many eSWT/eRCP applications as iPhone applications?

The traditional wisdom on the mobile world would tell you that “there should be a large number of mobile phones with eSWT capability on the market so that it is feasible for applications to target eSWT”. I do not agree with this, come to think of it, I never did. Nokia has at least 8 models on the market that carries eSWT. I do not have the numbers for all the models but the lately released touch enabled 5800 XpressMusic sold 1 millon in a very short time. In addition to Nokia there are other manufacturers that carry S60 phones. I am aware of at least three Samsung models that has eSWT. Also there is a big number of Windows mobile based phones that has the possibility to download and use eSWT. Overall the number of eSWT enabled phones are way over the number of iPhones and iPod touches today and the number is increasing rapidly.

So what is really the reason for growing number of iPhone applications? eSWT is a toolkit that works with an application environment, nowadays it is widely used either with eRCP or MIDP. None of these application environments provide a clear revenue path for application developers, while iPhone with its application store does. So it is mostly about the money.

However, I believe there is another Eclipse technology that is also suffering from the same problem. Eclipse RCP technology is not getting the wide adoption it deserves. I know that RCP is getting some attention on the enterprise market, however on the consumer applications it barely exists. Especially, RCP applications that target consumers could use a good distribution channel that accompanies a payment system for commercial products. Simply a bundle marketplace, similar to Apple’s application store that enables the discovery and distribution of the RCP applications and OSGi bundles. Such a platform would open the way for RCP/eRCP applications to a whole new market.

A tutorial for developing eSWT Midlets on Nokia S60 smartphones

2008-12-24T11:33:00.001+02:00

There is a new tutorial in developerWorks about developing eSWT midlets. Tutorial explains how to develop eSWT based midlet applications using newly released Eclipse Mobile Tools for Java (MTJ) and Nokia's S60 3rd Ed. FP2 SDK. Author, Peter Nehrer, does a really good job explaining the basics of eSWT, Java ME Midlets and S60 platform. The result is an excellent starting point for anyone who wants to start developing eSWT based applications on Nokia S60 platform.

More on Mylyn Connector for ScrumWorks

2008-10-07T00:53:00.002+03:00

I have released a preview version of the Mylyn Connector for ScrumWorks that I have blogged about some time ago. There is now a google group that hosts the update site.

I call this a “preview” version because this is a read-only version of the connector. After giving it some thought, I have decided not to make this open source. It is funny, whenever I do something related to Eclipse I assume that it should be open source. However, After struggling with my reflexes for a while I reached the conclusion that open sourcing this plugin is not really essential for Eclipse.

If you are using ScrumWorks and Mylyn, please give a try and provide feedback on the group, it will be highly appreciated.

Eclipse Mylyn connector for ScrumWorks

2008-08-24T23:26:00.005+03:00

Hi, My name is Gorkem and I am a Mylyn addict. Mylyn makes it so convenient to work with my tasks, switching between them etc. However, I was trying to quit lately.
I use ScrumWorks for my daily work and a Mylyn connector ( plugin(s) that enable Mylyn to retrieve/update data ) to ScrumWorks did not exist. This meant, I had to do a lot of copying and pasting between two tools. Obviously, this manual synchronization effort was futile and I had to give up on one. Since, It is not possible to give up on ScrumWorks, I decided to put Mylyn aside. I tried for a week or so but once you get used to the stuff it is hard to quit.
On a moment of desperation, I thought, I have some experience with developing Eclipse stuff that connects to servers. If I get enough cappuccinos to my system, I can develop a ScrumWorks connector for myself. It turns out I was right, after giving some part of my night’s sleep, I have it. My Mylyn connector that allows me to retrieve and update backlog Items and tasks. I can also add tasks to backlog items and of course it works in great harmony with the rest of Mylyn.

I am impressed by the way Mylyn handles the UI for a connector. Once you get the data mapping right the UI almost does itself. Unfortunately, this can be a challenge since Mylyn lacks API and extension point documentation. There could be more extension points but it looked like Mylyn team is already aware of it. On the positive side the code follows well known patterns so after some code reading, I was able to figure them out.