Gorkem Ercan

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.

Story behind the code

noreply@blogger.com (gorkem) — Sun, 06 Dec 2009 04:56:46 PST

Your reasons may vary but if you are a software developer you are probably reading code. And you have probably noticed some piece of code that does not make much sense, and would have been done better.

First assumption is code is badly written because it was written by a bad developer. Actually, a good part of bad written code is developed by developers who are capable of producing good quality code. So why do good software developers create bad code every now and then.

There is usually a story behind the bad code done by a good developer. The stories vary, a story can be the usual fast coming deadline or it can get very interesting. I have seen code that overrides functions so that it can provide extended documentation, or UI components hardwired to show limited elements after a user experience study although it still allowed to add more elements.

Does having a story give you a right to produce bad code? A story may make you feel better about it but it does not give you the right. What separates a regular software developer from a damn good software developer is intolerance to bad code. No matter what the story is, and who originally created the code, good software developers refactor the code to good code quality. And this is why some of the most successful refactorings have a good beer story attached.

Help for MIDP friends

noreply@blogger.com (gorkem) — Thu, 19 Nov 2009 02:23:44 PST

eSWT developers usually come from two different backgrounds. Those who are familiar with desktop Java GUIs especially SWT that are starting to do mobile development or seasoned MIDP developers who are looking for advanced UI features for their applications. Looking at the questions coming from the later group of developers on forums, a common theme is about how to implement something that they could do with MIDP UI with eSWT. Here is some help for two cases that are asked often.

How to fix the screen orientation to landscape or portrait? This feature is implemented on MIDP UIs using a Nokia specific Midlet Jad attribute Nokia-MIDlet-App-Orientation. eSWT does not make use of the any of the Jad attributes that are present on the MIDP platform. Instead it provides APIs that enables developers to achieve the same results. This also allows eSWT applications to be easily portable between runtimes. eSWT’s way for achieving fixed screen orientation is using the Screen API. Here is a short snippet that fixes the orientation to portrait for all available screens.

1:     Screen[] screens = MobileDevice.getMobileDevice().getScreens();
2:     for (int i = 0; i < screens.length; i++) {
3:       screens[i].setOrientation(Screen.PORTRAIT);
4:     }

A good thing to remember is some devices may actually plug new screens, for the best results it is a good idea to listen for Screen changes using the listeners from MobileDevice APIs.

How to put an eSWT application to background? On mobile platforms that support background applications MIDP developers achieve sending the application to background by removing the current Displayable. Here is an entry that explains how it is done on MIDP LCDUI. The same can be achieved for eSWT applications by setting the active Shell to minimized. Here is how.

1:         Shell activeShell = display.getActiveShell();
2:         while(activeShell != null ){
3:           activeShell.setMinimized(true);
4:           activeShell = display.getActiveShell();
5:         }

The example snippet takes into account that you may actually have more than one top-level Shell, which the second one may get active once the currently active one is minimized.

I will try to make more of similar kind of posts in the future. Please do comment if you have any suggestions for content. And of course. I continue to keep an eye on the Nokia forums and Eclipse discussion boards.

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.