... in favor of initialization via constructors. It's fine to break out
a separate private initialization method, but it appears to be
unnecessary to formally model an initialization lifecycle distinct from
construction.
After removing all empty implementations of lifecycle methods (see
earlier commit), the #terminate method was no longer called anywhere
other than from CachedViewCB's #terminate method, which per its own
Javadoc is supposed to call #deactivate. Now it does just that.
Significant changes in the way that controllers and models interact with
backend services. Most important is the introduction of RxJava's
Observable. See individual commit comments for details.
Conflicts were minor, mainly dealing with the fact that MainPM had been
modified in master, but removed completely on the 'cbeams' branch. All
changes have been preserved by carrying them over to MainModel.
* cbeams:
Improve service initialization coordination using rx.Observable
Redesign controller/model types and apply to gui.main.Main*
Conflicts:
build.gradle
src/main/java/io/bitsquare/btc/WalletService.java
src/main/java/io/bitsquare/gui/main/MainPM.java
src/main/java/io/bitsquare/msg/tomp2p/TomP2PNode.java
This change introduces the use of RxJava's Observable [1] to redesign
how we work with non-deterministic and/or event-based information, such
as: connecting to peer-to-peer infrastructure, synchronizing the bitcoin
blockchain, and so on.
Prior to this commit, these activities were initiated in methods like
WalletService#initialize and TomP2PMessageService#init. These methods
accepted 'listener' interfaces, and these listeners' callback methods
would be invoked whenever work progressed, completed, or failed.
This approach required significant coordination logic, which, prior to
this commit, was found primarily in MainModel#initBackend. A primary
goal of the logic found here was to determine when the backend was
"ready". This state was represented in MainModel's `backendReady` field,
which would be set to true once the following three conditions were
satisfied:
1. the message service had finished initialization
2. the wallet service had finished initialization, and
3. the blockchain synchronization had reached 100%
Monitoring these three states was complex, and required hard-to-follow
conditional logic spread across a number of locations in the code. In
any case, however, once these three conditions were satisfied and
backendReady's value was set to true, a listener on the backendReady
field (in MainViewCB#doInitialize) would then populate combo boxes and
pending trade counts in the main view and cause the splash screen to
fade out, rendering the application ready for user interaction.
The introduction of rx.Observable is designed to achieve the same
show-the-splash-screen-until-everything-is-ready functionality described
above, without the complex monitoring, conditional logic and nested
callbacks. This is achieved by modeling each process as an Observable
stream of events. Observables in RxJava can emit any number of events,
and can complete either normally or with an error.
These observables may be 'subscribed' to by any number of subscribers,
and events emitted can be acted upon by instructing the subscriber what
to do `onNext`, `onCompleted`, and `onError`. So for example
WalletService now exposes an Observable<Double> called bootstrapState.
This Observable is subscribed to in MainModel#initBackend in such a way
that every time it emits a new double value (i.e. a new percentage), the
various bootstrap state text labels and progress indicators are updated
accordingly.
Where it gets really interesting, however, is when Observables are
combined. The primary complexity described above is coordinating the
fading out of the splash screen with the completed initialization of all
backend services. As can now be seen in MainModel#initBackend, the
wallet service and message service Observables are simply "merged" into
a single observable and returned. From the MainViewCB side, this "single
backend observable" is subscribed to and, when it completes (i.e. when
all the underlying Observables complete), then combo boxes and pending
trade counts are populated and the splash screen is faded out.
Understanding RxJava, Observables, and the principles of "Functional
Reactive Programming" takes time. It is a paradigm shift in dealing with
concurrency and non-determinism, but one that ultimately rewards those
who take the time. In the end, I believe it's use will result in a
significantly more concise and robust internal architecture for
Bitsquare, and using RxJava's lightweight, well-adopted and
infrastructure-agnostic API leaves us open to using Akka or other more
sophisticated infrastructure later without tying ourselves to those
specific APIs (because virtually anything can be modeled as an
Observable). Achieve these benifits means that core committers will need
to understand how RxJava works, how to think about it, and how to design
using it. I have spent the better part of the last week getting to know
it, and I am certainly still learning. I can recommend many resources to
aid in this process, but having gone through it myself, I recommend that
everyone read at least [1] and [2] first.
[1]: https://github.com/ReactiveX/RxJava/wiki/Observable
[2]: [The introduction to Reactive Programming you've been
missing](https://gist.github.com/staltz/868e7e9bc2a7b8c1f754)
Major changes:
- Introduce Controller base class and FxmlController subclass. The
latter has awareness of an @FXML "root" Node. Together, these classes
functionally replace the ViewCB class, however ViewCB has been left
in place so as to avoid the need to refactor all controllers at once.
In this commit, the new Controller hierarchy has been applied only to
the gui.main.MainViewCB controller.
- Eliminate MainPM in favor of placing all logic in MainModel. This is
potentially temporary, i.e. the distinction between data model and
presentation model may be reintroduced in later commits, but for the
purposes of this change, the goal was to simplify and remove as many
layers as possible. The precise arrangement of controller and model
classes is a topic to be discussed when reviewing this change.
Minor changes:
- Inject model objects into MainModel instead of MainViewCB.
Previously, model objects such as WalletService were injected into
both MainModel and MainViewCB. Now this intended separation is more
strictly observed.
- Remove comment section markers and empty methods from MainModel and
MainViewCB
- Use public constructors in MainModel and elsewhere. This avoids
unnecessary IDE warnings, allows the possibility of unit testing, and
generally avoids surprise for the reader.
- Eliminate Profiler statements in MainModel and elsewhere. These
statements are fine during debugging or optimization sessions, but
should otherwise be removed so as not to fill the logs with
unimportant information.
- Change signature of User#getCurrentBankAccount to return
ObjectProperty. Previously, this method returned the underlying
BankAccount; now returning ObjectProperty allows other components to
add listeners (such as for user persistence when changing accounts in
the UI).
- Handle user persistence on account change elsewhere; namely add a
listener for it in the MainModel constructor. Previously this was
done in MainModel#setCurrentBankAccount, which amounts to a side
effect in a setter method--something to avoid if possible.
- Expose MainModel#getUser, and eliminate delegate methods previously
in place that mediated access to the User object. This is mainly for
consistency and concision.
