ソーシャルネットワークへの投稿に最適なパターン
ビールレビューの公開、現在のステータスの設定、スター評価の設定、データベースへの可用性の追加など、ユーザーがソーシャルネットワークに更新を投稿できるアプリ（RateBeer for Android）を持っています。
データの投稿に関するフィードバックをユーザーに提供する最良の方法は何ですか？
ここにいくつかの提案があります（長い投稿から申し訳ありません）、そのうち私が現在数1を使用しています）：
進行中の通知la a Tweetdeck（image 2 ）。何が投稿/アップロードされているかを示し、成功したときに消えるか、エラーメッセージ+アプリへのディープリンクを提供して失敗したときに再試行する、削除不可のステータス通知。
- +控えめ：直接アプリを直接使用できます
- +何が起こっているかをユーザーに直接フィードバック
- +エラー通知により、簡単に再試行できます
- -ユーザーに接続の詳細を公開します
- -通知を使用しますが、これはおそらくこれには使用されません。
- ？プロセスは理想的にはキャンセル可能である必要があります（ design docs を参照）
モーダルプログレスポップアップla Google +（image 1 ）と他のほとんどのアプリ。メイン画面に投稿のステータスを表示します。成功すると画面が閉じ、失敗するとポップアップが閉じます。その後、ユーザーは再試行できます。
- +何が起こっているかをユーザーに直接フィードバック
- +簡単な再試行が可能
- +実装が非常に簡単
- -邪魔になる：ユーザーがアプリをさらに使用できなくなる
- -ユーザーに接続の詳細を公開します
- -戻るボタンを無効にする必要があります
- ？ユーザーが投稿時に（自宅などに）移動するとどうなりますか？
- ？プロセスは理想的にはキャンセル可能である必要があります（ design docs を参照）
ユーザーが待機するときに画面に進行状況を表示しますユーザーが離れたときに通知を使用します。 （私がこれを使用してこれを見たのを覚えていることができません。）通知はこのように適切に使用されています。
- +邪魔にならない：アプリを直接使用できるようになり、戻るボタンは正常に機能します
- +何が起こっているかをユーザーに直接フィードバック
- +簡単な再試行が可能（直接または通知経由）
- -ユーザーに接続の詳細を公開します
- -確実に実装するのはかなり複雑で、想像できます
- ？ユーザーにとってなじみのないパターン？
- ？プロセスは理想的にはキャンセル可能である必要があります（ design docs を参照）
Gmailの投稿プロセスの完全な難読化。投稿の実際のプロセス-成功または失敗-は表示されません。代わりに、ユーザーはアプリを信頼します。多分直接のフィードバックがないので？このメソッドは Googlersが推奨 です。
- +非常に目立たない。
- +接続性の露出なし
- +かなり簡単に実装できます（ただし、いくつかのオフラインストレージが必要です）
- -ユーザーがアプリで投稿/更新を表示することを期待できない（またはオフラインストレージを使用してこれを「偽造」している）
- -投稿で何が起こっているかをユーザーに直接フィードバックしない
- ？何度か再試行しても投稿が失敗した場合はどうすればよいですか？
- ？ユーザーは信頼できるアプリを信頼する必要がありますか？
スケジュールされた（同期のような）投稿。ユーザーの投稿/更新は明らかにオフラインとしてマークされ、同期は手動で開始するか、バックグラウンドでスケジュールできます。ほとんどのメモを取るアプリと同じですが、一方向です。
- +目立たない;ユーザーは好きなときに同期できます
- +簡単な再試行が可能
- +実装がかなり簡単
- -それは非常に明確に接続の詳細を公開します
- -それは双方向の同期を示唆していますが、常にそうであるとは限りません
- ？ユーザーにとってなじみのないパターン（ノート以外のアプリの場合）？
バックグラウンド投稿プロセスですが、投稿されたかどうかのメッセージごとに視覚的なインジケーターが表示されますla la Whatsapp（image 4 ）。 4.と5.を組み合わせます。
- +非常に目立たない。
- +接続が非常に限定された（そして有用な）露出のみ
- -すべてのアプリケーションに適さないライブデータとオフラインデータの混在（例：スター評価の設定）
- ？再試行しても投稿が失敗した場合の通知は？
- ？適度に実装が簡単（ただし、オフラインストレージが必要です）
バックグラウンドポスト、成功時のトースト付き、la Play Store（画像）アプリの評価。
- +非常に目立たない。
- +接続が非常に限定された（そして有用な）露出のみ
- +実装がかなり簡単
- -投稿で何が起こっているかをユーザーに直接フィードバックしない
- ？再試行しても投稿が失敗した場合の通知は？
毛むくじゃらの詳細：私のサーバー（RateBeer.com、自分で制御しない）は非常に信頼性が低いため、アクションの失敗はある程度（1％？）よくあります。さらに、投稿はそれほど速くありません。低速または不良な接続では数秒かかる場合があります。
代替案？好き？
コンテンツのサイズ、具体的には更新が完了するまでの予想時間に依存すると思います。
ビールのレビューを追加する、現在のステータスを設定する、ビールにスターを付けるなどの単純な更新の場合は、変更の結果をすぐにインラインで表示し、バックグラウンドで更新を実行します。したがって、名前の横にある現在のステータスがすぐに更新され、ビールのレビューがすぐにレビューリストの一番上に表示されます。レビューにステータスインジケーターを表示して、レビューが投稿されていることを示すこともできますが、ステータスを示す進行中の通知は表示しません。操作にエラーがある場合（n再試行後）、変更を元に戻し、ユーザーにエラーを示します。
フル解像度の写真やビデオの投稿など、より重い更新の場合、継続的な通知オプションは、重い操作を中断することなくユーザーが別のアプリまたはアプリ内の別の画面に移動できることをユーザーに微妙に確信させるため、最善の方法です。通知は本質的にアクティビティに関連付けられていないため、状態が失われる恐れはありません。
モーダルダイアログやトースト通知は避けます。モーダルダイアログは、信頼性が低いことを内包し、国家の喪失を恐れます。トースト通知は一般的に使いすぎており（私は自分で被害者になりました）、成功を示すために使用すべきではありません。
Romanの回答は、適切な根拠のある応答を提供するため、私はそれをあなたの決定の基礎として使用します。
とは言っても、通知の使用に関して少なくとも1つの別の視点を提示したかったのです。
ユーザーに実行するアクションを提示する場合にのみ通知を表示するべきだと私は主張します。ダウンロードの場合、通知は理にかなっています。ダウンロードが完了するまで、タスクの完了時にブロックされます。そのため、通知は、ブロックアクションが完了すると、そのタスクに戻るショートカットを表します。
アップロードの場合、これは関係ありません。ユーザーが懸念している限り、アクションは完了しており、アクションに戻る必要はありません。私たちの開発者の多くにとって、アップロード通知はトーストによく似ています-カバーをはがして、デバッガーが接続されていないときに実行時に何が起こっているのかを理解する方法です。 「動作していますか？サービスは実行されていますか？そのインテントは送信されましたか？」期待することを確認するために通知またはトーストを表示するたびに、実装に対する自信の欠如をユーザーに漏らしています。
しかしながら。これは、ほぼ100％の信頼性に依存します。つまり、いったんsendを押すと、データがサーバーに到達しないことを心配する必要がないことが保証されます。
通知（またはその他の「アップロードの進行状況」UI）を表示すると、通知が「完了」に変わるたびに強化されるため、アップロードが完了することをユーザーに確信させることができます。ただし、多分それはしない完全であることも意味します。
私は、通知が「アップロード完了」以外で終了した回数を監視し、それを0に減らすよう努めています。それが達成されたら、通知を表示する必要はまったくありません。