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.
Dec 9, 2008
Nov 26, 2008
- eRCP CVS has moved to RT repository. We took the opportunity and restructured the repository. The old and new locations of the projects are listed here.
- eRCP developer’s mailing list is renamed to ercp-dev. Curiously, this is the mailing list we have used before moving to DSDP so in a way we have returned to our original mailing list.
- eRCP user’s newsgroup also moved. The new newsgroup is eclipse.ercp.
Now with the new move, I hope we will be able to create more synergies between the runtime projects and will be able to raise the awareness to eRCP and the use of Eclipse technology in mobile runtimes.
Nov 21, 2008
Nov 18, 2008
Mobile industry is transforming rapidly. Mobile operating systems and runtime stacks are at the center of this change. Mobile Linux, Android, and the lately announced Symbian Foundation, the trend is clear. The Mobile OSs are becoming license free and in most cases open source.
The same trend can also be observed on the runtimes that run on these mobile platforms as well. WebKit, which most (S60 , iPhone, Android) of the mobile browsers and web runtimes are based on, is license free and open source. Python, license free and open source. Flash runtime, has no license fees and open source. Java, NOT free and NOT really open source for the manufacturers to ship.
Things do not look very good for Java on the innovation front as well. Manufacturers have to deal with branding and compliance test license costs for mobile Java. This is an additional cost on top of acquiring or developing the Java runtime itself. After all the costs, the end result is MIDP which is not really the bang you want to get for your buck. When the innovative value of the runtimes are questioned, I am sure MIDP product managers are having hard time to justify the resources to put MIDP on the phones. The main reason that MIDP is keeping afloat is its huge install base but it is only a matter of time where other runtimes such as WebKit makes this irrelevant.
I believe the root of the problem is mobile Java vendor(s) have no alternate business model to the license fees. They have been trying to prevent a free Java to appear on Mobile phones just to be able to keep the licensing fees. The open source license choice of Sun’s open Java is partly due to that. Do you recall Apache’s open letter to Sun? The main reason for Sun putting “field of use” restrictions on JCK is another effort to prevent a free and open source Java to appear on mobile phones. Sadly, this is in expense of mobile Java and for a business model that can not be sustained for a long time.
So what are the possibilities for the future of Java on mobile?
The obvious scenario is it will cease to exist in mobile space by time with the exception of Android. Motorola lately announced that it reduces the software platforms that it uses and will start using Android as one of its preferred platforms. This is significant for two reasons because Motorola is still one of the major phone manufacturers and it is the specification lead for the MIDP3 JSR in JCP. MIDP3 is under specification work for almost 4 years now and I guess we will be waiting for it some more. Although the features and innovation of the MIDP3 is not significant anymore but the delays of its arrival is an indication.
Android is a confusing player in the mobile space. Officially it is not Java. It uses the Java language and Sun appears to like it (I can’t really figure out why), at least Android was the main mobile demo platform in the last JavaOne. Android blend of Java is designed as an integral part of the mobile platform rather than a runtime on top of it. This makes it powerful but makes it hard to port to other mobile platforms. This actually brings us to the next scenario.
Android Java becomes so favored that OSS projects start for porting Android to other operating systems such as Symbian, Windows Mobile etc. This is a big effort, I am not even sure if it is feasible. I am sure that it requires the collaboration of at least Nokia, and Google. Also the port must be done in parallel to avoid fragmentation. So it is a low possibility for the time being.
And my last scenario of the day is another open source implementation. Let’s assume for a moment that the mobile manufacturers and the mobile Java platform providers have realized that they are in a crash course. They decide that instead of trying to implement the same old proprietary MIDP in house, they can collaborate for a MIDP implementation that everyone can also use commercially. They can then start to spare some of their resources from implementing proprietary to adding innovative features and adopting new directions to mobile Java. The biggest obstacle with this scenario is companies are not really good at creating new business models and unfortunately such a change requires new business models for Java vendors, phone manufacturers, mobile network operators and even internet service companies.
This is all the scenarios I have for the day. Like them, dislike it, have a better one ? Comments are open, fire away.
Oct 20, 2008
Oct 6, 2008
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.
Oct 1, 2008
On another note, the conference organizers have been kind to sent the below postcard image for promoting the conference. I think they are better than the usual banners.
Sep 18, 2008
I was chatting with a friend the other day about code reviews. His team was starting to adopt the code review practice and he had some questions on the practicalities. We have been practicing code reviews successfully within the Nokia's eSWT team for the last 3 years. I have tried to answer his questions as much as I can and at least my feeling was they were helpful for him. Perhaps our experience can be helpful to others.
The mechanics of our code reviews is simple. We conduct team wide code review meetings for all the major new feature development. The definition of major feature differs on every software project but it is basically a single task that is large enough to require the eye balls of the whole team. Team usually reaches a definition “major feature” of its own by time. Team code review starts about a week before the actual review meeting. Every team member spends some time to review the code and we collect the comments on a wiki page. At the meeting the owner of the code goes over the comments and explains the interesting parts of the code. One may think that the meeting is a bit redundant since the code is already reviewed beforehand and the comments are collected. However, that is not the case because the review meeting is about anything but review. It acts as a platform for discussing the coding related issues (the algorithms, duplicate functionality, style, tools, utilities etc… ). The meeting also represents an approval of the developed code by the team and marks the beginning of collective ownership of the reviewed code. In a sense, we dance the Haka, and accept the new code.
Anything that is smaller than a “major feature” gets peer reviewed. We do not use any tools to assist peer reviews. I am a bit amazed that some actually rely on tools to make a team to adopt code reviews. In my experience, tools do not help with the willingness to adopt a new practice, but this does not mean that they are not helpful once you have the practice in place. The only tool we are using for the peer reviews is the code repository itself and its mechanics is explained below.
The mastery of the code reviews depends on the human factors rather than technical. I guess it is common for teams to quit doing code reviews after giving it a try for once or twice. I remember the very first code review meeting we have had as well. First, we started to talk about the smallest bit of formatting errors. Although it is nice to have a unified format for the code discussing every bit of it on a review meeting is a waste that steals the time from the real problems. Also after a while. the owner of the reviewed code started to take it personal and started to argue with reviewers. At the end, it was a waste. When I was leaving the room I thought “is it worth to have code reviews in the expense of the team”. However, we were persistent on keeping the code reviews so we had come up with following principles to improve the practice a bit. Some of these, like the individual pre-meeting reviews, were put into practice right after the initial disaster, some we have added along the way.
- Do individual reviews and report your findings on the code before the review meeting.
- Only team members are allowed to comment at the meetings.(Chicken and Pig)
- Do not discuss the small formatting problems in the meetings.
- On peer reviews add reviewer to the commit comments, after all reviewer is as much responsible for that commit as well.
- Review comments are not personal, reviewers review the code not the person and comment about the code not the person.
- No developer is spared from code reviews.
This code review practice is developed by time, and will continue to evolve. It is not a silver bullet practice and you need to make up your own if you are serious about it.
Sep 10, 2008
I have been working to create an eSWT widget gallery that would feature the screenshots of eSWT widgets. I wanted the screenshots to be taken from a phone so I have used the S60 implementation to take my screenshots (and S60 was easier for me). Enjoy the pictures.
And a S60 implementation related note, there had been questions about compilation instructions for the S60 implementation for S60, the compilation instructions is now available on the wiki. You can use these instructions to get the latest and greatest eSWT. Binary downloads for S60 will be available in a short future as well, so stay tuned.
Aug 24, 2008
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.
Aug 16, 2008
The code for eSWT implementation for S60 is available in Eclipse’s CVS repository now. Nokia’s eSWT team had been ready to push the code for about a year now. Unfortunately, team had to wait the release of the S60 FP2 SDK which would enable Eclipse community to further develop eSWT for S60. The contributed code is the same code that is shipped by the announced S60 based Nokia and Samsung phones. However, CVS repository also includes some additional bug fixes.
Speaking of bugs, the way to report bugs for the S60 eSWT implementation is through the Eclipse bugzilla. Nokia eSWT team will also be handling the eSWT bugs (that are not directly related to unannounced devices) this way, so Eclipse bugzilla is the place to report eSWT problems on your phone.
Unfortunately, binary downloads for the S60 eSWT is not yet available due to legal and administrative reasons. The binaries for updating eSWT on the phones requires us to sign them. Actually, it may be possible to do the signing with Nokia’s certificate since Nokia is an active contributor and the distributed binaries will be targeting Nokia phones. We are now trying to agree on a good way of doing the signing that will be acceptable by both Nokia and Eclipse. In the mean time, we have the possibility to provide binaries to update the eSWT that is available on S60 FP2 SDK. If you think that the SDK update would be useful even without the phone binaries, let me or the eRCP developer mailing list know about it.
Aug 14, 2008
Jul 29, 2008
Jul 24, 2008
Recently announced Symbian Foundation’s choice of the open source license is Eclipse Public License (EPL). This choice is already a great plus on EPL’s account. Pretty soon, there will be an open source mobile OS licensed under EPL provided by a foundation other than Eclipse foundation. This late announcement actually made me think, does Eclipse fulfill its potential by limiting its technology scope?
For many, Eclipse is “still” all about IDE. Although, a big part of what exists in Eclipse is development tools related, the technology scope is not only development tools. Besides the tools, Eclipse also provides runtimes and frameworks, so the scope is as wide as a development platform such as .Net. The limitation in Eclipse’s technology scope is all its technologies run on Equinox OSGi. Although, I have not seen any Eclipse rule that states that all projects must support Equinox, there must be an unwritten community rule. Do not be mistaken, I like working with Equinox and I think it is the best runtime container to work with today. However, being cool and useful does not change the fact that not everything (operating system components, virtual machines etc..) can be based on Equinox.
After all the secret sauce of the Eclipse foundation is not a particular technology but its ecosystem. As the Symbian Foundation announcement indicates, Eclipse ecosystem has the potential to attract a more industries and technologies but this can happen only if the Eclipse community is ready to accept them. Is Eclipse community willing to accept operating system components, virtual machines, alternate runtime containers, embedded technologies…?
Jun 24, 2008
Jun 4, 2008
If you are reading my blog through its RSS feed, it is possible that you did not notice the "facelift" I have done for my blog. I am actually very happy about the end result, It looks pretty good for yet another Blogger blog. As part of the facelift, I was looking for a good and easy way to publish my blog to the mobile phones. As I am blogging frequently on things that are mobile, it was becoming embarrassing.
After considering several options, I found the solution not far away. I have started to publish my blog on Widsets. WidSets is a mobile java application that gets installed to your phone. It acts as an "on device portal" for mini-applications that WidSets calls widgets. It basically uses RSS to push the information to the phone using the widgets.
I was able to create a widget for my blog in a few minutes using the wizard on the WidSets web site. I now have a button for WidSets based subscription in my blog. Surprisingly, my widget was more discoverable than I have imagined, and I already have some mobile readers.
Using WidSets, there is also the possibility to make more advanced stuff than just displaying RSS feeds. There is a Widsets SDK, that can be downloaded to develop widgets using a java like scripting language called helium.
I have recently met with the WidSets team at the Eclipse party in JavaOne. I guess this is amusing because WidSets is a Nokia service and the team is located in Finland (as I am). They are fun people. I got convinced that I should provide a more advanced widget for my blog. We also talked a bit about how cool it would be to create a bunch of Eclipse plugins for WidSets widget development.
May 6, 2008
The final release of the JSR for Java ME Connected Device Configuration (CDC ) version 1.1 was 3 years ago. The early draft of the specification is almost 5 years old. The situation is indifferent with the smaller and more common Connected Limited Device Configuration (CLDC) version 1.1. CDLC specification is also about 5 years old. In the past 5 years the development of the Java did not stop. Java SE had two major releases Java SE 5 and Java SE 6, and these releases brought major changes to the java language. Today, the java language level of the Java ME remains at 1.4 level as defined by CDC and CLDC specifications.
In the meantime. the mobile handset industry has been changing constantly. The devices nowadays have more resources. Devices like N95 have 330 MHz or larger CPUs, 3D accelerators, a good amount of memory, and this was last year. iPhone had made a very positive impact in the industry and convinced the consumers that smartphones are more than phones. On the other hand, the rapid growth of the developer community around the Google's Android proven that the developers welcome an innovation platform that is closer to Java SE level, rich with APIs on the devices.
I believe mobile industry had never been more ready for having CDC as the mainstream Java ME configuration. The richer APIs of CDC will allow the innovation juices of the mobile java developers flow rapidly. The ability to use JNI will enable software that is more integrated to the the device features without need for the platform providers to provide the APIs. This is all sounds good and desired but lately I started to wonder is that enough?
The latest discussions on e4 made it more clear that there is a desire on the developers to use Java 5 features. This is not really news, there had been similar discussions on different Eclipse components concerning their use with eRCP, including the latest experience from Wayne Beaton. While with the current state of Java ME, it is a necessity for the components to keep the java language level at 1.4 level. I think it is really time to start with a new version of the CDC to move the the language level to Java SE 5 level and be prepared for the inevitable.
Of course, it is some work and investment to do a new CDC specification and therefore the possibility to define a subset of the latest Java SE and calling it the new mobile java remains attractive to many.
Apr 27, 2008
This year I will be co-presenting a session at JavaOne. The session is about the use of java UI technologies on touch enabled devices. We will also talk about eSWT's touch enabled use as part of the session.
I have already registered myself on the Eclipse's JavaOne party. I have also reserved my time so that I will be at the Nokia booth at the Pavillion on Tuesday afternoon, during the Pavillion Welcome Reception. If you would like to see some eSWT demo on phones or just want to chat drop by the booth.
Apr 9, 2008
Mar 17, 2008
Although RCP, eRCP and RAP provide a step in the right direction they miss a true model for portability among these runtimes. Of course the commonality of APIs and the OSGi component model in these runtimes enables us to port applications among them easily but it is not currently possible to use an application on all of them without the porting effort. My first expactation from the top level runtime project is it can bring these projects close enough so that a common application model, especially for those with a ui, exists among them.
Speaking of the UI, SWT is the UI toolkit for eclipse runtimes. I think this may be a good time to move SWT to the runtimes project. I think such a move can strengthen the collaboration among different SWT flavors(eSWT, RWT) and mark SWT to be a runtime aspect of the eclipse rather than the IDE.
Mar 11, 2008
Feb 29, 2008
- Monday has the eRCP development tutorial, Developing applications using embedded Rich Client Platform (eRCP) a good starting place for your eRCP based development.
- Tuesday morning sees a very interesting talk. eRCP commiter Ken Walker discusses How eRCP stacks up against Android and other Mobile Rich Client Platforms
- Wednesday reveals the details on the lately announced Sprint Titan platform with Announcing the Sprint Next Generation Java Platform
- Thursday has the final word, a short update on the status of eRCP Project, today and tomorrow
Feb 18, 2008
I have posted about the first two devices that ship with eSWT. A colleague had pointed that there is already a total of 4 devices with eSWT support. Announced at the same time with N78 and N96, 6210 Navigator and 6220 classic do have eSWT loaded as well.
Obviously, I am not good at following the new device launches and it is imminent that there will be a lot of those in the near future. So I decided to teach how to fish instead of doing a bad job of providing. Forum Nokia provides product pages, such as this one for N78. These pages provide more relevant information for developers including a list of java APIs available on the device. The search application, that is also reachable from these pages, allows searching on the available java APIs on all Nokia devices.
Now you can see for yourself the devices that you can deploy your killer applications.
Feb 11, 2008
Today Nokia has announced two new phones. Although Nokia announcing new devices may not sound special but these devices are. N78 and N96 are the first phones that will include eSWT pre-installed on the device. This is the first of many devices that will be based on S60 with eSWT. Judging from the last year, there will be millions of Eclipse technology installed devices, before you can say eSWT.
Feb 10, 2008
If you are interested on how to develop applications for the eRCP (or next generation mobile java as some call it) we will have a tutorial at EclipseCon 2008, see you all at EclipseCon.
Jan 18, 2008
eRCP, along with Eclipse Modeling Project, has been chosen to be a finalist for the Jolt awards. Jolts are considered to be the Oscars of the software industry, so this is as close a software project can get to red carpet treatment.
Congratulations to the eRCP community on the well deserved finalists position and best of luck to both eRCP and Eclipse Modeling Project for the awards.
Jan 17, 2008
Jan 14, 2008
The public review for the JSR 271, (Mobile Information Device Profile 3 or MIDP 3 ) has started. Those familiar with the JCP process will tell you, this is an important milestone for a JSR. Also those into mobile java will tell that it has been a long waited milestone.
Why do I think this the last MIDP specification? It is definitely not because it solves all the shortcomings of the current MIDP environment for good. I think, we are in an era where java ME innovation on the JCP will be quite limited, this will make alternates the main provider for new technology. There are several reasons that lead me to this conclusion.
One major reason is, there are rising alternates to MIDP, to name some eRCP and the Google Android. One common theme for the newcomers is they are not designed by a committee and they are open source, therefore the innovation on them is rapid and open to anyone.
The costs associated with the licensing, certification of JCP related technologies is a big factor. Handset manufacturers pay substantial amounts of money for java and TCK licenses. This is an additional cost to developing/acquiring of the actual software. The open source nature of the alternates is attractive for the handset manufacturers because not only licensing and TCK costs but also the development costs are lowered.
MIDP is a highly controlled java environment, you work with what you have on the device and that is it. It is not possible to add new capabilities to the environment. As the mobile device business slides more to a software and services business those environments with such possibilities will start to attract more developers on the expense of MIDP.
Does all that mean MIDP is dead today? On the contrary, for the next few years MIDP will remain the most profitable java platform for developers to build on. The amount of existing and the coming mobile devices with built-in MIDP support are enormous and certainly not within the reach of any other alternate.