In order to take control of the native back button, we can link it to a DOM back button with a listener registered on. In this way once we intercepted the “click” event on the native back button, we can run the handlers registered on the DOM back button for the “click” event.

First of all, we need a function providing the list of handlers registered to a DOM element, something like the EventListenerList interface introduced in DOM level 3 and disappeared in the last draft of DOM level 3 Events Specification.

So, let’s define this function by using  jQuery:

Now, we need to intercept the “click” event on the native back button. The “hashchange” jQuery special event does the job: if a location.hash exists, whenever the browser back button is clicked the location.hash changes.

Done. Now Android users can navigate backward on your Mobile Web App by using Android UX.

We could make the code above simpler by using the HTML5 State Management Functionality in this way:

Unfortunately this code doesn’t work yet on mobile browsers (tested on Android 2.2 and iPhone OS 4.3) but support for HTML5 features is being added extremely quickly to most browsers, so I would not surprised to see this working in few months.

Leandrò Agrò, speaker at Better Software, convinced me to attend Frontiers of Interaction – the crossroads of innovation in Italy. What interests me most is that this conference is not specifically about software. “It’s not about software at all!”, you might say. Well, what’s not about software? I found out I’m much more interested to what is related to software than software itself. I mean interaction design of course, user experience, business, but also pollution, cyber punk, italian design, parallel computing …

See you there!

My goal for this article is to show how to create the main structure of a MVC-based Javascript Application using pure Javascript in defining classes, and the jQuery library to access and manipulate the DOM.

Model
Let’s start with the implementation of a Model object. ListModel is a very simple class that implements a list of items, in which items can be added and deleted.

View
The View implements an action form which is included inside the finditems HTML div, consisting of an input text field and a button to apply the form. The init method bind the apply button to the method findItemsController’s apply method, for the click event. The show method cleans the screen and makes the view visible, the hide method makes the view not visible, and the getInputValue method returns the value that has been inserted in the input text field.

Controller
The FindItemsView class is tightly bound with the FindItemsControllerclass, which handles the input event from the user interface via direct calls, registered handlers or callbacks. In our example FindItemsController’s apply method is called when the apply button is pressed (this event has been register in the init method of the FindItemsView class), gets the value of the input field from the View, then performs an asyncronous call to a service: the response handler is FindItemsController itself, and three callback methods (success, error and timeout) are passed. If nothing goes wrong, the success callback is called and a new ListModel object is created and initialized with retrieved items. At this point the control is given to the ListItemsController, that has the responsibility to display the ListModel on a different View.

Alright! This is the starting point to write a MVC-based Javascript Application using pure Javascript and jQuery library. Alex Netkachov in this article shows how to write a simple MVC-based JavaScript component with the support of the Dojo language utilities. Also want to point out this interesting video about JavascriptMVC: using a framework or a toolkit is rarely a bad idea.

Well, since in this period I am extensively developing Mobile Widgets (i.e. Javascript Application), I’m going to come back on the subject soon, showing how to implement widely used design patterns, such as Observer, Facade, Singleton and Factory.

Stay tuned !

I come from mobile web site and application development for mobile handsets, and mobile widgets are rather a new thing for me despite I had to deal with Nokia Web Runtime some months ago. At first glance mobile widgets seem to incorporate all advantages associated on both classic mobile applications and browser “applications” (i.e. mobile web sites):

• Web technology
• Low learning curve
• Portability
• Easy to Layout
• Offine content store
• One Package

However JIL Widget SDK is actually far from perfect: lack of features (to be implemented), device heterogeneity and limitations, different Web RunTimes to be handled. Fortunately the JIL project, currently in Beta, consists of a skilled team of developers and a large community, so I’m sure platform stability will be improved, missing features will be implemented and new features will be added.

Ruby on Rails is a Full-Stack Web Framework I started working with in 2007.

Convention over configuration through naming conventions, Ruby on Rails reduces the repetitive writing of configuration tasks. Less code means less potential for bugs.

This is the feature that made me fall in love with this framework, and that, incidently, makes hard to find a full featured IDE specific for Ruby on Rails.

Here we compare TextMate + RailsBundles with Aptana RadRails to choose the best Ruby on Rails IDE for Mac OS X. I’m sorry I couldn’t take NetBeans IDE into account, because unfortunately my good old iBook PPC is simply too slow for it.

Performance

Textmate is by far the faster one, there’s no comparison at all. Everything you do with Textmate doesn’t take more than 1-2 seconds to complete, whereas Aptana Studio takes half a minute sometimes.

Plugins and configurability

In TextMate Bundles are Plugins. Textmate is highly configurable just if you know how (and have time) to work from command line and edit or create bundles by youself, otherwise you just have to understand how commands, macros and snippets provided by RailsBundles work.

On the other hand Aptana RadRails is based on Eclipse, that means it’s a full featured IDE with a world of plugins to support Subversion and Git for instance, and is easily configurable via graphic interface. Unfortunately it inherits from Eclipse itself, and especially from plugins, configuration limitations and bugs.

Auto-complete

TextMate has no auto-complete, and no documentation about Rails: this is a big lack especially if you are new to Ruby on Rails and you don’t know much about existing classes, functions and keywords. I started programming in Ruby on Rails using TextMate and without knowing how bundles work, it was just like using a text editor such as VIM: I used to continuously switch among TextMate, the console for Rake and scripts, and Firefox for documentation. The beauty of auto-complete is that it helps you learn your classes, the libraries you’re using (if any) and the framework you’re working on. After all, TextMate is the missing editor for Mac OS X: it doesn’t aim to be an IDE.

Lack of auto-complete in TextMate has been the main reason that made me switch to Aptana, even if it doesn’t perform very good: sometimes takes more than 5 seconds to show up the list of entries, and up to 5 seconds to make the entry documentation appear.

Rake/Mongrel/Browser integration

RailsBundles allows TextMate to perform some rake tasks, such as migrations, without switching to Darwin. That’s that, unless you want to write your bundles, obviously…

On the other hand, Aptana RadRails provides a nice interface in which you can run scripts, rake tasks and control all your servers: logs are tailed inside the IDE so you can take the outcome under control. Moreover a browser is integrated inside the IDE so that you never need to switch to Firefox or Safari. That’s what an IDE should offer.

Price

TextMate costs about 50€.
AptanaStudio is free.

Have a look at RadRails on Aptana.tv .

Here we are again dealing with the Abstract Wizard Form Controller, a form controller for typical wizard-style workflows, provided by Spring, a Java Web Application Framework. This time we discuss a more frequent problem: skipping steps.

For istance, let’s consider the situation in which you are at page n of your wizard and submitting a form for target n+1. What if, for some reason, you need to skip the step n+1 and go forward one step?

The first attempt to face this problem might consists in conditionally changing the target value inside the form included in the jsp page corresponding to the view for page n. For example we might switch between passing the request parameter _target3 or _target4 by using the JSTL Core TagLib. This works, but we are putting a conditional control inside a View, that is a very bad practice in a MVC-based framework like Spring.

Let’s move the conditional control into our wizard controller, and to be more precise into the getTargetPage method:

This solution is clean and makes your application more readable, your code more reusable and so on…

But what if the step we want to jump to is the final step? We cannot reach it by using the getTargetPage method because the final step has no page number assigned: the finish action is triggered by the request parameter _finish and the view name is retrieved by the ModelAndView object that the processFinish method returns.

To solve this problem we can modify the view name for target n+1 at runtime by overriding the getViewName method as following:

In this way we simply redirect the flow to the final step. Obviously, at finish all pages get validated to guarantee a consistent state, so you cannot skip a step whose page needs validation.

In contrast to classic forms, wizards have more than one form view page. Therefore, there are various actions instead of one single submit action:

• finish: trying to leave the wizard successfully, i.e. performing its final action, and thus needing a valid state;
• cancel: leaving the wizard without performing its final action, and thus without regard to the validity of its current state;
• page change: showing another wizard page, e.g. the next or previous one, with regard to “dirty back” and “dirty forward”.

In this article I want to focus on pages, how to set them up, expecially in the uncommon situation in which you don’t know exactly the number of pages you want to put in your wizard before running the application.

Every Spring manual would suggest you to put WizardFormController’s pages in the Spring XML configuration file, and actually this is the best way to set up your pages. Let’s consider the following configuration:

We have put a property named pages inside myWizard.html bean, in which we listed the page values. Each value is used as the name of the view inside your jsp folder.

And now the wizard form, you can set it up for your needs.

Finally the wizard controller.

What if, for some reasons, you need to create or edit your wizard page list at runtime? Let’s face the problem.

First of all, you can override the XML configuration through the setPages method. The following example replaces the page list specified in the XML file with an identical one but that has been built at run-time in MyWizardFormController constructor.

This doesn’t help much: we moved the configuration outside XML (that’s a bad thing) but we still have a fixed number of pages with fixed values.

Let’s consider an application in which the page values are the request parameter keys for the first step (i.e. _target0). We might call setPages inside an overridden method used before the wizard controller accesses to page list, such as the getInitialPage method.

In this way, as soon as myWizard.html bean is invoked by clicking on a link (i.e. GET http request) or submitting a form (i.e. POST http request), the page list is dinamically built starting from request parameter keys. This would be more useful if you decide to use request parameters values, or attributes.

For my purposes I used request parameter keys retrieved from a form submission in order to run an unordered set of pages and reporting each result (i.e. validation) in the final step.

Its name is Ovi Store, has been announced at the Mobile World Congress 2009 (Barcelona) in February, and on May 26 it went live for all Nokia users in the world. More than 50 Nokia devices were compatible with the service from day one and Nokia estimated that around 50 million people with Nokia devices would be able to benefit for Ovi Store. Initial number of applications was 20.000 and new applications creation is propelled by an high percentage of money going to developers. Moreover the Nokia N97 will be the first to come out with Ovi Store pre-installed.

The Global Intelligence Alliance Group conducted an interesting analysis on  mobile market places. Different market places have been compared in terms of:

1. time to market
2. the ability to attract developers
3. the rate of device adoption
4. an efficient interface and user experience
5. having a critical mass of attractive applications.

to get the following rankings table:

Source: Global Intelligence Alliance. Points are allocated as follows: 2 – strong, 1 – medium, 0 – weak based on assessment/expectations of all application stores along the parameters.

It’s interesting to note that Nokia’s rank is two points lower than iPhone Apps Store’s, but equal to Android Marketplace’s. Further information in the Global Intelligence Alliance’s article.

What distinguish Nokia Ovi Store from the other marketplaces is the device and application heterogeneity Nokia had to manage and offers. Despite iPhone Apps Store, that is clearly made for one phone, Nokia Ovi Store covers more than 50 Nokia devices, Series 40 and Series 60 included, and because of this for each mobile application the Ovi Store needs to indicate the device compatibility. Moreover, even if every application you can find inside the Ovi Store behaves and looks like it has been developed using the same technology, the same programming language, it doesn’t ! In fact, a Nokia application you download from Ovi Store might be:

1. A Nokia Symbian Mobile Application
2. A Java Application (MIDlet)
3. A Nokia WRT Widget

This might be seen as an advantage for the developer because she/he has the chance to choose the technology which likes more or which better fits to application features or customer requirements. And maybe it is, we’ll see what happens in the next few months.

It was a very interesting seminar due to the fact that software architecture was still something vague for me (i.e. a computer engineering student much interested in software engineering but who has never handle with projects big enough to need a significant effort in making the architecture).

In his seminar, first of all Kruchten tried to give a definition of Software Architecture coming to the following conclusion:

Software architecture encompasses the significant decisions about:

• the organization of a software system,
• the selection of the structural elements and their interfaces by which the system is composed together with their behaviour as specified in the collaboration among those elements,
• the composition of these elements into progressively larger subsystems,
• the architectural syle that guides this organization, these elements and their interfaces, their collaborations, and their composition.

Software architecture is not only concerned with structure and behaviour, but also with usage, functionality, performance, resilience, reuse, comprehensibility, economic and technological constraints and tradeoffs, and aesthetics.

Although this definition of Software Architecture seems to be comprehensive, surely it is not so easy to understand at the first reading. A simpler definition could be the following:

Architecture is about making decision.

Then Kruchten focused on what architects actually do.

The life of a software architect is a long (and sometimes painful) succession of suboptimal decisions made partly in the dark.

Architects should spend their working time in the following manner:

• 50% Architecting (design, validation, prototyping, documenting, etc.)
• 25% Getting input (from user requirement, other architecture, technology)
• 25% Providing Information (communicating architecture, assisting other stakeholders).

The right balance among these activities is very important in order to not fall in typical situations in which architects don’t know anything about existing technology, or don’t communicate their work to designers.

It’s clear that decision is the key word for Software Architecture, therefore Decision Models, Decision Visualizations and Design Decision Capture Mechanisms are the key tools for architects. Refining models, languages and mechanisms concerning decisions is the purpose of Software Engineering Research in this area.

«If you ever admired those colleagues who stayed in office for more than 10 hours day by day, you should consider the fact that after a specific amount of work time bug rates increase dramatically and work results tend to reach lowest levels. Thus, working too hard for a long period of time could even have a negative effect.» Michael Stal