连接丢失不应总是意味着工作丢失。离线能力可以帮助人在不可靠的网络中完成任务，也可以在符合产品目标时，将记录保留在自己的设备上。
从必须继续的任务开始
“可离线使用”过于宽泛，无法成为实用需求。明确哪些具体操作必须保持可用：开始记录、编辑笔记、查看已保存的日程或导出信息。决定哪些操作可以等到恢复连接后再做。
界面应使这些边界容易理解。用户需要知道操作是已保存在本地、已发送至其他系统，还是仍需处理。不要让他们看着加载动画猜测。
决定数据应归属何处
本地存储改变了归属与恢复方面的问题。有没有备份？设备丢失或更换时怎么办？用户能否以可在其他地方使用的格式导出数据？删除应用后，还会留下哪些副本？
这些决策应与产品的实际行为和隐私声明一致。“离线”并不自动意味着每项功能都不使用网络。外部地图、地理编码、支持消息或用户选择的导出可能产生独立的数据流。
规划冲突后的处理方式
如果记录之后与服务器同步，两个设备可能编辑过同一信息。产品需要规则来决定接受哪个版本，以及在出现意外结果后如何清晰地恢复。
重复、延迟与中断的传输同样值得关注。重复点击不应悄悄产生重复的财务或运营操作。具体方案取决于产品的数据模型及相关系统。
解释权限选择
定位功能应服务于具体操作，并在权限被拒绝时表现可预期。通知应帮助用户理解正在进行的活动。用户不必了解 Android 内部机制，也应明白每项选择会改变什么。
在设计中包含权限被拒绝的路径。如果操作仍可手动完成，应让这条路径容易找到。如果功能无法工作，应在相关时刻说明限制。
验证状态转换
不要只检查关闭网络后的启动。检查操作中途失去连接、延迟后恢复连接，或应用不再可见时连接发生变化的任务。考虑应用重启、导出中断，以及用户纠正早前记录的情况。
检查应围绕核心路径及其风险展开。构建成功是关于编译的有用证据；设备行为需要自己的证据。