bleedingdeacons / hand / 34370079187
93%

DEFAULT BRANCH: main
Ran
Jobs 1
Files 18
Run time 1min
Badge
Embed ▾
README BADGES
x

If you need to use a raster PNG badge, change the '.svg' to '.png' in the link

Markdown

Textile

RDoc

HTML

Rst
coverage: 92.943% (+0.2%) from 92.769%
34370079187

push

github

web-flow 
feat: say whether push is available and enabled, on the settings screen (#56)

The settings screen carried one line that read either "Push" or
"Polling". It said the same thing for a Windows head that has never had
push and for a responder's own phone whose notifications had been
switched off in error. Those two have nothing in common. One is a
documented poll-only handset that still rings; the other is a handset on
the rota quietly swallowing every alert, and nothing anywhere said so.

It is now four states, because the two halves of "push works" fail for
different reasons and are fixed in different places -- the platform has
to carry a transport at all, and the phone's owner has to have left
notifications on for Hand:

    green   working
    amber   no registration, but the poll is still carrying it
    red     silenced in the phone's own settings
    grey    no transport on this head

The colour is the indicator. Amber rather than red for an unregistered
handset because the poll covers it and the responder will still be
alerted; red is kept for the one state where an alert can arrive and the
screen shows nothing.

WHERE THE ANSWERS COME FROM. The registration half is Reach's own
answer, read from the session Reach returned, not from whether this side
happens to hold an FCM token. Those disagree in exactly the case worth
catching: a handset with a perfectly good token that the server was
never told about, which looks push-capable from the inside and is never
pushed to.

The permission half is a new INotificationPermission, which reads and
never asks. PlatformAlertPresenter still owns the asking, at the moment
it needs one; a settings page that raised a permission sheet on arrival
would be one nobody opens twice. It answers false when it cannot tell,
because an indicator that under-promises gets checked and one that
over-promises is how a handset goes quiet.

Android reads AreNotificationsEnabled rather than checking
POST_NOTIFICATIONS. They are not... (continued)

1396 of 1502 relevant lines covered (92.94%)

1261.53 hits per line

Jobs
ID Job ID Ran Files Coverage
1 34370079187.1 18
92.94
GitHub Action Run
Source Files on build 34370079187