Purpose of chapter: to introduce Incidents log, that logs warnings triggered by conditions occurring.
Local TOC
Ref | Opener | Tapping | Back button *) |
---|---|---|---|
- | The Track mainpage |
*) A Track zone suffix is appended, e.g.
Its content is based on what was logged since App installation or since last
action.After some (constructed) incidents did occur, the log opens like:
Above, a !Not allowed to Send You Notifications'! appears in the first entry.
When the very first incident occurs in the foreground, a Toast message appears at the top, and - below that - a standard iOS dialog requests allowance to 'Send You Notifications':
If the very first incident occurs in the background, the request looks like:
In this example, allowance was given - *after* the incidence was logged.
Therefore, the !Not allowed to Send You Notifications'! doesn't appear in later log entries.
When the next incident occurs, and the App is in the background, a standard iOS notification is seen:
A badge appears with the number one. Each time an incident occurs, this number is increased, provided 'Send You Notifications' is allowed.
Also, an alarm sound (a dual beep) is played.
If an incident occurs when the App is in the foreground, the badge number is also increased, and a Toast message appears instead of the iOS notification:
The (always enabled) navigation bar button
opens the:Whenever an incident is logged, the
icon in the Track mainpage navigation bar turns red:If Requesting allowance to 'Send You Notifications' has been confirmed, the badge number at the App icon is also increased.
The Incidents log Options Menu action: Reset incidents log action makes the red color disappear.
The (always enabled) navigation bar button
opens the:Tapping its Incidents log Help pages.
action opens theTapping
confirms with:If you experience inexplicable incidents and need help, use this action and the contact link at our frontpage.
This action requires your acceptance:
- whereafter the Incideints log file is removed:
- the badge number is also reset, so the badge disappears:
Also the The nav.bar 'i' icon turns red syndrome is cancelled, i.e. the red color disappears.
The alarm sound repeats until the 'Anchor' activity is ended.
For more info, see Anchor.
The typical problem is related to communication - i.e. bad or missing network connection.
The Current weather data API at 'openweathermap.org' which is the target of Weatherfetch requests, guarantees an uptime of 95% - so here is another source of incidents.
The Weatherfetch feature continues its regular requests, independently of such incidents. It only stops when tracking ends, or the TrackSet: Weatherfetch freq. Picker is set to 'None'.
Checkout TrackSet: AutoEnd timetrigger Picker.
If you don't move during an extended period of time (approximately 15-20 minutes) and the App is in the background, it will sometimes end the track for you - and the last plot will be assigned an event with the text Pause plot.
Doesn't apply to activity type 'Anchor': here the App is never allowed to pause (for obvious reasons).
However, we find pause behaviour unpredictable. Investigating this, we have queried Apple for more info, who replies:
"The system will decide, based on many factors, almost all of them outside of the Apps control, whether it is worthwhile to stop location updates for the App or not. The logic to make this decision, determining whether movement has stopped can also change from iOS version to version. There is no guarantee that the updates are going to be paused in the same fashion across all devices and iOS versions, even under the same conditions".
Therefore manually ending of tracking is recommended.
Sailor Logbook App manual - © Copyright 2018 CoaSoft LLC Denmark