This change migrates from using `NetworkParameters` to `Network` for specifying the network and
also decouples from static methods in `Address` with an interface/implementation approach.
Note that there are 3 use cases for address parsing:
1. Any network is allowed - AddressParser.parseAddressAnyNetwork(String)
2. Parse for a specified network - AddressParser.parseAddress(String, Network)
3. Parse for a previously-specified (context dependent) network - AddressParser.Strict.parseAddress(String)
In most use cases, an AddressParser instance can be accessed through the Wallet,
which already knows the Network type and in this context validation for network makes
sense. This is why `Wallet` is implementing `AddressParser.Strict`
BitcoinURI allocates its own DefaultAddressParser for now, as do some other tests
and examples that don't have access to a Wallet
In the future DefaultAddressParser may be replaced by something loaded
via the ServiceLoader mechanism or other dynamically configured mechanism.
* WalletAppKit: add a constructor that takes a BitcoinNetwork
* WalletAppKit: deprecate constructors taking netParams or Context
* WalletAppKit: add an accessor for network()
* Update examples, tools, and wallettemplate to use the new constructor
This also moves Coin, Fiat, its parent Monetary and the related MonetaryFormat into the new base package.
See the provided package-info.java for details.
* Make the static field `estimatedKeyDerivationTime` private
* Refactor the calculation to a private, side-effect free function
* Replace `estimatedKeyDerivationTimeMsec()` with `initEstimatedKeyDerivationTime()`
** Don’t return a value that wasn’t unused anyway
** Make better use of CompletableFuture API
* Platform.runLater wasn’t needed because no JavaFX functions are called
* Make all public fields private and wrap with accessors
* Make `WalletAppKit` (was confusingly named `bitcoin`) field a member not a static
* Rename `bitcoin` to `walletAppKit`
* Extract abstract class `WalletApplication` from `WalletTemplate`
* `WalletTemplate` implements `loadController()` with resource names
* `MainController`: Add `scene` member and `scene()` method
* Introduce `AppDelegate` class for delegating JavaFX `Application`
* Move almost all of `Main` to `WalletTemplate`
Rationale:
* The “template” JavaFX Application main class (`Main`) is now about 30 lines of code
* `Main` class allows easy switching between TestNet and MainNet (in fact it could become a command-line argument) and other configuration changes (e.g. `preferredOutputScriptType`)
* Prepares the way for the next steps of refactoring
* OverlayController: rename init method, add rootController to params
* OverlayableStackPaneController: update to use updated initOverlay() method,
also pass this.getClass() into GuiUtils.getResource()
* GuiUtils.getResource(): replace reference to MainController.class with clazz parameter
* Main: Reduce visibility to “package” of 3 static globals
* MainController: Reduce visibility of `instance` static to “package”, initialize
addressControl by calling 2 initialization methods
* 4 other controllers: Update for OverlayController changes
* ClickableBitcoinAddress: OverlayController changes, eliminate use of Main.APP_NAME
Rationale:
* Decrease coupling
* Eliminate cross-package use of `Main` and `MainController` static globals
* Prepare for further refactoring — moving wallettemplate.controls package
to org.bitcoinj.walletfx.controls
* Extract abstract class OverlayableStackPaneController from MainController
* Rename OverlayWindowController to OverlayController (Window was misleading)
Rationale:
1. Overlay functionality is independent of MainContoller’s wallet functions
2. Increases reusability of classes in module
3. Prepares for further refactoring
Rationale:
1. Stronger typing makes code more readable and refactorable
2. Eliminates “automatic” reflection in MainController
3. Makes overlayUI field in implementing classes private
4. Is a step towards further refactoring and reusability
Move OverlayUI and other related functionality from Main (Application) class
to MainController.
Motivation:
1. This simplifies the Main class
2. The code more logically belongs in the controller
3. The code being in the controller increases reusability
4. Is a first step towards additional refactoring made possible
because MainController can subclass an abstract class and Main
can’t because it must subclass Application
I did this for two reasons:
1. So users will know why the buttons are there and that they work
2. A convenient way to test the informational alert function.
