Today we rolled out a new version of the Vaadin Directory. This update is mostly about fulfilling a common feature request we have heard from the community, downloading add-ons via Maven repository. We have setup our own Maven repository for Vaadin Add-ons and already deployed existing add-ons there with the exception of some add-ons that wouldn't make sense to use via Maven (tools etc). All future add-ons (and new versions of existing add-ons) will automatically be also available via the Maven repository.

How to use this new feature? It's simple, in the Directory we now have a Maven POM button right under the download button for each add-on that is available via Maven. By clicking this button you will be shown all the needed information (<repository> and <dependency>) for you to copy-paste into the pom.xml file of your Maven project. More defailed instructions here.

We would be happy to hear any feedback from you about this new feature. There might still be some rough edges and together we can smooth them out. Please post your comments, bug reports, ideas or any other feedback into this forum thread or use the feedback link on the Directory menu.

One of my first assignments as a fresh employee of IT Mill was to investigate how well Vaadin integrates with the new GlassFish 3 application server. The last time I had used the "official JEE" was back in the 1.4 days, resulting in me becoming somewhat of a Spring fanatic. However, I had read that JEE 5 had improved considerably and approached my assignment with careful optimism.

I had previously done a lot of development on Eclipse Rich Client Platform and really liked the modular thinking that was enforced by the underlying OSGi platform. Therefore, when I found out that GlassFish supported OSGi, I immediately became excited.

I started small by turning the Vaadin JAR into an OSGi bundle and deployed it on the GlassFish server. After that, I created a Vaadin application that could be deployed as a web application bundle (WAB). The result of this experiment was an article that can be found here.

With the basic building blocks in place, I moved on to create a simple modular Vaadin application inspired by Eclipse RCP. The user interface was running as an ordinary JEE web application, but it could be dynamically extended by installing OSGi bundles into GlassFish. The application is described in an article that can be found here. I have not yet created any "real-world" applications using this approach, but I have some ideas for a pet project that will utilize OSGi. If the ideas ever turn into code, I will let you know.

In addition to OSGi, I also checked out the new annotation-based way of configuring JEE applications and injecting dependencies. While figuring out how to utilize it with Vaadin, I came up with two different approaches that resulted in yet another article found here. Quickly after I had posted the article, I received a third (better) approach from a community member and included it in the article as well.

Finally, I investigated how the security features of GlassFish can be used to secure Vaadin applications. Although I still think Spring Security is more fine grained when it comes to security, the standard GlassFish/JEE 6 security features are sufficient for most applications. Custom security features, such as auditing or ACLs, can easily be implemented using interceptors to avoid cluttering the business logic with security code. My article on Vaadin and JEE6 security can be found here.

Overall, discovering GlassFish 3 has been a pleasant experience and I am going to continue on this path, as there is still a lot to discover. Thanks to the modular design of GlassFish 3, JEE has become a lightweight, non-intrusive framework for developing both small and large enterprise applications. Although Spring and Tomcat will still play an important role in my Vaadin toolbox, they are now accompanied by JEE6 and GlassFish 3 as well.

This is the first post in a series of three posts on Vaadin TouchKit and mobile web application development. In this first post, I’ll give a bit of background about how I got involved with developing Vaadin TouchKit and discuss some thoughts I’ve had during the development phase. The following posts will then discuss future plans that we have for TouchKit, and mobile web application development in general.

I joined the Vaadin team fairly recently, last January. I had just finished my Master’s thesis and graduated a month earlier when I got offered a job at IT Mill. 

Every new employee at IT Mill has a chance to familiarize themselves with Vaadin and other development tools while doing a small introductory project. As I had just majored in embedded systems design, I had a big interest in developing for mobile devices. I suggested that I’d take a look at how Vaadin works on mobile devices for my project. We decided that my project would be to develop a toolkit that would make creating mobile applications with Vaadin simpler. The focus of the project was on supporting modern, touch screen devices and try to deliver a user experience that feels like a native application. Quite early on in the development, we decided that the project would be expanded from a simple introductory project to an actual product. This brought in a few more people into the project to help me out. 

There are several things that we as developers have to be more aware of when developing web applications for mobile devices than when developing for desktop clients. First, the amount of screen real-estate limits the use of many components that are commonly used in designing web applications. Second, the amount of processing power and memory is very limited when compared to desktop computers. Combined with the fact that most wireless communication technologies are much slower than the internet connections people use at home, the mobile web application needs to be as small and computationally lightweight as possible. Finally, as we are working with touch screen devices, it’s very important to make sure that all user interface elements are large enough and spaced sufficiently far apart to keep the interface finger-friendly.

Before starting to develop TouchKit, I went through all the existing components in Vaadin to get a sense of which components were working well in mobile browsers and which needed more work. To my relief, most of the components that didn’t work well in mobile browsers were components that didn’t fit the experience of mobile computing. The remaining components worked fairly well, although some of them needed some additional CSS styling to make them more suitable for touch screen use. 

When I began developing Vaadin TouchKit, I tried to make sure to keep the client side as lightweight as possible. I did this by storing only one view at a time on the device, while the server takes care of navigation and history. This way, only the bare minimum of components are loaded in the limited memory on the device at any given time.

TouchKit 1.0 aims to produce good looking and intuitive web applications for  most mobile web browsers. More advanced browsers like those on the iPhone and iPad take advantage of CSS animations to add some extra user feedback, but the basic user experience is the same for all users. 

Taking a high-level look at what TouchKit comprises, you can see that there are two main components that are used to create the feel of native applications: a panel and a menu. The panel wraps the content and takes care of the header caption and back buttons. The panel is also responsible for handling animations for browsers that support them. 

The menu component, in turn, is used to create navigation menus that work like menus on the iPhone. Both the panel and menu take advantage of WebKit events for detecting touches to deliver feedback of taps to users.

As a developer, you can use just about any existing Vaadin components inside TouchKit to build your application, just remember to make sure that the user interfaces you create are easy to access with a finger. 

The following post in this series will continue from where we left of, taking a look at the future of TouchKit and what you can look forward to in TouchKit 2.0.