This cleans up and re-does the 'wallets' page, as it is named in the
menu.
This adds some features and inlines some not reused content but mostlie
redoes the UX to something more satisfying.
The Mnemonic object requires dictionaries that the lib doesn't ship,
but Pay does. So we need a different "constructor" to set those dicts
for the users of the Mnemonic class.
Now we make sure that setEnabled and loadSettings are always called for
each module info class, even if the save file doesn't have the relevant
properties.
This makes it easier to tie into the setup of the app.
The Wallet object used to have a guarenteed lifetime longer than the App
singleton, but then we started allowing people to delete their wallet
(argh!).
Also "external" modules, especially living outside of the main tree,
would be much more stable if they can avoid using raw pointers for core
concepts like the Wallet.
This adds a setting in the mobile client where the user to select to
prefer to start inputting the BCH value on payments (that require manual
input of price).
The default is to start with the user selected fiat value.
We notice a lack of DNS lookup and instead of trying all, we give up
quickly and realize that the most likely reason is that the Internet is
missing.
This avoids giving a punishment to all discovered peers.
Additionally, we recover better and show the password field in such
cases.
And on Mobile this adds a menu option to enable the password field for
better discoverability.
When the singleton shuts down, this now gives the platform specific code
an opportunity to do something too.
This avoids doing work after we shut down the application.
Android doesn't have a direct equivalent of our sections, and the tag is
really meant to be the same for the entire application.
As such this simply prefixes the section to our log message. Not ideal,
but at least the information is there.
Tie the Android logging system (and transport) into the Flowee logging
system, allowing all C++ calls to end up in Androids LogCat.
This makes remote debugging even simpler by using their multiple
transports like wifi and usb and tools.
This adds things like the notification being unique, avoiding many duplicates.
We add a title and the ability to click on the notification to open Flowee Pay.
Repeat payments are handled in the background process and issues and
indeed successes need to be shared to the user via notifications.
We now have notifications for:
∙ successfully sending a repeat payment
∙ when a payment is due soon, but not approved.
∙ when a payment is due soon, but not enough funds are in wallet.
tomFlowee