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.
Since the whole thing with Android going full screen with margins, the
combobox popup idea started showing a big flaw; Qt no longer clips the
window on top to the content area and thus your top and bottom item may
become impossible to select.
This replaces the combobox with a new component; a thumbler. Based on
the extremely basic one from QQComponents we introduce our own and use
that to select the year and month in the import screen.
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.
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 net log is useful without the quick deploy and indeed the quick deploy
will create problems on first install, so according to the law of fewest
surprises these features should not be combined "magically".
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.
This upgrades to the latest stable Qt (6.8.3) to my surprise the
translator patch still is required and they didn't fix that bug
for 2 bugfix releases now.
When running in the background on Android the user selected locale
information turns out to not be available. Which, to be honest, I won't
qualify as a bug, just unfortunate.
We now always store the data in our app config which makes the
notifications show a fiat price as expected.
The on boot complete android feature is tricky, it allows
very little in the actual callback and the strategy that works
best now is to make that callback schedule a single background
run, which will in turn plan the normal schedule.
Or insta-exit if the user had no wish to do background running.
This additionally also triggers on the my-package-replaced
signal in order to ensure that an upgrade doesn't disrupt the
background running schedule.
We re-introduced a checkbox to enable notifications.
We now have a second type of notification, one for incoming transactions
that may happen when the app isn't in the foreground.