It's about two years ago that I wrote about controlling window shutters. The system run for 2 years without problems but it was time to change "something" because it was vacation time and I thought it would be useful to showcase our vaadin UI

The old system was controled via (good old) SMS - without GUI. It had a lot of commands but only en/disable up/down were heavily used because the integrated public holiday and weekend automatism solved most use cases. The SMS contol was great and worked without problems but it was a problem if you didn't know the commands and syntax by heart!

Another consideration was a simple real-world showcase for our vaadin UI, the responsive feature and push support. Our application frame was already responsive and worked on desktop, tablet and smartphone browsers. I thought about using AngularJS or different "hypeware" but I didn't have weeks to research and implement. My new GUI had to be finished in few hours. And it should be maintainable for the next two (or more) years without problems.

I love researching hypeware... but simply read some articles if you want:

• 10 Amazing Libraries for Your Web-based JavaScript Applications
• 7 Exceptional JavaScript Frameworks for Mobile App Developers
• Generation Javascript

There are too many frameworks, everyone is different - no real standard APIs (didn't count HTML and CSS). You can't be sure that the framework is future-proof because developers love to change software to be incompatible with previous versions just to be state-of-the-art.
And why should a developer use 5 or more frameworks to create a simple application for desktop and mobile? You'll need more libs if your application needs DB and CRUD support.
C'mon we need simple and small frameworks and not what we have right now! The world is talking about microservices and what about "micro frameworks"?

Conclusio: I didn't find something comparable to JVx. Of course, it's my opinion and I'm JVx developer, but I'm a researcher and the technology isn't a problem if it makes sense to use it.

To be honest: Our Vaadin UI in combination with other JVx features is unbeatable for most application types. Of course, it's not recommended for web pages with custom layout requirements. If you need an "application style" solution with menu and screen/work area or form based - there's nothing comparable.

After I knew that my new GUI would be a JVx' vaadin solution, I had to think about the details. The whole application should be responsive to support every modern device and desktop browsers as well. The application server should be Jetty or Tomcat and it should run on the RasPi. The performance is not critical because the hardware is limited (but cheap).

Software stack: clear
Hardware: clear
Deployment type: clear

Next step was development. This was easy because I re-used existing classes and added some get/set methods to access internal members. The most important change was an event listener because every vaadin client should be updated immediate via push. It wasn't possible without notification mechanism. I thought about an event bus and played around with mbassador. It's a nice and small lib, fast and just works (recommendable).
To be honest: I didn't need it because I didn't need more than one listener and an event bus is not much more than a listener abstraction (with some extras).

After some hours developing and refactoring, everything was ready for a test.... The next decission: Jetty or Tomcat?
I worked with Tomcat for many years and didn't know much about Jetty, only that it's the number one for embedding into applications, supports SPDY and has websocket support. I played around with Jetty and got it running. The installation of my GUI worked like a charme and everything worked except push. I found solutions for embedded run mode but not for standalone Jetty. I'm pretty sure that I missed something, but I wasn't very patient and switched to Tomcat 8.
Not only because of my push problem but Jetty didn't handle requests as expected:

http://localhost/house/ didn't redirect to http://localhost/house/index.html automatically. I didn't have an index.html file in the public file area, anyway the request should be executed. Such requests work with Tomcat without additional configuration.

I'm not happy that my Jetty server didn't work but I'll retry it in the next days

Here's a simple screencast of my solution because it's easier to understand:

It took me less than one day to finish my GUI and the best: It's family safe.
I tried the GUI with PS4 and WiiU integrated browser and it was great to see shutters moving.

Summary

I've used a RaspberryPi, installed Tomcat 8 with Java8 and deployed my application as war file. The GUI is responsive and supports push via websockets and runs on every device in my house. It wasn't planned using gaming consoles

Oh, I forgot to mention: During my tests I found out that Android and iOS support custom Bookmark images for Desktop links but this needs additional tags in index.html (works without, but it's better to include the tags). Our VaadinUI now has built-in support for such images

The switch component is available in the Vaadin Directory.

We fully support Vaadin' push support with current JVx *nightly* builds (see JVx with vaadin UI and server-side push). We had some problems with manual push mode because of some strange implementations of atmosphere in vaadin. We found a better solution to be independent of vaadin changes (should work with 7.1.8 and later).

No we automatically push if you use standard threads or threads, created via VaadinFactory. It's also possible to use JVx' callback mechanism for push operations. If you won't use threads in your client application, simply make an async server call. The server implementation automatically starts a new thread and executes the task. The server will notify the client after the task is finished. This is a little bit strange because client and server run on the application server, if you use our vaadin UI. If your JVx client retrieves the result of an async call, it will automatically push the results to the vaadin client. This makes the whole application very smart and live.

It's very easy to work with async calls in JVx. Simply use a callback listener:

The server method in Session LCO:

We didn't change JVx' APIs to support vaadin push. It works behind the scenes and we simply love it.

Use our nightly builds to see how it works.

Vaadin supports "push" - since 7.1 - but JVx doesn't have an API for that. It's technology dependent and we usually not need it on client-side of an application. It would be useful for the server-side of JVx applications, but that's a different thing. I want to write about server-side push for UI changes.

If you use threads in your application, to update the UI, it's not a problem if you use a desktop technology like Swing UI. The UI is always up-to-date. If you use vaadin UI, it's not the case, because vaadin UI runs on an application server (= server machine) and vaadin client runs in your browser as Javascript code (= client machine). The thread runs on the server machine and doesn't update the client machine automatically. The client retrieves all changes with next client request. This is sometimes too late. With server-side push it's possible to update the client machine immediate, if you use pure vaadin.

With our next vaadin UI release, it's also possible to use server-side push of vaadin to update the client machine. It's very easy to use and also is technology independent, but we didn't introduce new APIs

How it works?

Create a new thread, through your factory and use invokeLater to update the UI. You always should use invokeLater to update the UI (no difference if you use swing or other desktop technologies).

If push is enabled, above code pushes the UI changes immediate to the client machines. To enable server-side push, simply add following to your servlet configuration in web.xml:

It's also possible to use vaadin push without JVx' mechanism (pure vaadin). To see how this works, read following issue: Server-side refresh.