1

Virgil Dobjanschi のオプション B (このトークから: http://www.google.com/events/io/2010/sessions/developing-RESTful-android-apps.html ) を使用して、Android アプリに Web サービスを実装しています。 Google Cloud Endpoints RESTful サービスに接続します (そのため、私の URL は抽象化されています)。

ローカル SQLite データベースには主キーが必要です (ListView とリンクできるように、_id と呼ばれる必要があります)。AppEngine サービスでは、レコードごとに一意の ID も必要です。サービス内のリソースは複数のクライアント間で共有されるため、それらの ID はサーバー上で一意である必要があります。リソース ID は、他の 2 つの ID から派生し、文字列の形式で生成されます。

設計上、これらのリソースは Android アプリでローカルに作成されることはなく、読み取りと更新のみが行われます。作成と削除は別の場所で行われ、作成されたリソースは Google Cloud Messaging を介して送信され、REST ID と共に送信され、SQLite テーブルに挿入されます。 . それらをローカルで作成する場合は、REST リソースからもローカルで一意の ID を生成できます。

SQLite データベースの ID を別の一意の ID にして、ローカルで維持し、REST ID をレコードに保存する必要がありますか、それとも SQLite ID を REST ID と同じに設定する必要がありますか?

すなわち:

私の REST リソースの形式は次のとおりです。

String id; // unique, derived from two other ids
String data;

私のSQLiteオプションは次のとおりです。

create table myResource (
  _id INTEGER PRIMARY KEY AUTOINCREMEMT,
  restId TEXT,
  data TEXT);

または：

create table myResource (
  _id TEXT PRIMARY KEY,
  data TEXT);

最初のオプションでは、restId を UNIQUE にすることもできます。私は 2 番目のオプションに傾いていますが、このアプローチで予期しない問題が発生するかどうか疑問に思っています。

REST キーが String ではなく Long であるいくつかの異なるリソースでも同様の状況がありますが、REST リソース ID とは別にローカル主キーを保持する必要があるかどうかはまだ疑問です。

4

1 に答える 1

0

SQLite の _id フィールドには整数を使用するのが最善のようです。これは、AppEngine の文字列キーと必ずしも一致しないことを意味します。

http://developer.android.com/reference/android/content/ContentUris.htmlは id を「一意の数値識別子」として参照し、長い必要があるヘルパー メソッドを提供します。

これを回避することは可能かもしれませんが、この仮定が ContentUris に組み込まれていることを考えると、他の場所にも組み込まれると予想されるため、数値 ID をアプリの内部に保持して強制する方が簡単です。 AppEngine キーの一意性を個別に確認します。

于 2013-03-08T13:18:29.343 に答える