With the sync-state label being removed the whole UI used to jump, we
solved that by pushing in the labels a little based on the assumption
that they won't be there very long.
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.
For Page inhering screens (BroadcastFeedback/UnlockApplication)
This changes the Page.hideHeader to now act like a full screen,
removing all insets from the Page object when enabled.
The insets are then re-added on the child pages, but
without affecting the background fields, so they cover the insets.
UnlockApplication is a simply full screen widget, we added the
insets to it too.
The checkFinished slot is not executed based on a timer instead of based
on progress.
This avoids problems when the downloads were all done but we were still
waiting for something. Now we notice that all is done since we keep
calling the slot because it is on a timer.
The default changed there and the application at full screen is actually
fully full screen. Meaning we need to make space for the statusbar and
menu.
This code fetches the relevant insets from Android and the GUI honers
them in a couple of choice widgets.
Should we actively be broadcasting a new transaction this now waits for
it to reach the success (or reject) phase before we exit the background
runner.
This fixes a bunch of little issues and possible issues, including the
ability to swipe horizontal the main transaction view before we have a
second tab to scroll to.
This also re-enables the adding of the action that turns a payment into
a repeat payment. Currently our only way to create them.
A bit hidden, but we expect that in future other methods will become
available that make more sense.
The UI can now again click on the repeat payment and show / edit it.
The actual objects are now created elsewhere and the savedPaymentHandler
no longer owns them, vastly simplifying that class.
On Android 'startNet' is called in a more complex way, based on the presence
of network interfaces.
On Android we also don't supply any command line arguments to avoid going
online.
So this is called in the FloweePay_android.cpp file, and it is the same for
foreground and background apps.
For Linux and other platforms the Periodic thus needs to call it manually.
tomFlowee