What the phone keeps

Status: Accepted · Audience: Operator · Area: N — Companion

---

Purpose

The app forgets everything a stack told it when it closes. Opening it again is a spinner, a stack that is out of reach says only that it is out of reach, and a choice the operator makes — how soon to ask for the passcode again, which stack comes first — has nowhere to stay.

This page is what the phone keeps between launches, and the rules for keeping it: the last reading of each kind per stack, shown for what it is; the operator’s own settings; and a note of what they have already seen, so that the app can say what is new. How it is kept, and why that way, is ADR-0035.

Behaviour

Opening shows what the phone last knew

A screen that has a kept reading draws it at once, with when it was read, and then asks the stack (N1-R24, N1-R25, N1-R9). The kept reading is replaced when the fresh one arrives. Until then, nothing that acts on the stack can be used: a restart, taking an update or agreeing to anything is shown, disabled, with the reading’s age beside it. A stack that cannot be reached shows what it last said and when, beside the reason it cannot be reached now.

Four kinds of reading are kept per stack: health, what runs, updates and household. A repair offer is not kept: it is something the operator agrees to, and an agreement is only ever given against a fresh offer (N13-R7).

What is kept stays on the phone, sealed

Everything kept is encrypted with a key the phone’s secure storage holds, and can be read only while the phone is unlocked. Nothing kept is ever a password, a sign-in or pairing material (N1-R23), an action the stack did not receive (N1-R41) or the confirmation of one (N1-R24). A phone with no secure storage keeps nothing and says so; a phone whose key has gone — restored onto another device, its keychain reset — clears what it had kept, keeps its pairings and says once that it did.

Artwork is held, never kept

Posters and backdrops are drawn from memory and gone when the app closes. They come from the core’s own API, which serves a held title’s pictures and the poster of a title a member’s search found, or from the location the core states for a title through the media server’s guarded front door. Either way the request is the app’s own, on the session’s credential, over a connection pinned as that request is — to the stack for the core’s API, to the door for the door — and never to an address the app put together (D11). A title the core has no artwork for is drawn as its lettered poster, so a cold start draws immediately and the art arrives as it loads.

How long, and clearing it

The operator chooses how long readings are kept: any whole number of days from 1 to 365, or until the stack is removed from the phone. It is 30 days until they choose. Readings older than that are deleted when the app opens and when the setting changes. Removing a stack from the phone removes everything kept about it. Clear saved data removes every reading, setting and marker the phone keeps, and leaves every stack paired and signed in.

Settings the phone remembers

App settings, for the whole phone: when to ask for the passcode again (N4-R19), how long readings are kept, the order of the stacks, and clearing saved data. It is also where a phone with no secure storage says that it keeps nothing.

A stack’s settings, one per stack: which of the kinds of notification that stack raises may reach the phone, within the phone’s own notification settings, and which kinds are marked as new. The kinds of notification are the core’s (N4-R11): a closed list the contract publishes, of which each stack says the ones it raises (ARCH-R279, ARCH-R280), so the app offers a stack’s kinds and no others.

The app also remembers where the operator was — which stack and which tab — and opens there, after the lock.

What is new

For each stack, the phone notes the newest update, request and problem the operator has seen. Anything newer, of a kind the operator wants marked, is new. An update is newer by its place in the stack’s record, a request by its number, and a problem by when it began (C1-R17), which are the orders the stack itself vouches for (ARCH-R140). The tab it belongs to carries a mark, and What’s new lists every new item across the stacks, filtered by kind and by stack. Opening an item marks it as seen; Mark all seen clears the list. A mark is announced to a screen reader and never shown by colour alone.

States

Edge cases

• The first reading of a stack. Nothing has been seen yet, so nothing is new: the first reading records what it holds as seen, and only what arrives after it is marked.
• A kind switched off in a stack’s settings. Its marks disappear at once; switched on again, it starts from what is current, not from everything since it was off.
• The stack last used has been removed. The app opens on the first stack in the operator’s order, or on first run if none is left (N1-R35).
• A reading kept by an older version of the app. Its shape is not this build’s, so it is discarded and read again; a setting from an older version is carried over (N1-R32, N1-R33).
• The lifetime shortened below the age of what is kept. Everything older is deleted at once, not at the next launch.
• A stack re-paired after moving address. It is the same stack (N1-R22), and what was kept for it stays.

Requirements

Notes

Where each thing is kept is a decision about the app, not about behaviour. Which module keeps what, the sealing port and the rules that test it are in ADR-0035; the companion’s architecture document carries each rule beside its test.

Where these screens sit in the app — the menu that reaches What’s new, App settings and a stack’s settings — is the navigation page, not this one.

Related

• ADR-0035 — how it is kept
• N1 — retained readings, shapes and pairings
• N4 — secure storage, notifications and the lock
• N13 — why an agreement is never kept
• N2, N3 — the screens whose readings are kept
• G3 — marks a screen reader can hear