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.
We remove the block notification feature, as that was nice but useless.
This instead introduces a way for a transaction we created to be marked
as needing monitoring and when a block comes in we create a notification
explaining it has been mined.
After setting, check if it was approved by the user, and if not
unset the checkbox again.
Bugfix:
On some Android implementations, setting this value opens a screen
even if the value is already set, while on many others that is a no-op
as you'd expect.
So for those phones we check first before we set.
This removes the Qt middle-man for requesting the camera permissions
and we just code this in our own Java class.
This solves the issue we observed where after the approval of the
user we didn't actually manage to start the camera on some phones.
This avoids using the Qt intermediate and just directly uses
the Android side, including some extra checks like "screen off".
Rework the various methods in a class.
This makes the various android support features be less hacky and instead
are based on a single class with Qt signals and slots.
We also remove the ping feature for checking online state, since Android
seems to throw a random exception (calling virtual method on null pointer
java.lang.String.size) somewhere in the OS libs when you call it the
second time.
This also implements the AIRPLANE_MODE_CHANGED listener to instantly turn
off internet the moment the user enables flight mode.
This is the only useful notification type we have today,
but at least it allows the user to explicitly go and request
notifications from the Android OS.
On Android this enables the application to run just a simple
quick sync and then exit the app on regular intervals.
The main benefit is that when the user doesn't run the app very
often they will avoid having a long sync time.
Add logic to notice that the device is offline and notify the
user of this fact on screen.
Repeat checking so we can notify the user that network is back.
This shows in the UI (of the mobile form factor) that the device
is offline and we avoid starting the p2p layer until network
is detected to be there again.
This takes the NotificationManager and splits it into multiple
compile units based on the backend that is available.
The 'dbus' was the only one available so far (which serves
kde/gnome desktops) and this is moved to its own file.
This adds android support as well, but so far only for block
notifications (when a new block is mined).
This reverts a broken Qt patch wrt translation selection. See QTBUG-131894
This removes various Qt features from the build that we don't need
in order to keep the library size down.
The qtdeclarative module went from 4285 ninja tasks to 2387, or for the
android buld from 4117 to 2251.
On Android an app can ship with (static) shortcuts. We use this feature
to allow the user to create a new icon which still starts Flowee Pay,
but it instantly opens the payment screen on the QR scanner.
The idea of using Flowee Pay to open a payment screen, or a sweep
screen, was so far married to the executable lifetime due to it being
passed as a command line argument.
This does not reflect reality, on neither desktop nor on mobile as
multi-tasking is possible and we should allow that.
As a result the new object "Intent" has been introduced with the
usecase specific properties. Setting those properties at any time
during the lifetime of the app now pushes the correct page to the
stack on mobile. Desktop is in need of more love in this department.
This allows a user to click on a link in a browser with the bch-wif
scheme and we'll handle that with a sweep page on startup.
To avoid this being just-another-special case we introduce a new
module (read: plugin) concept that is a Start-screen type.
The idea is that we can have a generic handling of this type in
various parts of the app without it being specifically about the
wif handling.
Notice that it doesn't matter if the user has the module enabled,
which just operates the display of the menu option to start it manually.
tomFlowee