Documentation for Azure Mobile Services offline sync

Question

We're trying to use Azure Mobile Services to do offline sync to an iOS app, running on iPhones and iPads.

So far, we have only a very simple app that's trying to sync against a single table. Sometimes it works fine, sometimes it's slow as hell, sometimes it times out, sometimes it fails immediately with internal "table not found" errors.

We've been unable to find any actual documentation on this framework. There are a number of online tutorials, but no in-depth documentation.

Does anyone know where we can find better docs on how to use, and how to trouble-shoot, this API?

Is there someplace we could look to find more details about what actually went wrong, when our client-side calls error out?

Answer 1

The primary two docs are here:

• https://azure.microsoft.com/en-us/documentation/articles/mobile-services-ios-get-started-offline-data/
• https://azure.microsoft.com/en-us/documentation/articles/mobile-services-ios-handling-conflicts-offline-data/

Granted those are both still fairly high level, but the last one should be a little more helpful on troubleshooting.

Also the project is open source here: https://github.com/Azure/azure-mobile-services/tree/master/sdk/iOS and you can make a workspace with it if you want to get into the internals.

The synctable operations (insert/update/delete) errors would typically only be an issue with CoreData and they just surface the error they got internally up.

For Push/Pull, they can wrap the errors up in an array since there can be 1/item being synced, but again the underlying error should be available.

Internal table not found error would be due to the table not being defined in CoreData. It happens when the code is unable to make an entity for the given table (see: https://github.com/Azure/azure-mobile-services/blob/master/sdk/iOS/src/MSCoreDataStore.m#L51) I'd review how you are initializing your managed object context and if your model is correct.

For the slowness issue, my guess is, you are running a free mobile service, which if not used for a period can be wound down and needs to start up on first API ping. (This process does not happen in the basic/standard tiers)

Also the iOS default for network timeout is 30 seconds, so a legitimate network issue can also feel slow.

Finally, it could also be the amount of data, by default 50 records come down at a time during Pull (so if you are syncing 5k rows initially, that will take 500 trips to finish, but after that it would only be pulling changes, which would be 1-2 trips.