Overview of major changes:
- Introduce top-level `viewfx` package for general-purpose MVVM-style
infrastructure classes. Note that this package naming will likely
change, especially if and when we extract it to a physically-separate
library.
- Introduce View and Model class hierarchies that capture the various
lifecycle and model management concerns throughout the existing
Bitsquare application (see `viewfx.view` and `viewfx.model` packages)
- Introduce @FxmlView and FxmlViewLoader to support declarative,
convention-over-configuration support for FXML-based views.
Eventually, this approach will allow for seamless mixing of FXML- and
non-FXML based view implementations within the same application.
- Introduce a type-safe approach to intra-view navigation: eliminate
the Navigation.Item enum in favor of navigating directly from one
view to another using *View class literals. This change is closely
tied to the @FxmlView approach described above.
Many additional smaller changes are included as well; see individual
commits for details.
* cbeams: (75 commits)
Rename viewfx.view.support.guice.{Guice=>Injector}ViewFactory
Use instanceof checks on views instead of class equality
Add CachingViewLoaderTests
Revert "Remove System#exit call from BitsquareApp#stop"
Change signature of ViewLoader#load to accept Class
Complete implementation and testing of @FxmlView support
Remove System#exit call from BitsquareApp#stop
fix checkArgument
Use irc instead of fiat classes
Remove hardcoded path from ViewLoaderTests
Fix conditional logic in AccountView#activate
Polish AccountSettingsView
Introduce @FxmlView, replace Navigation.Item
Begin refactoring Navigation
Rename enum gui.{Navigation#Item => FxmlView}
Introduce viewfx.view.support.CachingViewLoader
Extract ViewLoader interface and introduce FxmlViewLoader
Fix broken tests and app exceptions due to ViewLoader changes
Bind ViewFactory interface to GuiceViewFactory impl
Move i.b.gui.ViewLoader.java => viewfx.view.support.ViewLoader
...
This reverts commit 78d3da0c4e17ce356905c3b745d9773eb458988e.
Because while eliminating the call to System#exit does mean that
JavaFX's LauncherImpl can properly report errors and stack traces, it
also means that Bitsquare never shuts down (probably due to non-daemon
threads). When System#exit is removed (or replaced with Platform#exit),
closing the Bitsquare window (or clicking Exit from the system tray menu)
results in the application no longer being able to function at the UI
level (because the JavaFX toolkit has essentially been shut down), but
the process does not exit either.
So in the meantime, this change is being reverted, and we just have to
deal with not getting stack traces at the command line when uncaught
exceptions bubble up through the #start method (specifically, exceptions
that occur before the UncaughtExceptionHandler has had a chance to be
set).
A solution to this could be to provide a custom subclass of JavaFX's own
Application class that implements a template #start / #doStart methods
trying and catching anything that is raised from #doStart and printing
the stack trace on its own.
Calling System#exit short-circuits normal error reporting, meaning that
when an exception is called within the scope of executing the
Application's #start method, the message
Exception in Application start method
is printed to the console, but without a stack trace. Removing the
System#exit call allows JavaFX's LauncherImpl to continue processing the
exception, ultimately printing out the stack trace as expected.
- Replace MultiStepNavigation and ContextAware with Wizard and Wizard.Step
- Introduce ChildOf interface
- Eliminate TradeNavigator in favor of depending directly on TradeView
