メッセージのリストを表示する UITableViewController があります。CoreData と NSFetchedResultsController を使用して、セルに対応する各オブジェクトをキャッシュ/保存します。サーバーと同期するためにいつテーブルを更新するのだろうか。一方では、手動更新のみを行うこともできますが、テーブル ビューを自動的に同期させたいと考えています。一方、テーブル ビューが表示されるたびに更新することもできますが、それは無駄に思えます。この場合の通常のアプローチは何ですか？プッシュ通知を使用して、プッシュを受信するたびに更新しますか? しかし、ユーザーがプッシュ通知を無効にするとどうなるでしょうか?
1 に答える
0
「サーバー」と言うときは、インターネット上のリモートサーバーについて話していると思います。その場合、サーバーにユーザーが必要とする/望む更新が頻繁にある場合は、テーブルビューが表示されたときに更新するのは不合理ではありません (より正確には、サーバーに問い合わせて、更新が必要かどうかを確認し、代わりに更新のみをダウンロードします)。すべてを再ダウンロードするのではなく、新しいデータがある場合にのみ更新します...その種類はサーバーの性質に依存します)。ただし、この種のロジックを実行する場合は、バックグラウンドで更新をチェックしている間にユーザー エクスペリエンスが遅れないように、非同期で実行する必要があります。ただし、ユーザーが更新されたデータを必要とする/望む可能性が高い場合は、更新ボタンをタップする手間を省いてください。メール プログラムを考えてみてください。既存のメールを確認したい場合、
サーバーの更新が頻繁でない場合、および/またはサーバープロトコルが少し遅い場合は、おそらく「最後の更新が x 分前よりも長い場合にのみテーブルビューが表示されたときに更新する」というハイブリッドを配置できます。データの更新に対してこの種の条件付きチェックを行う場合、おそらく、ユーザーが手動で更新できるようにする UI を提供する必要があります。最後の更新がいつ行われたかなどを確認できます。分単位の大量の更新ではなく、毎日または毎週の更新になります。
また、私の以前のコメントのいくつかで示唆されているように、サーバーの更新をバックグラウンドで、場合によってはプロアクティブに行っていることを確認することもできます。(たとえば、アプリが起動されるとすぐにバックグラウンドで更新サーバー データのチェックを開始し、ユーザーが特定のテーブルビューに移動するときの待ち時間を短縮したい場合があります)。または、ユーザーがまだ問題のテーブルビューにいる間に、更新の非同期チェックをトリガーすることもできます (たとえば、進行中のスポーツ イベントのスコアの概要を見ている場合など)。それはすべて、サーバー データの変更の性質、アクセスできるサーバー インターフェイスの種類、およびユーザーの期待に依存します。とにかく、迷惑なスピナーなどでユーザー インターフェイスをブロックしないでください。
したがって、残念ながら、あなたの質問に対する簡単な答えはありません。答えは、少なくとも、(a) サーバーがデータ更新の存在に関する問い合わせにどれだけ迅速に応答し、その後、それらの更新をダウンロードできるかによって決まります。(b) サーバーのデータが変更される頻度。(c) ユーザーが更新されたデータを探している可能性が高い (更新ボタンを常にタップしなければならないと感じるような UX をユーザーが持っていない)。
于 2012-07-01T06:39:04.353 に答える