1

アプリ内に保存し、ルックアップ テーブルとして使用する大量のデータを定義する必要があります。たとえば、メーカー名の配列があり、それぞれに製造コードが付いています。各メーカーは、それぞれ独自のコードを持つさまざまな製品を製造できます。

A,7 は意味を解読することができます

Manufacturer: Apple(A)
Product: MacMini(7)

これを定義する方法はいくつかありますが、どれが最適かはわかりません。

オプション 1) 次のような別のヘッダー ファイルでこれらの定数を #define します。

#define MFG_APPLE @"A"
#define MFG_DELL  @"B"

#define PRODUCT_MAC_MINI 7
#define PRODUCT_INSPIRON 2

オプション 2) ディクショナリ オブジェクトで満たされたディクショナリ オブジェクトを作成して、それらのインデックスを簡単に作成できるようにします。

オプション 3) コア データを使用して、これらの製造元、製品、および関係のデータベースを作成します。

オプション 2 または 3 が提案されている場合、プログラムの起動時にデータ構造をハードコーディングして入力する代わりに、これらのデータ構造を事前に入力する簡単な方法はありますか?

オプション 4) データをより頻繁に更新できるサーバーにこれを結び付ける Web サービスを作成します。JSON クエリは製造元と製品コードをサーバーに送信し、そこで製造元と製品名で応答できます。

4

1 に答える 1

2

次の点を考慮する必要があります。データベースがアプリに付属している場合は、データベースを更新する必要があるたびに、アプリの更新をリリースする必要があります。問題は、データをどのくらいの頻度で更新する必要があるかということです。データベースを数か月に1回、または1年に1回だけ更新するのが問題ない場合は、アプリと一緒にデータベースを出荷することもできます。毎月または毎週更新する必要がある場合は、データベースをどこかでホストする必要があります。ウェブ; このような短い間隔で更新をリリースすることは、実行可能なオプションではありません。

考慮すべきもう1つのこと：データベースがWebサービスとしてのみ存在し、各ルックアップでサーバーへのJSON呼び出しが必要な場合、ユーザーがオフラインの場合（現在、ネットワークアクセスがない場合）はルックアップを実行できません。理由）。また、各ルックアップにはユーザートラフィックがかかるため、ユーザーに1か月の制限があり、1日に大量のルックアップを実行する必要がある場合、アプリを使用すると、すぐにその1か月の制限を超えて、インターネットサービスが利用できなくなる可能性があります。スロットルされたもの）最後に。

私の経験から、このようなデータベースはオンラインでホストするのが最善ですが、可能であればオフラインアクセス用にキャッシュしてください。アプリ自体にはデータベースコピーが付属しています。これは、配布用にアプリを作成した日の最新のものです。アプリが起動するたびに、またアプリが終了しない場合に備えて1日に1回、データベースの現在の「バージョン」をWebサーバーに照会します。このバージョンがアプリに付属しているバージョンよりも新しい場合は、このデータベースのコピーをローカルキャッシュにダウンロードしてから、将来のルックアップのためにキャッシュされたコピーに切り替えます。キャッシュされたコピーが失われた場合（キャッシュはいつでもシステムによってフラッシュされる可能性があります）、再ダウンロードする必要があります。その間、出荷されたデータベースを使用できます。これは古くなっていますが、何もないよりはましです。ダウンロードが不可能な場合（たとえば、デバイスに十分な空き容量がない場合）、

したがって、基本的にアプリのワークフローは次のようになります。

  1. 始める
  2. ローカルにキャッシュされたコピーが存在しますか？いいえ後藤6。
  3. ローカルにキャッシュされたコピーは最新ですか？いいえ後藤5。
  4. ローカルにキャッシュされたコピーを使用してルックアップを実行します。後藤12。
  5. 古いキャッシュコピーを削除します。後藤1。
  6. 出荷されたデータベースは最新ですか？いいえ後藤8。
  7. 出荷されたデータベースを使用してルックアップを実行します。後藤12。
  8. 更新されたデータベースをダウンロードします。
  9. ダウンロードに成功しましたか？はいの場合後藤4。
  10. ユーザーは現在オンラインですか？いいえ後藤7。
  11. JSONWebサービスを使用してルックアップを実行します。後藤12。
  12. 終わり

将来、データベースにエントリを追加するだけで、既存のエントリが変更されない場合は、さらに優れたオプションがもう1つあります。データベースが2つしかないということです。1つはアプリに同梱されており、もう1つは最後のアプリリリース以降の更新（新しいエントリが追加された）のみが含まれています。これにより、ダウンロードしてキャッシュする必要のあるデータの量が大幅に削減されます。その場合、アプリは常に2つのルックアップを実行する必要があります。1つは出荷されたデータベースで（常に最初に実行されます）、そこに何も見つからない場合は、ダウンロードされたキャッシュコピーで、出荷されたデータベースで既に見つかったエントリが含まれていません（または、キャッシュされたコピーが利用できない場合は直接オンラインで、ユーザーは現在インターネットにアクセスできます）。アプリの新しいアップデートをリリースするたびに、データベースの新しい完全なコピーが取得されます。

ダウンロード用の更新データベースは、サーバーによって動的に作成される場合もあります。もちろん、これが最良のオプションです。たとえば、アプリの出荷後、3つのベンダーと30の製品をデータベースに追加し、すべてのベンダーと製品に一意のIDがあり（新しいエントリが追加されるたびに厳密に増加します）、アプリはサーバーに最高のベンダーであることを通知できます。はIDXを持ち、最高の製品はID Yを持っていることを知っています。この場合、サーバーは、IDがXおよびYより大きいすべてのベンダーおよび製品を含む更新データベースを送信します。

これらの決定はすべて、使用するデータベース形式に影響します。一般的にはCoreDataの仕事のように聞こえますが、動的更新データベースが必要な場合は、更新を別の形式（JSON、XML、CVS、またはサーバーが簡単に生成できるもの）で配信し、次の方法でCoreDataに変換する必要があります。サーバー上でCoreDataデータベースを動的に生成することはかなり難しく、絶対にお勧めできないため、ダウンロードが完了した後のアプリ。

于 2013-01-09T16:14:39.330 に答える