Tuesday, August 29, 2006

GUI toolkit for Java ME/ CDC devices

During 2007 there will come more devices supporting Java ME/CDC1.1
My question is, what will new devices support, eSWT or/and AGUI?
(IBM:s j9 will of course support eSWT, but AGUI?)

Sun and Netbeans will only support AGUI because eSWT is not a JCP standard or?
But if there will not be so many devices supporting AGUI (today only SavaJe phones support AGUI).
Nokia have talked about it for a long time that they will support next generation Java platform with eSWT
Remember Nokia is the biggest Mobile phone company!!
I also wondering what SonyEricsson and Motorola will support in the future , eSWT or AGUI?
I know SavaJe support AGUI (I bought a phone at last JavaOne).

I think we will have devices during 2007 supporting Java ME/CDC1.1/Personal Basis Profile 1.1 profile with eSWT and other devices supporting Java ME/CDC1.1/Personal Profile 1.1 with AGUI (like the SavaJe phone).But of course I would like companies (with eSWT support) like Nokia to support also Java ME/CDC1.1/Personal Profile 1.1 with AGUI.

I am a little worried about if there will be a success for Java ME/CDC1.1 platform.
So far with Java ME/CDC1.0 there have not been so many devices to buy on the market.
I hope this will change with Java ME/CDC1.1!

JSR-249 does not include any GUI functions other than what’s in MIDP. I think that if it doesn't include a GUI (that is suitable for the hi-end device the JSR is targeted for) the whole JSR will miss its purpose. Personal Profile or at least Personal Basis Profile should be the obvious choice.
What do you think?

Friday, August 25, 2006

ERCP - Embedded Rich Client Platform, soon with the first release of eRCP

I read in the mailing list for the ERCP project, they is close to the very first release of the eRCP, release 1.0 it is planned to be released 9/6-2006.

It is very interesting; the intent of ERCP project is to extend the Eclipse Rich Client Platform (RCP) to embedded devices. eRCP is largely a set of components which are subsets of RCP components. It basically enables the same application model used on desktop machines to be used on devices.

Why do I think it interesting?

eRCP have some interesting components:
Core Runtime - the Eclipse Core which provides OSGI and Extension Point Framework support.
eSWT - The embedded Standard Widget Toolkit which is a subset of desktop SWT API.
SWT Mobile Extensions - a set of widgets and dialogs which are mobile device specific
eUpdate - a simplified API and interface for dynamically updating device software

I like Java standards, but what is this, is it Java standards?
No, not all of the componets!
OSGI is not new to Java ME or to the JCP, because we already have JSR 232 [Mobile Operational Management].

eSWT is not a standard, but Nokia have talked about for a long time that they will support next generation Java platform with eSWT. Nokia think the performance will increase for GUI mobile application. I have also read in newsgroups some developers think it is easier to develop good GUI application using C++ instead of Java for the symbian platform, I don’t know if is correct but with eSWT it will change.

I think we will have to new GUI toolkit eSWT and AGUI, we (developers) need to support them both.

But I am positive because I would like to have success for Java ME/CDC platform at least! I don’t think Java ME/CDC1.0/PP1.0 have been a success so far, not so many good devices have we seen.

I think we have devices during 2007 supporting Java ME/CDC1.1/Personal Basis Profile 1.1 profile with eSWT and other devices supporting Java ME/CDC1.1/Personal Profile 1.1 with AGUI (like the SavaJe phone).
But of course I would like companies (with eSWT support) like Nokia to support also Java ME/CDC1.1/Personal Profile 1.1 with AGUI.

Friday, August 18, 2006

Start developing eSWT applications for mobile phones

There are some different UI toolkits for the J2ME/CDC platform. Except Java ME/CDC’s old UI toolkit AWT, we also have AGUI (JSR-209) which is a subset of Swing for CDC. Both are standardized through the jcp process.

But Nokia talk about eSWT instead of AGUI, but eSWT is not a JCP standard.
I have playing around with eSWT for a while.
There is a good document about developing embedded apps with eSWT

1) I started with download a trial of IBM Workplace Client Technology Micro Edition 5.7
It packages the following portfolio of products:
- WebSphere Everyplace Micro Environment
- WebSphere Studio Device Developer
- WebSphere Everyplace Custom Environment
- IBM Service Management Framework

At the download page I downloaded the follow three files:
Workplace Client Technology, Micro Edition for Windows (containing all component products and tools)
- Read me (WCTMEReadme.html (50KB))
- Installation Guide (WCTMEInstall.html (20KB) )
- Workplace Client Technology, Micro Edition 5.7.1 for Windows (windows_cd.zip (611MB))

2) After downloaded all files I started the installation and choose to install “IBM WebSphere Studio Device Developer 5.7.1”.

3) Then I also need to install “eSWT (BETA) for Extension Services”
Start WSDD and in the menu select select .
Select update site: IBM Micro Environment Toolkit for WebSphere Studio
I installed this:
- SMF Bundle Development Kit
- Extension Services
- eSWT (BETA) for Extension Services
- JSR 169 (BETA) for Extension Services (add JDBC support)

4) A example application and howto configure WSDD I found in this document How to Develop eSWT Apps on WSDD 5.7.1, you also need to download the file: eSWT-WSDD-M3.zip for that document.

Today there no phone supporting eSWT, perhaps in the beginning of 2007 we will se the first phone (but I don’t know; only Nokia know).

I wondering what SonyEricsson and Motorola will support in the future , eSWT or AGUI?
I know SavaJe support AGUI (I bought a phone at last JavaOne).

For us developer it look like we have to learn both eSWT and AGUI!

update:
New article Explore Eclipse's embedded Rich Client Platform

Thursday, August 17, 2006

We need to do projects better!

I read James Gosling’s interesting blog about boiling oceans.

James says:
“my favorite principles of engineering that is all-too-often forgotten:
A journey of a thousand miles begins with a single step.
At Sun we use the term "boiling oceans" to refer to trying to do something impossibly hard all at once”

“Engineering projects too often fall into the trap of over-generalizing, trying to solve problems that folks might conceivably have, building things so large and elaborate on day 1 that they never get off the ground. It is always better to start with a first step. Then a second. And on...”

I really agree about this!
I think it is really funny how often this happen, new project start up and have to big scope. It is like people/companies newer learn the lesson and we end up with crashed projects and a lot of money spend.

I think every company need some easy rules, like:
1) Newer have a project that is longer than 6 month
2) Shit in --> shit out (we starting often develop to early), have look on this picture, I like it!
3) Some people/comany think: If we using RUP or Agile, then it is impossible to make mistakes.
4) But it is people’s competence/experience in a project that makes the success”.
I don’t think everyone in a project have to be an expert, we need beginners also but not only beginners.

Wednesday, August 16, 2006

Sun is open-sourcing Java ME, but what will be the benefit?

In the keynote at last JavaOne, Sun CEO Jonathan Schwartz and Senior Vice President Rich Green.Schwartz told us “the question is not whether Sun will open-source Java at this time, but how it will do it”.

I thought at that time it will take years before Java will be Open Source, but it was wrong!

Now I read things like Sun is open-sourcing Java ME, More info available here.

Open Source Java they have spoke about for years now.
But what will be the benefit? I don’t now?

>Sun Microsystems plans to open source its implementation of the Java ME specification
What will the benefit for me as a developer?
Perhaps it means better Java support on more devices like the Palm and PocketPC platform?

What do you think will be the benefit with open-sourcing Java ME?

Friday, August 11, 2006

JSR-232 and MSA Advanced (JSR-249)

JSR-232 (Mobile Operational Management) has now reach status proposed final draft.
"The specification is about creating a predictable management environment for mobile devices capable of installing, executing, profiling, updating, and removing Java and associated native components in the J2ME Connected Device Configuration."

If you read the interesting interview with MSA spec lead Asko Komsi, who is also Nokia's Director of Industry Relations, he talks about the future of mobile Java, you understand how important JSR-232 is for JSR-249 [Mobile Service Architecture Advanced].

In that interview you could read:
1) JSR 248 does not provide all the features enterprises need, mainly because JSR 248 defines a very static environment
2) JSR 249 is about a dynamic environment. With JSR 249, you can dynamically download new APIs to the handset. What APIs are available on the handset is no longer tied to that handset or even to what the MSA initiative can provide you with JSR 248. I think that [dynamic environment] is really what enterprises, and even consumer applications, will need in the future
3) From Nokia's perspective, we think that OSGI already offers us a lot of what we need, and it would provide an excellent framework for the dynamic environment we envision in JSR 249.
4) OSGI is not new to Java ME or to the JCP, because we already have JSR 232 [Mobile Operational Management], with Nokia and Motorola as the spec leads. From MSA's perspective, if we wanted to use OSGI, all we'd have to do would be to deploy JSR 232.
5) We anticipate that JSR 249 will exist in a draft version by the end of this year.

Tuesday, August 08, 2006

The Future of Mobile Java

I read an interesting interview with MSA spec lead Asko Komsi, who is also Nokia's Director of Industry Relations. In this interview Asko talks about the future of mobile Java, and how the MSA standard will help make it easier to develop for mobile handsets.