Azure Mobile Services as explained at //build/ – The first 15 minutes
Introduction
This is a bookmark to help me remember a useful session around Azure Mobile Services at //build/. It covers only the first 15 minutes that have provided me some great insight to waht is possible. I also provide a rough outline to help me remember the content.
This is a quick synopsis of the first part of Chris and Donna’s presentation at //build/ 2014. You can find it at the //build/ site.
The first part of this talk provides a great overview of what type of data models you can support leveraging Azure mobile services as your backend.
I was surprised to learn that not only does it support multiple client applications, but also multiple data models on the backend, such as MongoDB, Azure tables, and more.
LOB Business Apps - You should leverage Mobile Services
- Mobile Services provides good backend support
- Just focus on front end
- You spend time on app logic
- Mobile Services provides full CRUD operations
Cross-platform support - use of a common interface
Needs to be lightweight
Broad support for Windows, iOS, Android, HTML/JS, Xamarin, PhoneGap
Supports basic operations
- Below you will find a read operation
Data Back-end also can be different
- Not locked into SQL Server
- Azure, SQL, Mongo, You are not restriced to SQL Server.
Connecting with common interface
- Leverage pre-built table objects that support CRUD operations
Built-in types provide needed functionality
- IMobileServiceTable
- Provides crud operations for tables
- MobileServiceConnection
- How you connect to backend
Support for Occassionally connected scenarios
- Same as "offline data"
- Keep a queue of work that was performed while disconnected
- Queue is applied to real data once the connection is re-established
- Synchronize when connected
- Needs to be smart about conflict resolution
- App opts in to be "offline capable"
- Nuget can give you a local version
- But not a full-featured sync frameworks
- Most full featured versions have a specific backend and front end, like SQL Server
- But if you want support for multiple back ends and multiple clients, this might be a compromise you are willing to accept
How to add offline support
Use IMobileServiceSyncTable<> and GetSyncTable() to interact with tables
In your init code, add App.MobileService.SyncContext.IsInitialized
Uses MobileServiceSQLiteStore() object
- Job and Customer table offline synced
Calls the App.MobileService.SyncContext.InitializeAsync()
- Then you juse call DefineTable for those tables you want to sync
There are PushAsync() and PullAsync() methods to call to perform local data usage
- Optimistic concurrency is used
- You don't need a lock ahead of time because you are optimistic it hasn't been changed on the server
- Pessimistic you need to ask for a lock, but not shown here
How to handle and resolve conflicts
- Notice that Device 1 has a dirty write up at the server because the server version is more recent.
- Now we need conflict resolution code
- During init() you need to specify and SyncHandler()
- Called when change is trying to happen on server
- But we may need to have a conflict resolution
- Trap the MobileServicePreconditionFailedException
- Pull the existing server value to client
- Then show to user and let user decide if overwrite on server
- Use local version or use server version.
- Let user decide
- The user interface allowing user to choose
Summary
I recommend you go through the video. There is some great guidance to be had:
- Supporting multiple front end clients AND back end data stores
- How the optimistic concurrency mechanism works
- How to implement conflict resolution code
- How to support occassionally connected scenarios