Separate replaceable copies from original work
Imagine a Budapest lighting wholesaler planning an app for its sales team. A downloaded public product catalogue, an unfinished customer quotation and a language preference serve different purposes. The catalogue can be downloaded again. A quotation drafted only on the phone may contain work that exists nowhere else. A preference affects convenience.
Android’s data-layer guidance separates data sources and defines a source of truth. Turn that into a business inventory: for each item, record who owns it, where the authoritative record lives and whether another copy exists. Ask the developer to identify device-only work explicitly.
Give downloaded information a useful lifetime
For the wholesaler, agree which catalogue details staff need during visits and how much imagery the app should retain. Keeping every image may improve repeat browsing but uses more device storage. A smaller cache needs more downloading. Choose a limit and a removal order according to the sales task.
Define when product information must be refreshed and which decisions require current server information. For example, the team could permit viewing a downloaded lamp specification while requiring a current check before confirming availability. Write that boundary into the product brief. Removing an old product image must not also remove an unfinished quotation.
Make cleanup specific to the account and item
Firebase documents that Firestore’s persistent web cache is not automatically cleared between sessions. That web-specific example is a reason to verify each platform’s storage behaviour, rather than assume that ending a session erases saved information.
For the sales app, agree separately what sign-out does to public catalogue copies, account-specific customer details and unsent quotations. Before a destructive choice, explain what the salesperson would lose and what remains recoverable elsewhere. If unfinished work is retained, require it to remain tied to its original account. The next signed-in person must not see or send it.
Distinguish removing a device copy from deleting the business record on the server. Give those actions clear wording and demonstrate them with fictional accounts. A single Clear data label leaves too much room for different expectations.
Budget for changes to stored data
Android’s Room documentation warns that destructive migration fallback can delete stored table data when no migration path exists. Ask whether the proposed upgrade treats all local information as disposable or preserves original work.
Suppose the wholesaler adds a room-name field to quotation drafts. Agree how an older draft appears after the upgrade, including what happens when that field was never collected. Rebuilding downloaded catalogue data may be acceptable; silently losing the salesperson’s draft is a different business decision. Have the team demonstrate both outcomes using a previous-version test draft.
Approve a short storage agreement
Keep these decisions beside the feature brief, with an owner for future changes. The agreement should explain what survives each event before the team chooses implementation details.
- List downloaded copies, original drafts and preferences separately.
- Record ownership, the authoritative record and the available recovery path.
- Set download limits, freshness rules and the order of cache removal.
- Rehearse sign-out and account switching with unfinished work.
- Check an upgrade with both replaceable data and an older device-only draft.