接続が失われても、必ずしも仕事まで失われる必要はありません。オフライン動作は、不安定なネットワークでも作業を完了する助けとなります。製品の目的に合うなら、自分の端末に記録を保持することにも役立ちます。
続けなければならない作業から考える
「オフラインで動く」だけでは広すぎて、有用な要件になりません。記録の開始、メモの編集、保存済み予定の閲覧、情報の書き出しなど、引き続き使えるべき具体的な操作を特定します。接続の回復まで待てるものも決めます。
画面は、その境界を理解できるようにする必要があります。操作が端末内に保存されたのか、別のシステムへ送信されたのか、まだ対応が必要なのかが分かるべきです。読み込み表示から推測させないようにします。
データをどこに置くかを決める
端末内への保存は、帰属と復旧の課題を変えます。バックアップはありますか？端末を紛失、交換したらどうなりますか？他でも利用できる形式で書き出せますか？アプリの削除後に残るコピーは何ですか？
こうした判断は、製品の実際の動作とプライバシー通知に一致させるべきです。「オフライン」だからといって、すべての機能が通信しないとは限りません。外部地図、ジオコーディング、サポートへの連絡、利用者が選ぶ書き出しによって、別のデータの流れが生じることがあります。
競合の後にどうするかを計画する
後で記録をサーバーと同期する場合、二つの端末が同じ情報を編集していることがあります。どの版を採用するかの規則と、予期しない結果から復旧する明快な方法が必要です。
重複、遅延、中断した転送にも注意が必要です。繰り返しタップしても、金銭や業務に関わる操作が黙って重複実行されるべきではありません。具体策は製品のデータモデルと関係するシステムによって異なります。
権限の選択を説明する
位置情報の機能は具体的な操作に役立ち、権限を拒否された場合も予測可能に動くべきです。通知は進行中の活動を理解する助けであるべきです。Android の内部を知らなくても、選択によって何が変わるかを理解できるようにします。
権限を拒否した場合の操作の流れも設計に含めます。手動でできる操作があるなら、その方法を見つけやすくします。機能を使えない場合は、適切な時点で制限を説明します。
状態の変化を検証する
ネットワークを切った状態での起動だけでは足りません。操作の途中で接続が失われる、遅れて回復する、アプリが見えなくなった間に変化するといった場合も確認します。アプリの再起動、書き出しの中断、過去の記録の修正も考慮します。
確認は、中心となる一連の操作とそのリスクに沿って行います。ビルド成功はコンパイルに関する有用な証拠ですが、端末上の動作には別の証拠が必要です。