FX Playground

 

 

 

Update: The FX Playground project can be found at: https://bitbucket.org/cdea/fxplayground

Introduction

FX Playground is a JavaFX-based prototyping tool or live editor that eliminates the step of compiling Java code. This concept isn’t new, for instance the Web world there are many HTML5 playgrounds that offer online editors that enable developers to quickly prototype or experiment with various JavaScript libraries. This allows the developer to focus on visualizations or UI details without needing to set-up an IDE project or mess with files. Even older (pre-dating) than playgrounds are REPLs (Read Eval Print Loop) where dynamic languages such as Groovy, Python, Ruby, etc. provide an interactive interpreter command line tool to allow developers to quickly script code to be executed. Scala is a compiled language, but also provides a REPL tool.

After finishing the book JavaFX 8 Introduction by Example I noticed each example was created as separate NetBeans projects which seemed a little overkill for small examples. Because the book is based on Java the language each program needed to be compiled (via javac) prior to execution. Larger projects will typically need to be set-up with a proper classpath and resources in the appropriate directory locations. Even larger projects will also need dependencies which typically reside on Maven repositories.

JavaOne 2014

Based on timing I was able to submit a talk regarding JavaFX based playgrounds just in time. After awhile I was pleasantly surprised that my proposal (talk) was accepted. You can check out the session here. Also, I will be presenting with my good friend Gerrit Grunwald (@hansolo_). So, be prepared to see awe-inspiring demos. Since the talk is a BoF (birds of a feather) the atmosphere will be low-key and very casual. I hope to see you there!

The JavaOne talk is titled “JavaFX Coding Playground (JavaFX-Based Live Editor Tool) [BOF2730]”.  Based on the description you’ll find that the tool will be using the NEW! Nashorn (JavaScript) engine to interact with JavaFX primitives. The figure below depicts the FX Playground tool’s editor windows and a JavaFX Display area. Starting clockwise at the lower left is the code editor window allowing the user to use JavaScript (Nashorn) to interact with nodes. Next, is the JavaFX FXML editor window allowing the user to use FXML (upper left). The FXML window is an optional.  In the upper right, you will notice the JavaFX CSS editor window allowing you to style nodes on the display surface. Lastly, to the bottom right is the output area or better known as the DISPLAY_SURFACE.

FXPlayground’s editor windows

FX Playground in Action

Because FX Playground is still in development I will give you a glimpse of some demos that I’ve created on Youtube. The following are examples with links to videos.

• FXPlayground Path Example – This example is an updated example hosted at the BitBucket repo at https://bitbucket.org/cdea/fxplayground.
• FXPlayground w/Webcam – Nashorn w/sarxos/webcam-capture library
• FXPlayground3d – Nashorn and JavaFX 3D
• FX Playground now has a settings slide out panel – Nashorn, Rectangle w/CSS, and MediaView
• FX Playground Using Enzo library – Nashorn and Enzo Library
• FX Playground Testing Video w/ MediaView and WebView – Nashorn, MediaView and WebView

 

Roadmap

There are plans to opensource the code, but for now there is much needed functionality before public consumption.

The following features are a work in progress:

• Make use of FXML editor window.
• Pop out the display panel into its own window
• Save, SaveAs, and Load Playgrounds
• Build software to be an executable for tool users. (90% done)
• Make the tool capable of using other languages (JSR 223)

I want to thank Oracle corp. especially the following engineers who helped me (some of the engineers below are not Oracle employees):

• David Grieve – @dsgrieve
• Jim Laskey – @wickund
• Sundararajan Athijegannathan  – @sundararajan_a
• Danno Ferrin – @shemnon
• Sean Phillips – @SeanMiPhillips
• Mark Heckler – @MkHeck
• Jose Perada – @JPeredaDnr
• Gerrit Grunwald – @hansolo_
• Jim Weaver – @JavaFXpert

References

The FX Playground project can be found at: https://bitbucket.org/cdea/fxplayground

CarlFX’s Channel – https://www.youtube.com/channel/UCNBYRHaYk9mlTmn9oAPp1VA

7 of the Best Code Playgrounds – http://www.sitepoint.com/7-code-playgrounds

NetBeans – https://www.netbeans.org

JavaFX 8 Introduction by Example – http://www.apress.com/9781430264606

Nashorn – https://wiki.openjdk.java.net/display/Nashorn/Main

Enzo – https://bitbucket.org/hansolo/enzo/wiki/Home

Harmonic Code – http://harmoniccode.blogspot.com/

Advertisement

JavaOne 2013 BOF2605 JavaFX, Widgets, and Apps, Oh My! Launching Frameworks for Platforms Large and Small

Multipurpose widget called KeyHole displaying maps and the weather.

Introduction

This is probably the longest title I’d ever create for a blog entry.

In my spare time I’ve been working with Mark Heckler(The Java Jungle), Hendrik Ebbers (GuiGarage), and Gerrit Grunwald (Harmonic Code) on the idea of application launching frameworks. We will be presenting two approaches to running widgets and applications on the desktop and embedded device (Raspberry Pi) environments. The talk will be a BoF (Birds of a feather) session at JavaOne 2013 (BOF2605). This is where the Java/JavaFX community will have lots of fun demoing, discussing and sharing ideas on topics such as:

• Application Containers / Dashboards
• Widgets/Apps/Games/Gadgets
• Widget/App Development workflow
• Widget/App life cycle
• Deployment / App stores

To see a sneak preview of Hendrik Ebbers’ implementation of a Roku-AppleTV-like application container check out his blog entry here: http://www.guigarage.com/2013/08/boxfx-javaone-preview-1/ The application container is called BoxFX.

Mark and I have been working on an implementation of a desktop-centric application container called TrayFX. To see a sneak preview of TrayFX visit an interview with Mark Heckler hosted by Stephen Chin. Another sneak preview of TrayFX in action is on my youtube channel here: http://www.youtube.com/watch?v=x_KLIzVSiu8 and http://www.youtube.com/watch?v=WwzwsGxd-Jk

In this blog entry I will discuss some high level concepts relating to the framework eWidgetFX and the application container TrayFX. Since there is a lot to digest I would like to at least (briefly) show you each layer in the architecture.

Disclaimer: BoxFX and TrayFX are currently private APIs. Both approaches have similarities, however they are independent projects. It’s important to hear from the audience for potential use cases. They eventually will wind up as open source projects. Also, leading up to the JavaOne talk some diagrams or APIs are subject to change in this blog entry.

eWidgetFX

eWidgetFX is a core library (API) that widgets and app containers will depend on.  Shown below depicts the layers:

Core widget framework API that widgets and widget containers depend on.

The APIs provide services for loading widgets, widget life cycles, and utilities for the widget developer. The main idea was to provide a cross platform application API for application container developers and widget developers to coexist. In fact the goal was to have cross platform widgets & apps capable of running on any app container (based on the eWidgetFX lib).

Application Containers (TrayFX)

TrayFX is an App Container instance that depends on the core widget framework (eWidgetFX). Shown below is the middle layer which is basically different custom application containers based on the core.

Application Containers depend on the eWidgetFX API (core). This allows developers to build their own custom application containers.

TrayFX is an App Container instance that depends on the core widget framework (eWidgetFX). This means that you to can develop your own JavaFX widget & app container of your liking if you don’t like TrayFX 🙂 For instance you could create one for a tablet device which may have different UI metaphors and varied screen sizes (real estate). Shown below is TrayFX launching a clock widget (on the Desktop).

A clock widget launched from TrayFX

Widgets

Widgets or Apps are either standalone applications or eWidgetFX based widgets that can be run inside of a application container. Shown below is the widgets layer:

Widgets are mini-applications that can launch standalone or launch inside a widget container such as TrayFX.

When creating widgets you can implement a Widget interface or you can extend from the abstract DefaultWidget adapter class overriding optional life cycle methods as a convenience to the developer. Shown below is a high level class diagram:

Widget’s Class Diagram using the eWidgetFX core library.

In the JavaOne BoF  (BOF2605) since the framework is still very alpha during the talk we will present a possible developer workflow to create, build, deploy, and launch widgets.  Below I would like to share a small bit of code to give you an idea of how easy it is to implement a widget on the eWidgetFX platform.

Usually, application launching frameworks have life cycles for the application containers to manage widgets & apps. Widget developers will not need to implement a Stage nor a Scene and basically focus on what they know best (their JavaFX widget as a Node). The framework APIs will allow you to interact with the JavaFX parent containers such as Stage and Scene. The eWidgetFX Widget interface is shown below which has methods that a widget developer would need to implement. For brevity please look at the comments on the methods to understand the basic widget life cycle.

package org.ewidgetfx.core;

import javafx.beans.property.ObjectProperty;
import javafx.beans.property.StringProperty;
import javafx.scene.layout.Pane;
import javafx.stage.Stage;

/**
 * User: cdea
 * Date: 4/7/13
 */
public interface Widget {
    public static enum DECORATION {
        STAGED_OS_TITLE_BAR,
        STAGED_CLOSE,
        STAGED_CONFIG_CLOSE,
        STAGED_CONFIG,
        STAGED_UNDECORATED,
        NON_STAGED_CLOSE,
        NON_STAGED_CONFIG_CLOSE,
        NON_STAGED_CONFIG,
        NON_STAGED_UNDECORATED
    };

    DECORATION getDecoration();
    void setDecoration(DECORATION decoration);

    String getName();
    void setName(String name);
    StringProperty nameProperty();

    String getVersion();
    void setVersion(String version);
    StringProperty  versionProperty();

    String getDescription();
    void setDescription(String descr);

    String getVendor();
    void setVendor(String vendor);

    String getVendorUrl();
    void setVendorUrl(String vendorUrl);

    String getVendorEmail();
    void setVendorEmail(String vendorEmail);

    LaunchInfo getLaunchInfo();
    void setLaunchInfo(LaunchInfo launchInfo);

    WidgetIcon getWidgetIcon();
    void setWidgetIcon(WidgetIcon widgetIcon);
    ObjectProperty widgetIconProperty();

    Pane getAsNode();
    Stage getParentStage();
    void setParentStage(Stage stage);

    WidgetState getWidgetState();

    /**
     * Returns a created WidgetIcon for the app container to use. Called 1st.
     * @return WidgetIcon containing a raw node representing the icon. App containers can resize.
     */
    WidgetIcon buildWidgetIcon();

    /**
     * Called after buildWidgetIcon() method to allow background processes to occur. Called 2nd.
     * Typically to collect data to update WidgetIcon's Icon overlay. An example would be
     * an email widget periodically checking email to update Icon overlay the number of emails received.
     */
    void startBackground();

    /**
     * Initialize the widget. If the developer calls this method the framework will not call it. Called 3rd.
     */
    void init();

    /**
     * Start is meant to be called when the user clicks the icon to launch widget. Called 4th.
     * Typically to start animations or position on the desktop. This should not be confused with startBackground()
 */
 void start();

 /**
 * Pause is typically used to pause animations. Or other developer defined resources.
 */
 void pause();

 /**
 * Resume is typically used to resume a animations. Or other developer defined resources.
 */
 void resume();

 /**
 * Stop is called when the widget is closed and not visible. Typically this is to stop animations, and minor cleanup.
 * The framework will call stop and stopBackground() method when exiting the app container.
 */
 void stop();

 /**
 * Stops any background processes. Called when widget is being closed by the framework when exiting app contain. Called last.
 *
 */
 void stopBackground();

}

Conclusion

While building this framework we kept coming up with more features and ideas, however with very little time left we still were able to provide common capabilities that you’ve grown to love on your device. Hopefully, this will whet your appetite before you attend the BoF at JavaOne.

All are welcome! Enjoy!

Carl