Lessons Learned from Creating a Data Intensive, Multi-tier Application in JavaFX

In December 2008 I featured a JavaFX application spotted "in the wild" named Sapphire, of which a more recent screenshot appears below:

According to the Sapphire User Guide, "The Sapphire classroom observation software reflects the state-of-the-art in education technology. Sapphire provides an easy-to-use interface, multiple platform deployments, and interchangeable observation forms which can be customized to fit most any situation. Cutting-edge Java technologies power Sapphire. From the embedded Derby database through custom Java libraries, all the way out to the JavaFX graphical interface, we designed Sapphire to be flexible, extensible, and deployable over a wide range of user environments. Unlike traditional rubrics, Sapphire can accurately time instructional processes to the level of seconds and efficiently categorize timing results according to myriad criteria. Its ability to incorporate the difficult issue of partial engagement relatively effortlessly is unique in the industry."

By the way, you can try out this application via Web Start by clicking either of the screenshots above. Note: The Standards Company is in the process of acquiring a code-signing certificate, but until then there will be a warning that states that the digital signature cannot be verified.

I asked Ben Jones of The Standards Company to fill us in on lessons learned as his company has been enhancing Sapphire, and he responded with the following:

"Just a few months ago we deployed the community edition of Sapphire which you covered in a December JavaFXpert blog post. The development of Sapphire continues. Incorporating user experiences and JavaFX community feedback, a February update to the application included many changes. In comparison to that initial release, the most obvious difference appears in the user interface; however, the real changes run much deeper than the GUI skin. The most significant of these stems from embracing JavaFX as a real RIA technology instead of treating it as simply a graphical markup script. This might sound like an odd statement for a data intensive, multi-tier, production level application like Sapphire, so let me explain in a bit more detail.

Initially when Sapphire was on the drawing board, we considered JavaFX as a convenient way to “skin up” a GUI for the application—a type of Swing alternative. This meant using JavaFX as a quick means to produce a graphical veneer from which to hang the real functionality. Such a simplistic view of JavaFX led us down a path where the mindset became “how do I wrap my Java application?”, not “how do I create usability?” That distinction profoundly affected our original development efforts by fostering a jump-to-Java design.

A case in point, the original registration process found in Sapphire relied upon a custom Java class that wrapped a DOM parser to deal with the XML returned from a REST web service. While perfectly serviceable, this approach failed to capitalize on the asynchronous pull parsing available in JavaFX. The update dropped this approach in favor of using the RemoteTextDocument with a JSON pull parser that binds directly to the registration model. The asynchronous nature of the RemoteTextDocument allows the user interface to remain active and responsive to interactions while the direct parser to model binding better supports future extensibility options.

There are numerous areas within Sapphire making the transition from wrapped Java functionality to inherent JavaFX capabilities. While the ability to “step-out” to Java provides tremendous wealth of potential functionality, the real power comes from using the unique abilities of JavaFX and blending Java back in where appropriate. From our perspective, it has been a lesson well learned. "

Thanks, Ben, for your insight, and congrats on the development and success of this JavaFX application!