Consolidate the flow for local and remote wallet connections for
consolidate. When unlocking a local wallet wait for the macaroon to be
generated before we try to use it.
There is no need to check wether an lnd process exists and prevent
Zap from starting if so. We don't care if there is another process
running. We only care that we can successfully start up our own process.
If there is a conflict with another lnd process such as a port that we
need already being in use we already handle this elsewhere in our code.
The standard approach on Darwin is to keen applications running when the
window is closed. Clicking the apps icon again in the doc should bring
back the application window.
This changeset refactors things to handle this. It will keep Zap and lnd
running in the background when the main application window is closed.
Quitting the app will stop both the app and lnd.
Fix#586Fix#601
Fetch the current block height from multiple block explorers early on in
the sync process. This ensures that we get the correct block height in
the case where our BTCd node is still mid way through syncing. Do this
in the main process rather than in the render process.
`main.dev.js` was hard to follow and understand the code flow. It housed
code to handle quite a few distinct things. This is a fairly substantial
refactor of the application startup code in which we:
A new `Neutrino` class has been created with 2 public methods. `start`
and `stop`. `start` will launch a new `lnd` process whilst `stop` will
stop it. This class extends the `EventEmitter` class and emits the
following events based on activity detected from the lnd log output.
- `grpc-proxy-started` - gRPC started
- `wallet-opened` Wallet opened
- `fully-synced` - lnd is all caught up to the blockchain
- `got-block-height` - got updated block height
A new `ZapController` class has been created which houses all of the
logic for intraprocess communication between the main and renderer
processes.
Previously we had several `setInterval` loops that were checking every
second to see if the application status has changed and trigging the
appropriate action if so. This was pretty hard to follow has been
replaced here with more extensive use of promises. This enables us to
act instantly to relevant changes rather than waiting up to 1 second
for the next interval to fire.
Now, the only stuff that lives in `main.dev.js` now is the top level
`app` listeners, which calls out the other parts mentioned above to
bootstrap the application.
Tom Kirkpatrick