Services and Controllers
This class diagram presents the objects involved in a fully-running application. HomeScreenController creates the other FX Controllers via an FXMLLoader.load() call on FXML files. HomeScreenController also creates the AbstractModules and Injectors that realize the Services used by the Application. Guice objects and FX objects are cached for memory and CPU performance.
|Full Class Model of Demo Application|
Adding on to this application will involve adding new Services, FXML / Controller pairs, or both. At the start of such new development a decision should be made on the Service side as to whether or not this is a CoreModule service. If it's expected to be used in one or more @SubApps, then the service should be added to the CoreModule and the bootstrap mode retested.
Adding an item to the CoreModule would produce additional dependencies alongside ServiceObject1 and its implementation.
HomeScreenController and other Core Views
HomeScreenController is a single screen with a menubar and programmatically-created Buttons. It is implemented with an FXML / Controller pair but could expand to use more FXML / Controller pairs. For example, if a popup is needed by the HomeScreenController, it would appear in the app_core package. Since all modules are dependent on app_core, they can make use of this shared code.
A login mechanism in one candidate for an addition to app_core. There would be a LoginService added to CoreModule and an FXML / Controller pair to gather the username and password.
Preloading may also find a home in app_core, although I might put a preloader class alongside the MultiStageMain Application subclass.
This part discussed the core service available to all modules. The next part will finish the series with a discussion on what it is to be a SubApp.
Click Click Dynamic FX Application Modules - Part 6 - Module Development for the final part of the series.