1

I'm using Virgil Dobjanschi's Option B (from this talk: http://www.google.com/events/io/2010/sessions/developing-RESTful-android-apps.html) to implement a web service on my Android App to connect to a Google Cloud Endpoints RESTful service (hence, my URLs are abstracted over).

The local SQLite database requires a Primary key (which must be called _id so it can link with a ListView). The AppEngine service also requires a unique ID per record. The resources in the service are shared between multiple clients, so their IDs need to be maintained unique on the server. The resource ID is generated, derived from two other IDs, and in the form of a String.

By design, these resources are never created locally on the Android app, they are only read and updated - creation and deletion happens elsewhere, and then those created are sent via Google Cloud Messaging, complete with their REST Ids, and inserted into the SQLite table. If I ever do create them locally, I'll be able to generate the unique ID from the REST resource locally as well.

Should I have the ID on the SQLite database be a separate unique id, maintained locally, and store the REST id in the record, or should I set the SQLite ID to be the same as the REST id?

ie:

My REST Resources are of the form:

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

My SQLite options are:

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

Or:

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

In the first option, I could make restId UNIQUE as well. I'm leaning towards the second option, but am wondering if I'll run into unforeseen problems with this approach.

I also have another similar situation with some different resources where the REST key is a Long rather than a String, but I still question whether I should maintain a local primary key separate to the REST resource ID.

Richard Russell
  • 1,105
  • 1
  • 10
  • 19
  • I've since started implementing the version with a Long ID, keeping the _id and the AppEngine key the same. I discovered that in UriMatcher (http://developer.android.com/reference/android/content/UriMatcher.html) I can use # as a wildcard for numbers, and * as a wildcard for text... So it looks like this is possible. The question then becomes: is it wise? – Richard Russell Mar 08 '13 at 11:24

1 Answers1

0

It seems that it's best to use Integers for the _id field in SQLite, which means that they necessarily won't match the String Keys in AppEngine.

The http://developer.android.com/reference/android/content/ContentUris.html refers to id as "A unique numeric identifier", and provides helper methods that require it to be a long.

It may be possible to work around this, but given that this assumption is built in to ContentUris, I expect that it will also be built in elsewhere, so it would be easier to do this with numeric ids kept internal to the App, and enforce uniqueness of the AppEngine keys separately.

Richard Russell
  • 1,105
  • 1
  • 10
  • 19
  • This is what I have done. However it is possible to use long as type for the key field in SQLite, so you could use your appengine ids. I wanted to be able to created records locally on the android device, even if offline, so I needed to use the other approach. – Patrick Jackson Mar 15 '13 at 14:03