iPhoneアプリのコアデータを使用する際に価値はありますか？

Question

アプリケーションでcoreDataを使用する理由の例を教えてもらえますか？

ほとんどのアプリは、何らかのAPIが必要な情報を提供する中央サーバーのクライアントに過ぎないので、私はこれを尋ねます。コアデータに私のサーバー上のデータ構造を複製するの任意の値がある場合、私はAPIを持っていると私は議論していたWebアプリケーションのためのタイムシートアプリケーションを書いている私の場合は

（Sqliteを）

例えば

プロジェクト 従業員は、多くのタイムシート

を持っている多くのタイムシートを持っていることは、私はちょうどプロジェクトまたは、例えば、既存のタイムシートのリストのすべての呼び出しでAPIに接続できるように私には思えます。

オフラインモードでは、コアデータをローカルに保存することができますが、接続が再開されたときに、そのデータをWebサーバーに同期させるのに大きな問題が発生するため、より多くの問題が発生します。タイムシート用に選択したプロジェクトは存在しなくなりました。

経験豊富な開発者は、コアデータがベストプラクティスのアプローチであるときの経験を少しでも光らせてくれますか？

EDIT

私は値がローカルの永続性を格納してあり、もちろん実現するが、ユーザーのデフォルトのキー値は、私は考えることができるほとんどのアプリケーションをカバーしているようです。

Answer 1

CoreDataは単にSQLiteデータベースと考えるべきではありません。 SQLiteデータベースだけではありません。確かに、SQLiteはオプションですが、インメモリやiOS5のような他のオプションもあります。これはカスタムデータストア全体です。 CoreDataの最大の利点は、明らかに永続性です。しかし、メモリ内のデータストアを使用していても、非常に構造化されたオブジェクトグラフの利点があります。また、データストアから情報を引き出す、または情報をデータストアに格納することに関する重労働は、そのデータストアをバックアップしていることに心配する必要はありません。確かに、今日は永続性についてあまり気にしないので、インメモリのデータストアを使用することができます。明日、あるいは1ヶ月、または1年のうちに、永続性から本当に恩恵を受ける機能を追加しようとするとどうなりますか？ CoreDataを使用すると、永続的なデータストアを変更または追加するだけで、すべてのメソッドを使用して情報を取得または変更することができます。 SQLiteや他のデータストアに直接アクセスしようとしていた場合と比べて、そのような追加のオーバーヘッドは最小限に抑えられます。 IMHO、それは抽象化という最大の利点です。そして、本質的には、抽象化はOOPの背後にある最も強力なものの1つです。確かに、メモリ内のストレージだけのためにデータモデルを構築することは、アプリの関与状況に応じて、アプリにとって過度のものになる可能性があります。しかし、ちょっとしたこととして、より速いものを検討したいと思うかもしれません。何らかのアクションを実行するたびに情報を要求したり、情報を一度要求したり、メモリに保存したり、残りのセッション。インメモリー・データ・ストアは、その特定のセッションを超えて永続的ではありません。

さらに、CoreDataを使用すると、保存、フェッチ、元に戻すなどの他の優れた機能を多数利用できます。

Answer 2

データを電話機にローカルに保存する場合に最適です。

しかし、あなたのタイムシートアプリの必要性が見えない場合は、心配する必要はありませんし、使用しないでください。

「オフライン」モードで発生する同期の問題を解決するには、アプリの設計に細部があります。たとえば、プロジェクトを削除できないようにします。どうしてですか？特定のプロジェクトのために以前のデータを時間内に戻して見たいと思わないでしょうか？代わりに、それを非アクティブとして表示するためのマーカーと、非アクティブにされた日付/時刻を表示するだけです。デバイスから同期されているデータがそのプロジェクトのもので、そのデータが非アクティブとしてマークされた日時より前である場合、同期することは問題ありません。それ以外の場合はメッセージを表示し、ユーザーはそれをソートする必要があります。

Answer 3

実際に問題がある場合や、Webサービスの周りに薄いGUIクライアントがある場合、データをローカルに保存する必要があるかどうかは、アプリケーションの設計に依存します。オフラインモードとは別に、クライアント側でサーバーデータをキャッシュするもう1つの理由は、サーバーからトラフィックをロードすることです。クライアントにタイムシートデータ全体が送信されるたびに、または変更が送信されることは、サーバーが何を意味するのかを考えてください。はい、それは両側でより多くの実装を意味しますが、場合によっては深刻な利点があります。

EDIT：例では、あなたのタイムシートアプリケーションでユーザーあたり1000件のレコードを持っており、一つのレコードは、CCA 1キロバイトである

を追加しました。この場合、ユーザーがアプリケーションを起動するたびに、サーバーから1Mバイトのデータをフェッチする必要があります。データをローカルにキャッシュすると、サーバーは最後の更新以降に2つのレコードが更新されたとします。したがって、2 KBだけをダウンロードする必要があります。今は数万人のユーザーのためにこれをスケールアップする必要があり、サーバー帯域幅とCPU使用率の違いにすぐ気付くでしょう。

Answer 4

基本的に2種類のアプリがあります。ローカルの機能（ゲーム、プロフェッショナルアプリケーション、ナビゲーションシステムなど）を提供するものと、リモートサービスへのアクセスを許可するもの。

あなたのアプリは2番目のカテゴリにあるようです。リモートサービスにアクセスすると、ユーザーは新しいデータやリアルタイムのデータにアクセスしたい（2週間前のFacebookの投稿を読んでいない）場合がありますが、ローカルのキャッシュが意味を持ちます（たとえば、不安定なネットワークの列車で）。

リアルタイムデータにアクセスする重要性と比較して、ネットワークに接続されていないときにキャッシュされたエントリにアクセスする価値は、お客様（内部または外部）にとってかなり低いと想定します。したがって、ローカルストレージはまったく必要ではないかもしれません。

タイムテーブルに何百ものエントリがない場合、「通常の」シリアル化（NSCoding-protocol）で十分でしょう。いくつかの "ダッシュボードデータ"にしかアクセスしないと、単純なリクエスト/レスポンスキャッシング（NSURLCacheは多くのことを行うことができます...）に対応することができます。

コアデータは、サーバーと同期する必要がある複雑なデータ構造を持っていると意味があります。これにより、コアデータの統合（同時実行性、スレッド安全性、アプリ内競合など）の複雑さと同様に、プロジェクトに多くの同期ロジックが追加されます。

サーバードリブンユーザーエクスペリエンスで「クライアント」-appを作成する場合、ローカルストレージはまったく必要ないので、私の提案は次のとおりです。オフラインストレージが本当に必要でない限り、できるだけシンプルにしてください。