ONEDiary: A Photo in a Diary Is a Permission That Expires

A diary entry from eleven months earlier, with a caption describing a photo, and a grey placeholder where the photo should be. The text was intact. The image was gone.

We had done the efficient thing, and for a photo in a diary the efficient thing is wrong.

Referencing versus copying

When a user picks an image on Android, you get a URI — a reference to something the system knows about. You can display it, and storing the URI string with the entry is obviously better than duplicating a several-megabyte file that already exists on the device.

The reference is not durable, and it fails in more ways than you would guess.

A grant is not permanent by default. A URI handed to you by a picker comes with permission to read it, and that permission does not automatically survive a reboot. takePersistableUriPermission extends it, which we were calling. It is necessary and it is not sufficient.

There is a limit on how many you can hold. Persistable grants are a finite per-app resource. An app that takes one per photo will, over years of daily entries, run out. When it does, older grants are released, and the oldest entries lose their photos first — which is precisely the pattern we were seeing and initially could not explain.

The underlying file can go away. The user tidies their gallery. A cloud photo service moves things around. An SD card is removed. The reference remains valid-looking and points at nothing.

A backup and restore does not carry the grant. Restore an app to a new device and the URIs come back while the permissions do not.

Every one of these ends the same way: an entry from a while ago with a hole in it.

What we do now

ONEDiary copies attached images into its own storage. The entry references a file the app owns and manages.

The cost is real. A diary with a photo a day uses meaningfully more space than one with a list of URIs, and we now have to think about storage growth, cleanup of orphaned files, and what happens when the device is nearly full. Those are all problems we would rather have than the alternative, which is a diary that quietly rots.

Copying also makes the entry self-contained, which matters for the same reason autosave matters here: a diary entry is not reproducible. If a photo from a Tuesday in March is gone, there is no second Tuesday.

We reduce the size cost by storing a resized copy rather than the original where the original is very large. A twelve-megapixel photograph of a café table does not need to be twelve megapixels to serve as a memory cue. Where the image is the point rather than the cue, the full version is kept.

On newer Android versions, the system photo picker helps considerably. It gives access to exactly the images the user chose without the app holding a broad media permission at all, which is better for everyone — we do not want read access to someone's entire photo library to attach one picture to a diary entry.

Location, and how much of it to keep

Places make entries findable later. A month of text entries is a wall; a month with places attached is browsable. So location is genuinely useful in a diary and it is also the most sensitive thing the app touches.

The choices we made:

Location is per entry and opt-in each time. There is no background tracking and no automatic tagging. The app never learns where you were on a day you did not tell it.

We store a place, not a trace. A café, a park, a city — resolved to something with a name and coordinates, at the granularity of a place rather than a position. A diary does not need six decimal places, and a stored point that precise is a home address.

Photo location is not automatically imported. Photographs carry coordinates in their metadata, and silently reading them would mean entries acquiring locations the user never chose to record. If you want the photo's location, you say so.

Metadata is stripped on export and sharing. If an entry leaves the app, its images go without their embedded location and camera data. Sharing a photo of your kitchen should not share your address.

The entry model

Beyond text and photos, an entry can carry a mood, tags, and a template. These exist because a diary you cannot search is a diary you do not re-read, and each of them is a different retrieval path.

Dates are the primary one and the calendar view is what most people use. Search covers text. Tags cover recurring subjects. Mood covers the pattern you cannot find by searching, because you did not use the same words for it. The map view covers the trip you remember by where it was rather than when.

The point of having several is that memory is not indexed one way. People look for "the day at that place," "the week I was anxious," "when did I last see them," and each of those needs a different route in.

A first entry

Do not try to build a system. Write something short and add structure later if the habit takes.

A few lines about the day. Plain. "Worked from home, finished the report, walked after dinner."

One photo, if there is one worth having. Chosen as a cue, not as a picture. A receipt, a street corner, a meal, the sky. Ordinary images age better than good ones.

A place, only if it matters. Where something happened, not where you were.

A mood, if you want the pattern later. This is the field most people skip and most appreciate a year in, because it is the only one that finds days you would not otherwise search for.

Templates are worth reaching for on the days when you do not know what to write: what happened, how it felt, what to remember, what tomorrow needs. One sentence each is enough. Use them as a door rather than a form to fill in, and change the questions when they go stale.

What a diary should not become

The temptation with a structured entry model is to fill in every field every day, and that is how a five-minute habit turns into a chore that lasts a fortnight.

Most entries need text and nothing else. The photo is for days there is one. The location is for days it matters. The mood is optional and useful in aggregate rather than individually. An entry with one honest sentence is a better entry than one with every field populated and nothing said.

Still unsolved

Storage growth is the open problem. A diary with a photo a day, kept for years, becomes large, and we do not currently give the user good tools for understanding or managing that beyond the system's storage screen. Showing which months are heaviest, and offering to shrink older images while keeping them, is the shape of the answer and it is not built.