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.
This avoids people approving when they intent do just open the details
screen. User tests showed that the confusion of hitting the checkbox
when the details screen was aimed for was masking the actual action
taken, making it dangerous to leave it larger.
The crazy animation caused it to show a little at the top on hide, so
now we move it further off screen to avoid that.
Additionally this removes the semicolons from these pages where
applicable. It's cleaner without them then sometimes there sometimes not
there.
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.
tomFlowee