CODEWITHSUNDEEP
c#azureazure-mobile-services
h bob
h bob

Reputation: 3780

Which data types should a client model use for offline sync with the Azure mobile apps SDK?

I am using the offline-sync stuff in Azure's mobile app services SDK.

I'm aware that there have been various changes recently in the SDK. I want to define client models according to the latest spec, but not sure which types to use.

These are the offline-sync metadata properties, typically seen in most examples/tutorials:

[JsonProperty(PropertyName = "id")]
public string Id { get; set; }

[Version]
public string Version { get; set; }

[CreatedAt]
public DateTimeOffset CreatedAt { get; set; }

[UpdatedAt]
public DateTimeOffset UpdatedAt { get; set; }

[Deleted]
public bool Deleted { get; set; }

But some documentation and examples, as well as various official (too many!) samples/quickstarts on GitHub, use a combination of types.

So I've seen this too in various places:

[JsonProperty(PropertyName = "id")]
public Guid Id { get; set; }              // Guid is used here, not string

[Version]
[JsonProperty(PropertyName = "version")]  // Needed? I assume the attribute is enough
public byte[] Version { get; set; }       // byte[] is used here, not string

Under the covers everything is done via REST calls, and thus strings. So I assume the client SDK performs various type conversions.

But I don't want my app to bomb inexplicably at some point in the future, when things change. So which officially supported types should I be using?

Upvotes: 3

Views: 476

Answers (2)

lindydonna
lindydonna

Reputation: 3875

The client SDK requires only a string Id field (that should be named "Id", unless you want to jump through a bunch of hoops). The value of the string can be any unique string. The Server SDKs use a string-converted GUID by default. When using offline sync, the client SDK also generates a string GUID unless an ID is specified. When using the online IMobileServiceTable APIs, the client lets the server generate the ID.

The rest of the fields are optional and should either have the types you listed, or be convertible to them.

Here's your data model, with comments on the various fields:

// required, should be called Id, *must* be of type string when using offline sync
// When not using offline sync, should be string-convertible.
// When using offline sync, the client SDK uses a new string-converted GUID for this, unless 
// an ID is specified.
// When using offline sync, Ids are not mutable, so use something that can be client generated
public string Id { get; set; }

// optional. Using a Version field opts you into optimistic concurrency, where 
// the server will reject updates that are done against an older version
// of an object. This means you need a conflict handler.
// To use a client-wins policy, remove this property from your client object
[Version]
public string Version { get; set; }

// optional. Cannot be set on the client, will be sent from the server
[CreatedAt]
public DateTimeOffset CreatedAt { get; set; }

// optional. Cannot be set on the client, will be sent from the server
[UpdatedAt]
public DateTimeOffset UpdatedAt { get; set; }

// should generally not be used in the client object at all. This field tracks 
// which objects have been deleted so that they are automatically purged
// from the client's offline sync store
[Deleted]
public bool Deleted { get; set; }

Upvotes: 6

h bob
h bob

Reputation: 3780

Looks like you can use almost anything for the id column, as long as it's unique. Even an email address! (feels like NoSQL...) I've decided on a Guid, so all entities are consistent upon creation (no need to wait for server's response).

I've decided upon a byte array for the version column, as it seems to return exactly that from the server.

EDIT: This is quite wrong. See comment below and new accepted answer above.

Upvotes: -1

Related Questions