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

Category: News

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.

Presents for the community

We got awesome mail!

Our community T-shirts are in-da-house!

JVx, original green

JVx, original green

JVx, white

JVx, white

VisionX

VisionX

The text is on the front and logos are on the back. Simple and Smart as JVx and our Source Code.

The first chance to get a shirt will be in Hamburg, November 3rd. We'll present JVx at the Java User Group.

Code once. Run anywhere.

It's some time since my last post about JVx. But I have a good excuse - Coding :)

I tried to improve our JavaFX UI for mobile devices. It was a hard fight but I won. Not everything is done right now, but the result is soo awesome!

Many of you know that JVx is an Application Framework. It's small and simple but still very powerful. It follows the convention over configuration principle and it was designed to be UI technology independent. Oh, it follows the Single sourcing principle too, it's a Full-Stack-Framework, contains a very smart persistence implementation, and so on.

What means UI technology independent?

We define the term as follows:

Code an application once and use it on different platforms and with different devices and different technologies.

As platform, we recommend Windows, Linux or MacOS. Devices are Desktop PCs/Notebooks, Smartphones, Tablets or embedded Hardware like RaspberryPi. We use the term technology for UI toolkits/standards like HTML5, Java Swing or JavaFX.

JVx isn't a JavaScript framework or library because it supports every platform with maximum power. This means that a desktop application runs as standalone application on your desktop computer with full access to connected hardware. A HTML5 application runs in a web browser and has limited access to the device but you have full css features and websockets. If your application runs on mobile devices, simply use all available hardware features and gesture support.

All the platform/device/technology specific problems were solved in JVx and a developer simply has a standard API to create applications. If the standard API isn't enough, it's easily possible to access the technology features without limitations. JVx encapsulates but doesn't hide anything.

With JVx you can code desktop applications, browser based HTML5 applications or native mobile applications without know-how of every platform/device/hardware.

I guess it's time for facts and some screenshots should clarify what I mean.

Desktop Swing UI

Desktop Swing UI

Desktop JavaFX UI

Desktop JavaFX UI

vaadinUI corporate

vaadinUI corporate

vaadinUI simple

vaadinUI simple

vaadinUI legacy

vaadinUI Legacy

mobile fxUI

mobile fxUI

mobile fxUI menu

mobile fxUI menu

mobile fxUI legacy

mobile fxUI legacy

All screenshots show the same application (same source code) with different UI technologies and on different devices. We have UI implementations for vaadin, JavaFX, Swing. We have different application styles because the application shouldn't look like a desktop application, on mobile devices or in your browser (but it's possible).

The application style itself is fully customizable and it's only one possible implementation. It's not a problem to change it or create a new one from scratch. We've defined that our standard applications have a menu, a toolbar a content are (for screens) and an authentication mechanism (login).

If you compare the vaadinUI with Swing or JavaFX UI, you'll see that the vaadin style has a completely different menu. There's also a legacy mode which shows windows for every screen, but this style isn't the preferred one. Sure, sometimes this style makes sense but it's not very user-friendly. If you have an application with few screens, a simple menu would be useful and if your application has many screens, the corporate style could be better because it has a menubar and a sidepane for quick navitation.

The mobile variant is our latest style and it's really different. You won't use apps in MDI style. Sure, we have this style but it's ugly. We like hamburger menus as shown in the screenshots.

JVx is very fast, flexible and powerful. Don't waste time for platform problems, simply implement your requirements by using JVx.

Talk: JVx stellt sich vor. Zurück zur Effizienz

Wir sind am Dienstag, 03. November zu Gast bei der JUG Hamburg.

Nähere Details gibt es hier.

Im Moment sieht die Teilnehmerzahl verblüffend aus und das Thema dürfte auch für viele passen. Wir können allen interessierten schon jetzt versprechen, daß wir einige Überraschungen mitbringen. An einem zusätzlichen Highlight arbeiten wir noch und lasst euch einfach überraschen. Es wird auf jeden Fall etwas neues sein!

JVxEE 1.2

JVxEE version 1.2 is out!

The good news

JVxEE is now available from Maven central, that means that you can add it as dependency to your Maven projects:

<dependency>
    <groupId>com.sibvisions.jvx</groupId>
    <artifactId>jvxee</artifactId>
    <version>1.2</version>
</dependency>

The first of the two major changes are that we fixed possible exceptions that might be thrown by JPAStorage.getEstimatedRowCount(ICondition), it should now work under all situations.

The second change is the handling of foreign key columns. Previously, foreign key columns where named with the pattern "REFERENCEDTABLE_REFERENCEDCOLUMN", which can lead to collisions if there is more than one column referencing the same table and primary key. So it was possible that you would end up with two columns with the same name, which of course can't be handled by the storage and databook correctly. We devised a new naming scheme and from now on the foreign key columns are named with a combination of the referencing column and the referenced column.

An example:

@Entity public class A
{
    @Id private int id;
    private B source;
    private B target;
   
    // Getters/Setters
}

@Entity public class B
{
    @Id private int id;
    private String name;

    // Getters/Setters
}

With 1.1 the generated columns would look like this, for entity "A":

ID          BigDecimal
B_ID        BigDecimal
B_NAME      String
B_ID        BigDecimal
B_NAME      String

And with 1.2:

ID          BigDecimal
SOURCE_ID   BigDecimal
SOURCE_NAME String
TARGET_ID   BigDecimal
TARGET_NAME BigDecimal

This is definitely an improvement!

The bad news

There is always a downside :(

The changes in the foreign key column naming scheme, to avoid collisions, also mean that most foreign key columns do now have a different name. You'll have to check your code for usages of the now differently named columns.

But there is also an upside! With EPlug you will find those easily.

Usage example

JVxEE provides the possibility to utilize the Java Persistence API (JPA) as backend for storages and databooks. JPA is powered by POJOs, like these:

@Entity public class Aircraft
{
    private String country;
    private String description;
    @Id @OneToMany private String registrationNumber;
}

@Entity public class Airport
{
    @Id @OneToMany private String code;
    private String country;
    private String location;
    private String name;
}

@Entity public class Flight
{
    @OneToOne private Aircraft aircraft;
    private String airline;
    @OneToOne private Airport airportDestination;
    @OneToOne private Airport airportOrigin;
    @Id private String flightNumber;
}

This is an extremely simplified model for airline flights.

There is an aircraft that can be used, airports that can be flown to and from and the flight itself. Flight is referencing both, the aircraft and the airport. Now we only need to tell JPA about these classes by placing a persistence.xml in the META-INF directory, like this one that we use for our unit tests:

<?xml version="1.0" encoding="UTF-8" ?>
<persistence xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
             xsi:schemaLocation="http://java.sun.com/xml/ns/persistence              
                                 http://java.sun.com/xml/ns/persistence/persistence_2_0.xsd"

             version="2.0" xmlns="http://java.sun.com/xml/ns/persistence">

  <persistence-unit name="test" transaction-type="RESOURCE_LOCAL">
    <class>com.sibvisions.rad.persist.jpa.entity.flight.Aircraft</class>
    <class>com.sibvisions.rad.persist.jpa.entity.flight.Airport</class>
    <class>com.sibvisions.rad.persist.jpa.entity.flight.Flight</class>

    <properties>
      <property name="javax.persistence.jdbc.driver" value="org.hsqldb.jdbcDriver" />
      <property name="javax.persistence.jdbc.url" value="jdbc:hsqldb:hsql://localhost/db" />
      <property name="javax.persistence.jdbc.user" value="sa" />
      <property name="javax.persistence.jdbc.password" value="" />

      <property name="eclipselink.ddl-generation" value="drop-and-create-tables" />
      <property name="eclipselink.ddl-generation.output-mode" value="database" />
      <property name="eclipselink.logging.level" value="FINE"/>
    </properties>
  </persistence-unit>
</persistence>

(Sure, it's also possible without manual XML mapping)

Now all that is left is creating a new storage that uses the JPA:

EntityManagerFactory entityManagerFactory = Persistence.createEntityManagerFactory("test");
EntityManager entityManager = entityManagerFactory.createEntityManager();

JPAStorage storage = new JPAStorage(Flight.class);
storage.setEntityManager(entityManager);
storage.open();

And that's it! From here on there is only JVx code.

DOAG 2015 - I'm a speaker

2015-K_A-Banner-Speaker-180x150-ENGL   I'm a speaker at DOAG 2015 in Nuremberg.
My talk will be about "Mobile applications with JavaFX"

Read more.


I'll show you some really cool things with JVx and JavaFX on mobile devices. Let yourself be surprised.

VisionX 2.2 with OpenShift support

Our next VisionX release will support OpenShift. We wrote about OpenShift and our application test some weeks ago. It was so impressive that we did an integration in VisionX.
VisionX got additional menus and options for OpenShift and it handles complete communication. It's really end-user friendly. Usually, only developers can use OpenShift and create applications for the platform.

OpenShift platform was our preferred platform for VisionX because it has a complete REST API and a simple Java library. Many other platforms don't offer the same quality or are too complex for an integration. OpenShift itself has a simple frontend but it wasn't designed for end-users.

Why does an end-user need OpenShift?

To realize ideas.

Why should an end-user do that?

Why does and end-user need a website? ... to present itself or products.

Many end-users create Excel sheets or use app builders to realize ideas. The problem is often the deployment because and end-user can't deal with databases, application servers or PaaS providers. The same applies to startups.

VisionX is end-user friendly and enables innovation.

What we have in VisionX?

VisionX supports configuration of your OpenShift account. The only thing you need is an already activated OpenShift account. Simply register on OpenShift and that's it. The rest will be handled by VisionX. Don't create SSH keys or open tunnels to access your remote database or application server. VisionX will do all this tricky things for you.

We have a short Video for you. It demonstrates the OpenShift integration of VisionX. The first part shows configuration of a fresh OpenShift account. In the second part, we create a simple (unstyled) application and the last part is the deployment.

The whole video lasts 4:30 minutes. Have you ever created a full database application with menu, toolbar, user authentication, an input form and deployed in around 5 minutes?

Multi-IDE support for VisionX


(To be honest: Deployment wasn't as fast as shown in the video, because upload time can't be improved)

Next JVx and VisionX release?

Both products are code complete and JVx passed all tests. We're in the test phase with VisionX and do some smaller fixes, but it looks very stable.

We set the official release of VisionX 2.2 to August, 17th. We will release JVx 2.3 during the coming week (~ August, 7th).

VisionX 2.2 will come with some great new features like Java 8 + Multi-IDE support and our new MorphPanel.

MorphPanel?

It's a new UI component. You can use it to visualize a table of records (grid) and show record details as form in a tab area, as split panel, a popup or as replacement of your grid (= web mode).

It's soo useful. Usually you would create two or more screens for the same use-case but one screen with one MorphPanel is enough with VisionX 2.2.

A simple use-case: You have one master-data screen and want to show an edit screen for the records on double click or button click. You need one screen for showing master-data and another screen for the edit form. The master screen opens the edit screen with an additional parameter, to show the correct record in the edit screen... (boring).

Simply add a MorphPanel to your master-data screen, set Popup mode, design the popup and you're done. This is great for desktop applications and awesome for web applications!

Details and screenshots will follow!

Interested?

Get ready for VisionX 2.2.

SourceForge outage and JVx

You know that we use SourceForge (SVN services) for our open source projects like JVx, Vaadin UI, JavaFX UI, Online Help and some others.

The whole platform had big problems and so we couldn't use our repositories as usual. It wasn't a real problem for us because we had backups and our local repositories were up-to-date, but it wasn't possible to build snapshots or create nightly builds.
Our build infrastructure is directly connected to our SVN repositories and so we had no chance to build our projects.

Since yesterday, all our repositories are online. We made some tests and everything was fine. We lost one full day (July, 17th) because SourceForge stopped working at July, 17th and backups were from July, 16th. But also not a problem because we had local copies.

We did some migration checkins and now, everything is online. Our SF repositories are up-to-date.
Our "nightly build" was started some minutes ago and everything was finished without problems.

So, we're back in the game.
(A big "Thank you" to all SF operators for their support, daily reports and countless hours of restoration)

Future?

We got some questions during last days and most of you asked us if it wouldn't be better to leave SF and use GitHub instead. We don't think this makes sense because such problems can happen with all providers - sure, they should never happen.

The migration effort from SF to GitHub is high and we don't have visible benefits. We know that git has some advantages compared to SVN but we don't need more than Source Code versioning and the checkin history. It's that simple. SF services aren't as fancy as GitHub services and the repository access via browser is better with GitHub, but this wasn't important for our decision.

It was important for us to use a big OpenSource provider and SF is a dinosaur in this area. We don't plan to leave SF but it's not impossible, e.g. if the environment changes.