This website uses cookies for visitor traffic analysis. By using the website, you agree with storing the cookies on your computer.More information

Our nice JavaFX mobile applications

Our (research) projects with JavaFX are almost finished. We have awesome results and everything is production ready. The only drop of bitterness is the performance of JavaFX on desktops and mobile devices, but this can be improved by Oracle. It's not in our hands.

What do we have?

We have

  • a complete JavaFX UI for JVx
  • a custom application frame for mobile applications
  • Live CSS manipulation of installed apps (needs debug build)
  • Complete Project export for JavaFX mobile projects (JavaFXPorts based gradle project),
    integrated in upcoming VisionX 2.3
  • Remote Work-screen loading (via VisionX)
  • JVx server runs without limitations on mobile devices
  • JVx client runs on mobile devices (for network clients)

How does it look like?

I have some screenshots from two applications. The first one is a standalone JVx application. The whole JVx framework runs on the mobile device. The app is a remote control for our eTV project (it's a brand new side project of our research team).

The app was inspired by MS Metro style ... Windows8 style ... Modern ... Universal ... Windows Store ... Windows apps.

The main screen has some buttons to control our eTV and some buttons open a "popup" with additional options:

eTV Dashboard

eTV Dashboard

eTV Window view

eTV Window view

eTV Gallery

eTV Gallery

The second app will be shown as Video, because we want to demonstrate how we use VisionX to create backoffice apps in under 5 minutes! The app itself isn't complex and does "nothing special", but the same mechanism works for complex applications like our Demo ERP system (read our Code once. Run anywhere post).

Our JavaFX mobile project was based on the great work of Gluon and their JavaFXPorts OpenSource project and also on RoboVM.

JavaFX mobile LIVE CSS hacking

(The video lasts 05:19 but it should be 07:30 because the build process takes 02:50. We shortened the build process because it's boring to wait.)

The future of JavaFX?

After one year of JavaFX development, we thought it's time to write about our experience.

We started in Nov. 2014 with our first bigger JavaFX tests. The idea was an UI implementation for JVx. We thought it should be an easy task because JavaFX is a desktop technology. We had another research project in 2012, but the result wasn't as expected. Sometimes it's a good idea to re-start from scratch!

JavaFX wasn't very popular and is still not a Superstar, but we love researching and we thought it might be a good idea to bet on JavaFX. Not only as pure desktop solution and Swing replacement, but also for mobile app development based on JavaFXPorts and for embedded devices, like Raspberry Pi. So we had this big picture in mind.
We thought it would be awesome to create a single JavaFX application, for all platforms and devices. Sure, some other companies tried to solve this problem as well, but we didn't try to do the same. Our idea was simple and based on JVx. We hade this awesome JVx application framework which enabled GUI and technology independent application development. So we tried to solve the GUI problem because all other things like persistence, remote communcation, i18n, ... were already solved by JVx.

We did different GUI implementations for JVx, before we started with JavaFX. Our first one was based on Swing, followed by QTJambi, GWT, GXT, a headless variant and - last but not least - vaadin. We also made some tests with Flex and Pivot, but we didn't create more than some simple PoC. To be clear: GUI technology know-how was not the problem!

We knew that JavaFX didn't have a solution for MDI and especially a DesktopPane was missing, but it wasn't a problem to create custom components/controls. We had some hard months of development because we found out that JavaFX wasn't a mature toolkit like Swing. We had to find many workarounds for very simple problems and had to create more custom components than expected. We solved most problems in our own code, but it wasn't possible to change some basic problems. We tried to get in contact with the developers, via JIRA, but it was hard to explain real-world use-cases to toolkit developers. Our developers at SIB Visions create custom products and projects together with customers for their needs. So we had many UI toolkit requirements from real users. Some issues were accepted but not all. Many bugs were fixed but we had big problems with Feature Requests. So far so good.

We finished our JavaFX UI implementation in April 2015 and it was a big success, because we had a fresh UI technology with lots new features and animations, transitions, web and media views, .... awesome.

We thought that JavaFX will be improved in 2015/2016 and it will be mature enough to use it for our customers.

Wait... what's the problem with JavaFX?

Performance, Memory, limited chances to modify standard controls

The performance is not good, if you have many controls (= nodes). It's different on Windows, Linux, MacOS. It's much better on MacOS than on any other supported OS. If you develop business/backoffice applications, the performance is very important. Sure, if you create simple form based applications, it doesn't really matter.

We use JVx to develop huge backoffice applications and currently, JavaFX should be used with care.

What do we mean with "performance is not good"?

  • Large TableViews have scroll delays
  • Layouting sometimes need some "extra repaints"
  • Scrolling with many controls is not immediate
  • Startup time of an application is too long, compared to e.g. Swing applications

The version number of JavaFX 8 is too high for it's maturity.

JavaFX has big potential but we're not sure if it'll survive it's predecessor Swing.

And we're not alone with our opinion: Should Oracle Spring clean JavaFX

But there are also companies with JavaFX applications: JavaFX Real-world apps

There's more

The toolkit issues are one thing. Another big surprise was that Oracle stopped official ARM support in Jan 2015 which didn't mean that JavaFX doesn't run on ARM devices (RaspberryPi, ...), but it's not officially supported and Oracle doesn't fix bugs or implement improvements.
Thanks to Gluon it's still very easy to use JavaFX on ARM devices.

Another step backwards was the migration to Bugzilla. In 2014 (and earlier), JavaFX was a "newcomer" and announced as Swing replacement. The development process at Oracle was very open and you had a "direct connection" to the development team, or something like that. It was very simple to report issues and to get feedback from the developers. It was fantastic to see and feel the progress. This is different nowadays, because the ticketing system moved from JIRA to Bugzilla and it's more or less readonly for standard developers.

One problem with JavaFX is that Oracle doesn't tell us the strategy behind JavaFX. The investment of Oracle in JavaFX was high, but what will be the next step? It's hard to bet on JavaFX without definitive commitment from Oracle.

But we still hope that JavaFX will be the one and only UI toolkit for Java.

JavaFX for Android and iOS

In summer, we moved forward and tried to use JavaFXPorts. It makes it possible to use your JavaFX application as native Android and iOS apps. Our JavaFX UI worked with some smaller changes out-of-the-box. It was awesome to see our JVx on Android or iOS devices! It was a milestone.

But things have changed since summer because JavaFXPorts has a depency on RoboVM. It was an OpenSource project and was a big win for the community. But now it's a commercial tool (read more). This has no impact for us, but means that we can't offer an out-of-the-box OpenSource solution.

JavaFXPorts also works without RoboVM and there are plans for a JVM running on mobile devices, but this won't solve the problem that you need access to device features/APIs. But we'll see what happens in the next few months.

We had some fun in the last few weeks because we tuned our application frame for mobile devices. A mobile application has some specific characteristics and isn't a 1:1 desktop application. A desktop application usually has a menubar and a toolbar. The same app on a mobile device shouldn't use a menubar or toolbar. It should offer a hamburger button which offers a custom menu. Also the style of the controls should be different on mobile devices, e.g. Tabsets.

There are two interesting projects which offer custom mobile controls. The first is a commercial product, from Gluon and the second one is JFoenix and it's OpenSource (LGPL). We took JFoenix because it met our requirements and JVx is OpenSource.

We have some screenshots in older posts:


JavaFX has potential to rule the Java UI world, but it needs an official commitment/statement from Oracle. Now it's unclear if JavaFX is the right UI technology for the future.

We hope that JavaFX is the right toolkit, but we aren't sure. Our investment was risky and high, but no risk - no fun. The results are awesome!

Thanks to JVx the UI technology is not important for us, because if JavaFX won't make the race, we still have Swing or vaadin. It's important to be UI technology independent because it saves time and money and is future save.

Vaadin Panel background image

Our current Vaadin UI got a new feature. It's now possible to set a background image for a Panel.

This feature was already defined in JVx' IPanel but our vaadin UI didn't support it out-of-the-box.

We already had a custom Panel and it was an easy task to add missing functionality. Sorry, we don't have an extension for this feature, but it shouldn't be a problem to create an extension based on our implementation.

Our solution

As mentioned, we had a custom panel implementation. Its a simple extension of CssPanel with an implementation of SingleComponentContainer. The class can be found here.

The important part in our implementation is that we have a custom State and Connector for our Panel. The state got additional properties for the background, like repeat-x, repeat-y or the size. The image itself is a Resource and we re-used the existing transport mechanism for image resources. The mechanism is available in AbstractClientConnector. The nice thing with this standard mechanism is that the client has a method to build the correct image URL, automatically.

Our implementation:

public void setBackgroundImage(Resource pResource)
    setResource("background-image", pResource);
    SimplePanelState state = getState();

    if (pResource != null)
        state.backgroundRepeatX = "no-repeat";
        state.backgroundRepeatY = "no-repeat";
        state.backgroundRepeatX = null;
        state.backgroundRepeatY = null;

The most important thing was the connector on client side which reads the State and sets the background image via css. The full class is available here.

The following code snippet shows how we set the background image. It's not really tricky

public void onStateChanged(StateChangeEvent stateChangeEvent)

    String sURI = getResourceUrl("background-image");

    if (sURI != null)
        Style style = getWidget().getElement().getStyle();
        style.setBackgroundImage("url(" + sURI + ")");
        SimplePanelState state = getState();
        if (state.backgroundSize != null)
            style.setProperty("background-size", state.backgroundSize);
        if (state.backgroundRepeatX != null)
            style.setProperty("background-repeat-x", state.backgroundRepeatX);

        if (state.backgroundRepeatY != null)
            style.setProperty("background-repeat-y", state.backgroundRepeatY);
        Style style = getWidget().getElement().getStyle();

The method getResourceUrl is an existing method and returns the full image URL. It was easier to re-use this method than creating the URL manually.

We made a simple test in our showcase application and the result was as expected:

Background image

Background image

The image was set with following code:


SIB Visions at DOAG

JavaFX mobile

JavaFX mobile

Today is the last conference day and we had our second talk.
The title was: Mobile applications with JavaFX

We described how a JavaFX desktop application could run on a mobile device without any changes but with mobile user experience.

Thanks to JavaFXPorts it was very easy to realize this use-case.

If you have time and want to talk about JavaFX, JVx or VisionX visit our booth and push our buzzers.

SIB Visions @ DOAG

SIB Visions @ DOAG

The talk about MS Office as Report designer was on Tuesday:

Reporting design with MS Office

Reporting design with MS Office

We showed how we use MS Office to create Report templates and fill the templates with data. It's super easy for an end-user to create a custom report becasue MS Office is well known and easy to use.

We use this template mechanism for our customers and it's a super easy and fast solution.

Lets create a comples Report in minutes without additional coding effort. Simply use MS Office and layout your Report. The fill-in mechanism just uses your template.

DOAG 2015 - Two talks

DOAG 2015 will be in Nuremberg this year. The conference starts at November 17 and ends at Nov 20.
This year, we have two talks. The first one will be about mobile application development with JavaFX and the second talk will be about MS Office as Report Designer. Both will be in German!

We have a big surprise for all attendees. It's a .... :)
Okay, it's not really funny without details, but it's a surprise!

For all those, who don't want to wait

We'll demonstrate the power of JVx and VisionX with a super cool showcase. Visit our booth and have fun!
Here's a screenshot of a new JavaFX mobile application. This application is one element in our showcase....

eTV portrait

eTV portrait

eTV landscape

eTV landscape

Above application is a simple JVx (standalone) application. This means that JVx server runs in the same application.

Don't miss the opportunity to learn more about our showcase and to listen to our talks.