We take into account the server thinking this is a scam token and avoid
downloads based on that.
The image and bcmrs are downloaded from the caching server, based on the
information from the main (info) json.
The idea of sending a transaction as a background process is a bit risky
when the OS can decide at any moment to kill the process. Following
yesterdays code this adds to the security where we make sure we store
the new transaction on disk before we (async) broadcast it to the world.
Making a restart later have the right information to continue without
problems.
This makes the process a bit more mature where we now take
care to only start the repeat payment sending when a wallet
has reached the chain-tip.
We also double check that the payment hasn't already been sent
in order to make extra sure we don't create duplicates (don't trust
that the OS won't kill us at an inconvenient time).
And last we patiently wait for the subsystem that monitors the
transaction broadcast status to give the all clear before shutting
down the application.
This avoids problems with needing to tap it twice to show and allows for
better reuse of our own components and makes sizing and positioning not
black magic.
When a repeat payment is detected to soon be eligable for sending, but
the user has not approve it yet, we show a notification from the
background process to entice the users to go and approve it.
This popup now also carries a 'disable' text which disables the repeat
payment, effectively shutting up this and further notifications.
The tricky part to make this work is that the notification is showing
while the application is (likely) not actually active.
This takes the strategy that the notification carries some extra
details. Among others a newly introduced unique id for a notification
itself, and also some text to show on actually processing the disable
action.
The processing just writes a file, to avoid complexity and side-effects.
The file will then be read on start up (either foreground of background)
to action on the lines in there. So the item will be disabled on first
load.
When the title and the 'current value' text are both long, typically
with a huge font selected, they now avoid overlapping by moving the
value label down.
The new ZXingCpp release is out, it is a major version (v3) and
it has broken source compatibility towards version 2.
The good news is that we can actually cut out quite a lot of
boring code which is now done in the upstream project.
But to actually benefit from better readability I think the best
approach is the "isolate the old" idea. So this copies the v2
compatible file to CameraController_zxing2.cpp QRCreator_zxing2.cpp
We'll have code duplication that way, but it will never be compiled
into the same binary and indeed we'll just be cleanly able to
delete the old support when that time comes.
tomFlowee