eSWT and Java vs. Qt on Symbian
Posted on Jan 25, 2010
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
Posted on Dec 6, 2009
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
Posted on Nov 19, 2009
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.
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.1: Screen[] screens = MobileDevice.getMobileDevice().getScreens();2: for (int i = 0; i < screens.length; i++) {3: screens[i].setOrientation(Screen.PORTRAIT);4: }
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.
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.1: Shell activeShell = display.getActiveShell();2: while(activeShell != null ){3: activeShell.setMinimized(true);4: activeShell = display.getActiveShell();5: }
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
Posted on Nov 2, 2009
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…
Posted on Oct 12, 2009
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.
