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) |
||
---|---|---|
.idea | ||
doc | ||
gradle/wrapper | ||
package | ||
src | ||
.gitignore | ||
.travis.yml | ||
build.gradle | ||
gradlew | ||
gradlew.bat | ||
LICENSE | ||
README.md |

What is Bitsquare?
Bitsquare is a cross-platform desktop application that allows users to trade fiat money (dollars, euros, etc) for bitcoin without relying on centralized exchanges such as Coinbase, Bitstamp or (the former) Mt. Gox.
By running Bitsquare on their local machines, users form a peer-to-peer network. Offers to buy and sell bitcoin are broadcast to that network, and through the process of offering and accepting these trades via the Bitsquare UI, a market is established.
There are no central points of control or failure in the Bitsquare network. There are no trusted third parties. When two parties agree to trade fiat money for bitcoin, the bitcoin to be bought or sold is held in escrow using multisignature transaction capabilities native to the bitcoin protocol.
Because the fiat money portion of any trade must be transferred via traditional means such as a wire transfer, Bitsquare incorporates first-class support for human arbitration to resolve any errors or disputes.
You can read about all of this and more in the overview, whitepaper, arbitration and risk analysis documents. Several screencasts are available as well.
Status
Pre-alpha and under heavy development.
Building from source
- Install the latest JDK (8u20 or better)
- Clone this repository
- Build and launch the Bitsquare JavaFX client by running:
./gradlew run
Pass command line arguments to the app via the Gradle -Pargs
property as follows:
./gradlew run -Pargs="--help"
Or, build an executable jar with the appJar
task:
./gradlew appJar
Run the app as follows:
java -jar build/libs/bitsquare-<version>-app.jar
Pass the --help
flag to see what options are available:
java -jar build/libs/bitsquare-<version>-app.jar --help
To build a headless bootstrap node jar, run the bootstrapNodeJar
task:
./gradlew bootstrapNodeJar
Run the bootstrap node:
java -jar build/libs/bitsquare-<version>-bootstrapNode.jar
See doc/build.md for additional information.
Staying in Touch
Contact the team and keep up to date using any of the following:
- The Bitsquare Website
- The #bitsquare IRC channel on Freenode (logs)
- Our mailing list
- @bitsquare_ on Twitter
- Get in contact with us
- GitHub Issues
License
Bitsquare is free software, licensed under version 3 of the GNU Affero General Public License.
In short, this means you are free to fork this repository and do anything with it that you please. However, if you distribute your changes, i.e. create your own build of the software and make it available for others to use, you must:
- Publish your changes under the same license, so as to ensure the software remains free.
- Use a name and logo substantially different than "Bitsquare" and the Bitsquare logo seen here. This allows for competition without confusion.
See LICENSE for complete details.