エラー処理のAndroid推奨事項とは
Android UXデザインドキュメントを調べていますが、エラー処理に関するベストプラクティスの記事が見つかりません。
気になるエラーの種類は、インターネット接続がないなどの理由で機能が制限されています。
ユーザーが閉じることができるダイアログを作成することを考えました（その後、キャッシュされたバージョンのアプリが提供されます）が、アプリの上部に通知をポップアップ表示する方が理にかなっていると考えています（ Android UI Docs ）。これはAndroidスタイルガイドに沿ったものになると思いますが、同時にそれが適切かどうかはわかりません。
誰かが、特にAndroidからの記事を知っているなら、それは大歓迎です。
この「エラー」が発生した場合でも、アプリケーションの機能が制限されると述べています。したがって、過度に熱心なエラー報告は、アプリケーションの機能が制限されたバージョンを妨害する可能性があります。これは、アプリケーションを不明瞭にするか、何かがおかしくなり、アプリが機能しないことをユーザーに誤って知らせます。
通知はお勧めしません。通知は time-sensitive またはその他の重要なメッセージを対象としています。
ユーザーはすでにアプリにいますが、なぜアプリから通知ドロワーに強制しますか？むしろ、制限された機能のアクティビティに何らかのインジケーターを表示します。このようにして、ユーザーは接続が失われたことを通知されますが、それ以外の場合は通常の方法でアプリケーションと対話できます。さらに、ユーザーはアプリ内から、接続の状態の変化を監視できます。
この回答をより一般化できるようにするために、一般的に使用されている4つのエラー報告メカニズムについて見てきました。
- アプリケーション内のインライン通知：これは、ユーザーが使用中にアプリケーションを操作することが予想される場合、つまり、アプリケーションがバックグラウンドサービスではない場合に最適です。エラーが発生してもアプリケーションが機能し続けると、レポートが煩わしくなくなり、ユーザーがアプリケーションとやり取りするときにエラーのステータスを監視できるため、特に役立ちます。
- トースト通知： トースト は一時的な通知であり、ユーザーの操作を中断したり、画面の不動産を消費したりすることなく、基本的なフィードバックに最適です。これらは、ユーザーがアプリケーションをアクティブに操作している場合にのみフィードバックに役立ち、しばらくすると消えるので、最も小さなエラー以外には適していません。おそらく、エラーをより完全に説明するために、インラインエラーレポートでそれらを使用します。
- ダイアログボックス：これらは注意して使用する必要があり、ユーザーの操作を中断して注意を要求します。アプリケーションを続行する前に、ユーザーの介入または選択を要求するエラーに適しています。アプリがユーザーの介入なしに安全に続行できる場合、これらはおそらく正しい選択ではありません。
- 通知：これらは「アウトオブフロー」フィードバックであり、時間に敏感な介入を必要とするフィードバック、またはユーザーがアプリケーションと直接対話していないときに発生する可能性があるフィードバックに最適です。バックグラウンドダウンロードの失敗は良い例ですが、時間に敏感ではありませんが、ユーザーはエラーを通知する必要があり、座ってダウンロードを監視することはほとんどありません。
Android offline操作を許可するアプリケーションは、接続が利用できない場合にユーザーにエラーを表示しません。利用可能なデータ接続を確認し、利用できない場合は、アプリケーションの状態としてオフラインモードに入ります。
アクションバーにアイコンを追加して、オフラインモードを表すことができます。アイコンをクリックすると、オフラインモードを終了するためのサブメニュー項目が表示され、オンラインのときにオフラインモードに入るか、ユーザーにオフラインモードの機能を説明するヘルプページにリンクできます。
この質問は関連しているかもしれません。
質問は古いですが、返信は新しいAndroid Material Desginガイドライン、エラーセクションから取得する必要があります： http://www.google.com/design/spec/patterns/ errors.html