Building for One, Part one: a calm iPad display for someone living with dementia built a calm daily tablet display for someone in the early stages of dementia, and Building for One, Part seven: structure without a regime was about what it is doing in the house now that it is in daily use. This part is about the first thing it cannot do, and the decision about how it will.
The decision is where the day lives once more than one person needs to touch it. We were torn for a while between the two devices talking to each other and a server. We chose the server, and this is the argument, written down before the code so that it can be checked against what actually gets built.
TL;DR – The iPad does not need a server. The family does. Peer to peer solves the data problem, which we did not have, and leaves the people problem, which we do.
Contents
- The feature that is missing
- What peer to peer promised
- Where the peers actually are
- The problem is the people, not the data
- Why the server is Joomla
- The shape of it
- What it removes from the plan
- What her display does not do
- What we still have to get right
- Getting it, and telling us where we went wrong
The feature that is missing
Everything Daysome does today happens on one tablet. The routine, the meal lists, the note of the day, and the week’s menus all live on the iPad, and they are edited there, behind five taps and a PIN, by whoever is standing in the kitchen.
That is fine for the carer who is in the house. It is no use at all to the daughter who is not. The most common request since it shipped, and the one we would have made ourselves, is to change tonight’s tea, or post “Sarah is coming this afternoon”, from a phone that is somewhere else. A change stranded on one iPad helps nobody who is not standing next to it, which is the same argument that kept the tick-and-cross record off the display in the first place.
So the thing that forces a backend is not the data. The routine is a few dozen lines and it has lived happily on the iPad for a month. What forces it is the people: a daughter on her own phone, a carer with an account of their own, somebody taking over when somebody else cannot carry on.
What peer to peer promised
The appeal of the two devices simply talking to each other is real, and it is worth stating plainly before arguing against it.
Nothing about the household would be held by us. There would be no hosting bill, no server to back up, and no data controller role for a company that would rather not hold anybody’s routine. And it would keep working if we stopped: a product for a period of somebody’s life that is inherently finite should not depend on a company being around for the whole of it.
For a small company with a strong preference for storing as little as possible, that is a serious list. It is the reason this was a genuine decision rather than a foregone one.
Where the peers actually are
The argument fell apart on geography. The iPad is on home broadband, behind the router the phone company supplied. The daughter’s phone is on a mobile network, in another town. Neither can reach the other directly, and neither can be reached.
Apple’s peer-to-peer framework, the one that lets two iPads find each other in the same room, is local: Wi-Fi, Bluetooth, and nothing beyond the building. Getting two devices to find each other across two home networks needs a rendezvous point that both can reach, and usually a relay for the traffic as well. That rendezvous point is a server. Somebody runs it, and it has terms.
So the realistic versions of “peer to peer” for this product are the ones where somebody else’s server does the introducing. Apple’s iCloud sharing would do it, and it is Apple only, which rules out the £200 Fire tablet that part four made a real second target, and it ties the household to one Apple ID, which is precisely the failure the subscription design exists to avoid. Google’s Firebase would do it, and our release audit already fails the build if a Play Services dependency appears, because Fire OS does not have them.
Peer to peer here does not mean no server. It means a server we do not own, on terms we did not set, from the one vendor whose devices we happen to have chosen not to depend on.
The problem is the people, not the data
Set the networking aside and the case for a server is still made, because a surprising number of things need somewhere to live that is not either device.
Who is allowed in. Accounts, invitations, and revocation. A carer leaving, or a sibling taking over from a sibling, is a change to who is allowed to edit the day rather than a change to the day. That has to be held somewhere neither of them controls.
The entitlement. The subscription, when it comes, belongs to the household rather than the buyer, so that a bereavement or a change of carer does not strand a household inside somebody else’s Apple ID. Apple reports renewals, cancellations, and refunds to an address of your choosing, while nobody has the app open. That address has to be a server.
A clock everybody agrees on. Two people can edit the same item within a minute of each other: the daughter from her phone, the carer on the iPad. The rule is that the later write wins, per item, and “later” needs a clock that neither phone owns. Two devices arguing about what time it is, with no referee, is exactly the bug nobody can debug at eight in the morning.
The quiet signal. The passive question the deleted Done button gave way to, which is whether the iPad is awake and whether anybody has touched it today, is an answer for the daughter’s phone. It has to travel, and it has to be there when she looks, not only when the iPad happens to be reachable.
And there is the honest commercial point. The paid tier was defined from the beginning as everything that needs the server, because the server is the thing that costs money to run. Take the server away and there is nothing honest left to charge for, which sounds like a saving and is actually the product losing the one line it could explain in a sentence: the app is free, and the subscription connects the family.
Why the server is Joomla
Having decided on a server, the choice of what to run on it was short, because we have done this before.
The Porsche owners’ club platform we run is a Flutter app backed by a Joomla REST API. Articles, events, and the rest come down through Joomla’s web services layer, with an API token injected at build time from CI rather than kept in the source tree, and conditional requests using ETags so that a client which already has the current version is told so in a few bytes rather than sent the whole thing again. It has been in production for long enough to have opinions about, and the opinion is that it works.
Daysome’s own site is already Joomla, professionally hosted in the UK. That is the site the store listings point at, the one the tester form lives on, and the one a daughter will already have visited before she installs anything. Putting the household behind a login on that same site is the least surprising place it could possibly be.
What Joomla gives without being asked is the part that would otherwise be months of unglamorous work: user accounts, password reset, multi-factor authentication, email, an administrator’s view for answering support questions, and the privacy tooling that lets a person ask for everything held about them or ask for it to be deleted. Multizone is a registered data controller with the ICO, and being able to honour those requests with a built-in feature rather than a hand-written script is most of what makes holding any data at all defensible.
The house rule is vanilla Joomla: a custom component built the way Joomla’s own are, no forks, and no clever bending of articles and custom fields into a shape they were never meant to hold. A routine is not an article. It gets its own tables, its own views, and its own endpoints, and it upgrades with the platform because it does not fight it.
The shape of it
Most of this was decided before the first commit and written into the project requirements documentation, which is where it will be checked against the code. In outline:
| Piece | Decision | Why |
|---|---|---|
| Who signs in | Carers, as Joomla users | The iPad never does. It is not a person and it must not have a password |
| How the iPad joins | Pairs once with a short code, holds a revocable token scoped to one household | Revoking a device is one row, and a lost iPad cannot reach any other family |
| How changes travel | The iPad polls, every minute or two, with an ETag | A day changes a handful of times. Push adds a permission, a banner over her display, and a dependency, and buys seconds |
| Offline | The display renders a local snapshot always; edits made on the iPad queue until the network is back | Rule three. A dropped connection must never blank the screen or lose a change |
| Two writers | Per item, last write wins, on the server’s clock | Nothing here needs anything cleverer, and anything cleverer is a liability |
| What is stored | First names and times. No surname, no date of birth, no diagnosis, no drug names | Out of special-category territory by construction. The field is not added |
And none of it is Daysome-specific. The extension is being built as a general backend for mobile apps: registered apps, groups (a household is a group), members, devices and their pairings, items with ETags, and entitlements, licensed and limited the same way as the other Multizone extensions. Nothing in its tables or its API knows what a meal is. The app’s identifier is a configuration parameter, the site’s name and addresses come from Joomla’s own settings, and Daysome’s vocabulary lives in the app and in the pages that edit it. We will be building other apps, and the argument that made the Flutter chassis worth extracting applies just as well here: the cost of the next app’s backend should be close to nothing, and an extension that general is one we may well end up offering to other people.
The one Flutter change is at a seam that was left for it. The thing that holds the routine on the iPad becomes a repository that reads the local snapshot and writes through, and nothing above it in the app knows the difference. That was the point of leaving the seam.
What it removes from the plan
The largest consequence of choosing the website is not something it adds. It is something it takes off the list.
The plan had a second app in it: a carer app, on a phone, for exactly the editing described above. It does not exist yet. If editing lives on daysome.org, then on the first day the backend works a daughter can sign in from her phone’s browser, see the day, change tonight’s tea, and post a note, with no second app built, submitted, reviewed, or installed. Quick viewing and quick editing are the whole of the win, and a web page does both.
The native carer app can come later, as one more client of the same API, when there is something it would do that a browser cannot: the home screen widget, most likely, and notifications. That is the same instinct that put a one-screen placeholder through both stores before the real app existed. Prove the thing with the smallest client that can, then build the bigger one against something that already works.
What her display does not do
None of this reaches her screen, and that is by design rather than by omission.
The display keeps rendering from its local copy whatever the server is doing, and if the household’s broadband is out for a week the only thing that changes is that the daughter’s edits arrive when it comes back. A lapsed subscription changes nothing on the iPad: the display keeps showing the day indefinitely, local editing keeps working, and nothing on her screen ever mentions money, because the rule that keeps “missed” off it keeps “upgrade” off it too.
The iPad never authenticates as a person, so there is no password on it to forget and no account on it to be locked out of. And the household lives behind a login on a website, which is a thing somebody goes looking for rather than a thing she can wander into. The rule from part five, that nothing she can reach by accident on her own device may label her, is not touched by any of this.
What we still have to get right
Writing the argument down is the easy half. Some of what remains is worth naming now so that it is not discovered later.
A site holding families’ routines is a different thing from a brochure site. The data is deliberately thin, but a login that opens somebody’s day is still a login worth attacking, and the security posture, the backups, and the update cadence all have to be those of a service rather than a web page.
The first pairing has to decide whose copy wins. A household that has used the iPad for a month has a routine on it that nobody has ever typed into a website. The iPad’s copy is the true one and the server must take it, not the other way round. Getting that backwards, once, would empty somebody’s day.
The lag has to be short enough not to be noticed and long enough not to matter. A minute or two between an edit on the website and its appearance on the iPad is fine for tea. It is less fine for a note that says somebody is on their way. We think polling is still right, and we will find out on real glass rather than by argument.
And the poll must not become a heartbeat that somebody worries about. The quiet signal, whether the iPad is awake and has been touched, is genuinely useful to a daughter and is also the first step towards monitoring, which this product is not. What is shown on her phone, and in what words, is a decision for its own article.
Getting it, and telling us where we went wrong
It is out on all three stores now. The App Store, Google Play, and the Amazon Appstore, and daysome.org carries the links to each. It installs like any other app, it is free, and you can stop whenever you like. Everything in this part is still ahead of us: the app you can install today works on one tablet, and edits are made on it.
We would still like to hear from you, and that matters to us more than an install does. If you support someone in the early stages of dementia who is still living independently, or you work in dementia care and would be willing to tell us plainly where we have got it wrong, that is the thing we cannot get any other way. If you would be one of the first to try editing the day from your own phone when it is ready, say so at daysome.org/testers.html.
Plainly, so nobody is misled: Daysome is an app centred on a display that shows the day. It is not a medical device, not a monitoring system, and not a substitute for anybody. It does not track whether medication has been taken, and it never will.
