We (the Symbian Foundation) proposed a new project – Tools for Mobile Web. We offer our code as a basis for this new Eclipse project and now that we released version 1.0 of our product we would like to focus on this contribution. I would like to better explain what we would like to see out of this project. We did several presentations already so there are some common questions we had to answer.

What is “mobile web”?

In the scope of this project “mobile web” means “mobile web runtimes” that are present on most modern popular smartphones. Developers can use web technologies (HTML, CSS and JavaScript) to create mobile applications. These applications are quite different from the regular web pages in that they are not served from a web site but are installed on the device not unlike regular “native” mobile applications. They can be distributed through the OVI store or other platform-dependent application stores. These application have a broader access to device capabilities – they can access GPS and accelerometer sensor readings, use device-specific UI (i.e. software buttons on Symbian phones), read address book or be notified when SMS or MMS message was received.

Device simulator

But there is Web Tools Project already!

TWM does not mean to reimplement WTP functionality. We build on top of the WTP reusing all the powerful tools in provides (like JSDT). We focus on adding functionality that is specific to mobile development – like deployment to phone or mobile API simulation.

Will you add support for JQuery UI (or <your other favorite JS library>)?

Our focus is on adding mobile development-specific functionality. We do not plan to implement functionality that users consider “missing” from the WTP. On the other hand we hope to cooperate with WTP and possibly contribute to such areas. Once the WTP gets support for the library then TMW will “inherit” it.

We are watching closely JavaScript frameworks that are more specific to mobile application development. We already added support for PhoneGap framework and we may add support for other frameworks as they mature and gain popularity.

Is there any timeframe on when the tools will be available?

You can already download Tools that support Symbian WRT development. They are feature complete and EPL licensed so we encourage you to try them whether you are a JavaScript developer looking to expand to mobile platforms or an Eclipse enthusiast interested in IDEs for mobile. Currently we are focused on refactoring our code to add support for any number of the runtimes and to prepare it for migration to eclipse.org. From that point we will continue development of both Symbian-specific and runtime-agnostic parts.

What about support for other platforms?

We have implemented support for PhoneGap APIs but we only package applications for Symbian platform. Aplix already stepped up to contribute support for BONDI runtime. We expect other interested parties to contribute support for other platforms.

What can the IDE do?

It is a fully integrated IDE that supports application development cycle from creating a new application project to deployment on the device or packaging for distribution.

Main screen

Our editing experience is based on WTP were we extended JSDT with the support for mobile libraries and added CSS validator and application manifest validator.

Another important part is the simulator and debugger that are built into our IDE. It can be used as a live preview of your application or as a runtime for debugging. Our primary goal was to reduce overhead of the mobile application development so we chose to use desktop browser (Chrome) to ensure maximum debugger performance. We understand that this approach is not completely accurate but it had proven to be “good enough” for debugging of the vast majority of the tasks. We plan on adding on-device debugging in one of the next releases.

How do I start using this IDE?

Follow this link for up-to-date information on using our IDE. Do not hesitate to contact us on our forums or submit bugs to bugtracker.

How is this IDE related to other solutions for WRT development (i.e. Nokia plug-in for Aptana, Dreamweaver)?

Our code owes to a large degree to Nokia code contribution. Our initial goal was to achieve feature-parity with Aptana-based solution. We added several important features including PhoneGap support and acceleration events simulation that were not available in the original code.

The first questions developers ask about out new Mobile Web IDE is “why do we need another solution?” This question is really justified provided there are already several established alternatives in all shapes and sizes.

Our answer is that we wanted to have a completely open-sourced tools – and that leads to another question. “Why should we (as users) care?” Now that open-source is not that much of a buzz-word it used to be most users don’t really care if they can see the source code – they are more concerned with usability and ROI. This is what we hope to achieve with our project:

1. Single all-in-one download for every platform. All you need to install our IDE is to download ZIP file for your platform and to unzip it anywhere on your filesystem.
2. Use latest-and-greatest upstream projects available from the community. We use JSDT for JavaScript editing, Chrome Java SDK for debugging, W3C CSS validator for validation.
3. Use our codebase for an effort to provide a reference IDE for mobile web development. We want to contribute our project to serve as a basis for Eclipse project that will foster development of similar IDEs for different runtimes. Currently all major mobile platforms provide a way to create and deploy applications using web technologies. Until this point there was a separate IDE for each platform and we hope our project will encourage cooperation and ultimately result in better tools and consistent user experience.

We have a lot of plans that should justify having “yet another” Mobile Web IDE even more:

1. Support other mobile APIs. Currently we are working on out-of-box PhoneGap support but we will also consider other APIs and runtimes.
2. Improve preview and simulation. We are working on support for more sensors and mobile APIs.
3. Streamline UI.

So we encourage you to give the IDE a try. You can post your comments and suggestions to our forum. We would be grateful for any bug reports posted to our bugtracker.

I was unable to find any documentation on how to use Jetty as an OSGi HTTP service. We needed it as a part of our WRT tools effort to host a code that would serve as a runtime environment (sort of “emulator”) for the user code. I guess there are many other scenarios that could make use of the embedded server.

Basically, everything you need to know can be found in org.eclipse.wst.ws.internal.explorer.WebappManager class that is part of the WebTools project. The code is very simple:

Dictionary d = new Hashtable();
d.put("http.port", new Integer(getPortParameter())); //$NON-NLS-1$
// set the base URL
d.put("context.path", "/wse"); //$NON-NLS-1$ //$NON-NLS-2$
d.put("other.info", "org.eclipse.wst.ws.explorer"); //$NON-NLS-1$ //$NON-NLS-2$

// suppress Jetty INFO/DEBUG messages to stderr
Logger.getLogger("org.mortbay").setLevel(Level.WARNING); //$NON-NLS-1$

JettyConfigurator.startServer(webappName, d);
checkBundle();

In our code we do not specify the context path (so we have root as a context path) and specify a different ID so both our code and Web Services tools could coexist.

What is really important is that the server will run in Eclipse process and deployed servlets can have access to Eclipse APIs so you can interact with the workbench as you need – i.e. you can have all the settings stored in the preference store and configurable from the preference page, access the workspace and interact with your IDE (i.e. in our case it is possible to do AJAX call to disconnect JavaScript debugger).

There are two ways to register servlets:

1. Programmatic (using OSGi APIs)
2. Declarative (using org.eclipse.equinox.http.registry.servlets extension point)

In our application we use programmatic way so we don’t have to rely on singletons to integrate them with our IDE.

Here at Symbian Foundation we believe that one of the best way to attract users to a mobile platform is to have more/better applications. The best way to have more/better applications is to attract more developers. And one of the best ways to attract more developers is to provide better tools. And one of the best ways to provide better IDE is to build on top of Eclipse.

And that is exactly what we are aiming to do.

We took (in no particular order):

1. Contributions from our member company (Nokia)
2. Eclipse Platform from Eclipse Foundation
3. JavaScript Developer Tools from Eclipse Foundation
4. JS debugger from Google Chrome Developer Tools

and glued them together to produce a new IDE that will make web development experience for Symbian platform much more pleasant.

This is what you can do with our IDE:

1. Create a new WRT (Web Runtime) application project from one of the predefined templates or using existing packaged WRT application (WGZ file) as a template.
2. Edit HTML, JS and other files. This featureset is coming from WTP and JSDT in particular. We added validation for project metadata files and CSS files.
3. Debug the application. Chrome browser is used as a runtime and Chrome Developer Tools are used for debugger UI.
4. Package your application for distribution or deploy it directly to a device.

You can find the builds for different platforms on our downloads site. We plan to release the first version on March 31st.

Everybody is invited to:

• Visit the project page to obtain the sources. Use “Eclipse for JEE Developers” bundle with installed XULRunner as a target platform. Target platform can also be downloaded here (single downloads for all platforms).
• Try the IDE (there is a quickstart document)
• Comment on our forums or mailing list.
• Submit bugs to our bugtracker (like if there are any…).
• Participate in the project.

At this point this project is very much focused on Symbian platform and WRT in particular. But we are planning to expand the scope – both to encompass increasing scope of web support in Symbian platform (cWRT is one example) and to supporting more libraries and runtimes that are not platform-specific.

I hope to share some development experience in this blog so feel free to ask any questions on implementation.

I would really like to thank developers from Eclipse.org project and Google Chrome Developer Tools for making available all the great frameworks and tools.

I see a lot of discussion in the blogs on how to invite new developers to participate. They all are talking about people being reluctant to do development, making the eclipse.org site interface more inviting – but really, is this the biggest problem? I wonder, does anybody think obscure location of the CVS URL would really stop anybody from trying to enhance the favorite framework?

Consider this (the ones that I remember):

Bug 287887 – I haven’t seen response like “why would anybody want this” or else. The patch was submitted 3 months ago.

Bug 155479 – several commercial projects would like to see it. Patch was submitted in April.

Bug 166906 – pretty irritating bug. The patch was submitted four years ago.

Note – these are patches to make Eclipse better from the end-user POV. It’s not the patches to make Eclipse frameworks more open for extension so we can build better products on top of it – I’m pretty sure that most commercial developers know that there is next to no chance to get such change into Eclipse.org.

The result is quite simple. I joined a new company recently and from the start I say – do not expect the Eclipse.org to cooperate. We need to consider a way to branch projects we use – before we reach the point it is not possible to deliver proper product to our customers because the framework was not designed to support something.

I believe there should be a strict policy in Eclipse.org for handling patches – i.e. the projects should commit to responding for the patch in 2 weeks or one month – and either describe what’s wrong or to incorporate the patch into main repository. Otherwise there will be many Eclipses – Git makes it really simple.

And I’m not mentioning this: 262846 – pure enhancement to make simple API for the popular feature. I submitted this one in February – and I missed some Eclipse.org deadline. The result? Even in the best-case scenario I won’t be able to use this in my commercial product till Summer 2010 – 1.5 years. That’s if we don’t consider that the chances of this bug being committed are still slim. So why bother? 1.5 years is a long time.

I wonder if I’m the only one who can’t remember fancy names for Eclipse releases – Europa, Ganymede, Galileo, Helios. I think it’s not really good that there’s no easy way to memorize them (I wonder if they were meant to be in alphabetical order – if not for “Ganymede” and “Galileo”). Eclipse releases annually – so why doesn’t it has name like “Eclipse 2007″?

So:

WTP is a huge codebase with a lot of ready solutions for the problems that many Eclipse plug-in developers face. Unfortunately to me it looks like these solutions are not picked up as the people consider WTP only to concern with web site authoring. I would like to list some frameworks I believe are useful in all areas where Eclipse is adopted:

1. Faceted Project Framework

(Link to tutorial)

Essentialy Facets are project natures – only on steroids. Project natures can easily be added to a project and you can test if the project has specific nature – but the facets framework provides so much more:

1. Well defined facet lifecycle. Facet can be added, removed, upgraded you can define interdependence between facets. All done using clean API.

2. UI. You don’t need to implement your own menu action cramming the toolbars and confusing the user. You can contribute wizard pages that users will be able to invoke either when creating new project or when editing project properties. Sure, it is still possible to create custom action, wizard, etc.

As far as I understood this framework will be a basis for a projects framework in E4. I believe that will really streamline Eclipse user experience in many ways.

2. Structured Source Editing Framework

(Link to subproject page)

Extremely great source editors for XML, XSL, JSP, HTML, CSS, XSD – and other files. The editor has rich navigation & editing features JDT user would expect and is also extremely extensible. If you need to create an editor for XML-based file type you can pick the SSE XML editor and start customizing in small increments – outline view, content assistant, auto edit strategies, formatting, validation, hyperlinks. SSE editors can be embedded into multipage editors. Model management facilities can be used outside of the editor itself (i.e. from some toolbar action) and will help avoid conflicts when user did some change to the file that is already opened in the editor.

It is also possible to use custom parser to create editor for non-XML files.

I believe that SSE is long overdue in core Eclipse platform – PDE editor and ANT script would really benefit from reacher source editing capabilities (i.e. formatting).

3. Validation Framework

(Extension point description)

This framework provides a clean and easy way to add build-time validation to workspace resources. This way project will have only one validation builder attached to it and it is easy to change the set of validators between product versions. The framework will handle dull tasks like markers management (i.e. there’s no need to remove the markers after the user fixed the problem) and properly call the validator on manual or auto build. There is also UI to manage validators on workspace and project levels.

org.eclipse.swt.custom.CCombo are evil and should never be used as components on dialogs and editors!

They look deceptively “fine” on Windows:

But on MacOS X (I would expect same on on GTK) they look completely wrong:

It is not always possible to test on other OSes – so I believe avoiding this component is a good way to make the UI look better on other OSes.

Consider following two images:

Here you can see what I consider as a major UI antipattern – Cancel button has two distinct roles. In the first case it works as a close button on the window title bar – if the user clicks it, the wizard dialog will close and the user input will be lost. In the bottom case the Cancel button is a “Cancel task” button – the task will be stopped but the dialog will be retained. This is pretty confusing for the users as they are not sure if they loose input in later case. I suggest we introduce a new button that will explicitly stop the task but has nothing to do with wizard dialog:

This way Cancel button always mimics Close Window button – i.e. it is grayed out when the wizard dialog cannot be closed. I filed this enhancement suggestion (along with a patch) as bug 287887 in Eclipse.org bugtracker.

Several times I needed to implement wizards that have variable flow (i.e. user input on one page defines if next page is shown and what next page(s) will be). At first I felt it is complex and pretty counter-intuitive to implement the behavior – but the problem was that I didn’t quite understand the Wizard logic.

Usually JFace wizard is a one instance of org.eclipse.jface.wizard.IWizard with one or more org.eclipse.jface.wizard.IWizardPage pages. My mistake was that I assumed that both Wizard and Pages are “Views” in MCV terms – so I was confused on how to create the logic. But actually Wizard is a controller and Pages are views. What this means is that:

1. Wizard instance is responsible for “directing” wizard flow.
2. Wizard instance bridges between “model” and “pages” – i.e. it initializes pages from model, interprets information from pages.
3. Pages are responsible for information presentation, user entry interpretation, validation, etc.
4. Wizard depends both on model and views (pages), views are self-contained.

To create wizard with non-lineal flow I do the following:

In addPages method I add all the pages – independent on wether they are always shown or not:

public void addPages() {
    firstWizardPage = new FirstWizardPage();
    addPage(firstWizardPage);
    optionalWizardPage = new OptionalWizardPage();
    addPage(optionalWizardPage);
    lastWizardPage = new LastWizardPage();
    addPage(lastWizardPage);
}

Thus all pages will be properly initialized by Wizard, all controls will be created and the wizard dialog size will be set to the biggest of the pages so no clipping will occur.
Then I override getNextPage and getPreviousPage in the Wizard. Depending on user input (or model state) wizard decides what pages should be shown next. In my example first wizard page is simply a page with single checkbox – so I added “isChecked” method that returns the checkbox state:

@Override
public IWizardPage getNextPage(IWizardPage page) {
    if (page == firstWizardPage) {
        if (firstWizardPage.isChecked()) {
            return optionalWizardPage;
        } else {
            return lastWizardPage;
        }
    }
    return super.getNextPage(page);
}

@Override
public IWizardPage getPreviousPage(IWizardPage page) {
    if (page == lastWizardPage) {
        if (firstWizardPage.isChecked()) {
            return optionalWizardPage;
        } else {
            return lastWizardPage;
        }
    }
    return super.getPreviousPage(page);
}

In more complex scenarios I use these methods to refresh the model with user entry and propagate the changes to other pages (i.e., if user entry on one page changes the contents of the list on another.

When user input needs the wizard to refresh the workflow I add a call to getContainer().updateButtons() – i.e. in my example I added this to checkbox selection listener. This will call getNextPage, getPreviousPage and some other wizard methods in wizard-independent mode.