Dynamic FX Application Modules - Part 6 - Module Development

This is the last part of a six part series on dynamic Java FX application modules.  This post describes how to create such modules and where to put them in terms of source code and the target deployment.

SubApps

Extending the demo application involves adding modules called SubApps to the codebase.  SubApp is a term I'm using to describe an FX Stage / Google Guice AbstractModule pair.  A SubApp is defined in an @SubApp annotation placed on an AbstractModule subclass.  See SubApp B defined in the fms.subapp_b.B_Module class.

@SubApp(
        buttonId = "B",
        buttonTitle = "Show B",
        stageTitle = "Screen B",
        fxmlFile = "subapp_b/screenB.fxml")
public class B_Module extends AbstractModule {

    @Override    protected void configure() {
        bind( ServiceObject2.class ).to( ServiceObjectImpl2.class ).asEagerSingleton();
    }
}

The SubApp is launched from a Button with a title "Show B".  "Show B" creates a Stage titled "Show B" with a single Scene containing screenB.fxml as its root.  screenB.fxml has a controller, ScreenBController which can access ServiceObject1 from the CoreModule services (as all SubApps can) and it's own ServiceObject2 as defined in B_Module.

This package diagram is reposted to show the logical dependencies of the SubApp to the main module called app_core.  I steer away from inter-SubApp dependencies as this might make wiring buggy, especially if the dependencies are bi-directional.

SubApps Depend on app_core and Everyone Depends on framework

Although I've provided just a single ServiceObject class and a single FXML/Controller pair, a SubApp can be substantially more complex.  The @SubApp metadata serves as an entry point where common module initialization can take place in the referenced Controller.  In subapp_b's case, the @FXML initialize() method in ScreenBController will be the main initialization routine for the module.

Component and Deployment Views

In the package diagram, notice that subapp_d is set off by itself in a boarder.  That's because it is placed into a separate JAR and distributed optionally with the rest of the app.  When running my main(), I am loading the generated JAR of subapp_d rather than making an IntelliJ reference to the project.  This gives me good deployment flexibility.  If I spot a problem with subapp_d, I can simply yank it.  Or, I can swap it out with a hotfix without affecting the rest of the app.

This separation appears in the component view too.  subapp_d is a totally separate IntelliJ project (actually, a module but I've used that term enough).  See the following screenshot from my project browser.

subapp_d is Totally Separate Project and Deployment

This means that subapp_d can be put in a separate Git repository and built with it's artifacts deployed outside of the main development.  Speaking in non-technical terms, we can develop subapp_d without giving access to any more of the application than the CoreModule service interfaces.

Inside Job

subapp_a, subapp_b, and subapp_c are all inside the main project.  While they don't get the benefit of the a la carte deployment of the broken-out JAR, they still benefit from the consistency of this approach.  These modules can use the same type of metadata and initialization which can help with testing, performance tuning, and progress reporting.  If the SubApp development is done by the mainline group and there is no valid use case for the SubApps every not being deployed, then it may be worthwhile to bundle them together.

Wrap-Up

Look for an update with links to the project.  I may put this in a public GitHub.

It's easy to get started in FX.  Subclass an application. Load an FXML file with a Controller. Create a Scene.  Press Run.  And you can go this route for a while, but if there are a lot of developers working on the project, you'll find excessive coupling and an initialization routine that gets bogged down.  This post presented a structured technique for building an app based on the dynamic self-discovery of components.  If you find problems like those described in the series with your own development effort, consider taking a step backward and applying some of these principles.