Poppy field guide · 05
Android capture and delivery
The SharetoBoard operating model: preserve user intent locally, then deliver to a selected Poppy board with visible state.
Ideas, selected text, URLs, and shared material that appear on a phone before the user is ready to open a research workspace.
A fast share sheet gives the impression of capture while connectivity, process death, or a changed integration loses the item.
User moment
Capture has to fit inside the interruption that created it.
The Android share menu and selected-text action matter because the user is already somewhere else. Opening a separate app, finding the source again, choosing a board, and reconstructing intent imposes enough friction that valuable material disappears. The capture surface should ask only for information needed to preserve and route the item.
Destination choice is part of intent. A default board can reduce taps, but the user should be able to see and change it before delivery. Hidden routing creates clean analytics and dirty research spaces.
- Preserve the original shared text, URL, MIME type, and source metadata available to the app.
- Show the selected destination rather than treating it as background configuration.
- Let the user add a short note when the reason for capture is not obvious from the source.
Offline first
Save first. Acknowledge second. Deliver third.
A local Room record should exist before the interface tells the user the capture is safe. WorkManager can then schedule delivery under appropriate conditions and survive application restarts. This sequence makes the device a durable edge in the workflow instead of a thin remote-control surface.
Visible state is essential: queued, sending, delivered, failed, or needs review. A green check that only means ‘request started’ trains the user to trust a system that has not completed its obligation.
- Test airplane mode, process termination, device restart, and intermittent connectivity.
- Use stable operation IDs and avoid destructive mutation of the original capture.
- Give failed and uncertain items a user-controlled retry or review action.
Integration layer
Board delivery should be an adapter, not the data model.
The local capture model should not depend on one screen layout or remote selector. Map the durable item into a Poppy delivery adapter at the boundary. If the integration changes, queued material remains intelligible and another route can be introduced without rewriting capture history.
The adapter also owns validation. It should know whether the destination still exists, whether the payload is supported, and what completion evidence is available. When certainty is impossible, it should return an uncertain state instead of fabricating success.
- Version the adapter behavior alongside releases.
- Keep a manual export or copy path for important material.
- Measure delivery outcomes and time-to-recovery, not only share-sheet opens.
Release proof
The signed build is the product—not the emulator demonstration.
Verify share intents, selected-text capture, widgets, background work, encrypted settings, and delivery on the same signed artifact intended for testers or distribution. Debug builds can hide signing, configuration, optimization, and permission differences.
Privacy and store disclosures should follow the shipped data path. Document what leaves the device, which service receives it, what configuration is stored locally, and how a user can remove queued or historical items. Those claims should be checked whenever the integration changes.
Continue the field guide