to be allowed to upload it to the google store. Maybe once a year
requiring an upgrade to the latest release is Ok for Google, for
app-devs it is a chore that makes no sense.
Avoiding using the deprecated one would make sense, just forcing
me to use the latest, not so much.
This adds the backend code and the buttons that allow deletion of a
wallet.
Formerly you could archive a wallet and thus remove it from view,
at popular request an archived wallet now gets a button in the
wallets overview to delete the actual wallet completely.
This indeed also removes the files from disk, making it unrecoverable.
Additionally, an actually more complex feature, this allows an existing
wallet to have its history removed and start a re-scan to re-download
all transactions and build the balance.
This is useful for debugging or for recovering from buggy code we
probably had in older versions. (nobody is perfect all the time)
This code now catches the exceptions and logs it.
For instance when a wallet is aware of a transaction but can't find
the file on disk, we now don't just weirdly misbehave but forward an
error.
This separates it into two objects in order to make thead-safety easy
using Qt's signal/slot mechanism.
Additionally this removes magic timeout numbers and simply starts a
timer to check for changes and emit a signal if the status actually
needs updating.
Testing also shows that QML calls the getter a LOT, so I also moved the
broadcastStatus to be buffered and just return that on the call.
This incidentally also simplifies the code, double win.
The tx-broadcast was tied completely to a 'payment' object, this is now
more made into individual parts that can be reused outside of the
'payment' usecase.
This splits the latter class into an abstract baseclass that finds a
server and handshakes with it called ElectronXClient
and then as a subclass the import handler handling doing what it always
did.
The Payment specific methods paymentAmount and paymentAmountFiat are now
made to return the data from the first output and no longer required
there to be exactly one.
This allows these methods to still give useful info in the case of
payment protocol based creation of more complex payment objects.
This takes the concept added some 5 years ago to Electron-Cash and adds
this to Flowee Pay as well.
In a nutshell, it allows a bip21 style payment request to include a
'comment' with the argument op_return_raw
This comment is expected to be a hex-encoded data payload that then will
be added as a single output to the transaction we build to fullfill the
payment request.
As a natural consequence of how uri's work, adding the argument multiple
times will cause multiple outputs to be generated. We check that this
does not exceed the expected max sizing for op-return.
The Tx::Iterator no longer returns the token data as part of the
output-script, but instead sees them as separate tags.
This removes most of the code here, and makes future deeper
support of cashtokens much easier.
tomFlowee