The Visual Studio App Center team has been working to change how you use App Center with your apps. Last week, we released a suite of new Mobile Backend as a Service (MBaaS) services that will not only enable you to easily manage and deploy your backend, but easily scale your app as your user base grows. Build, Test, Release, Monitor, and Repeat. That has been the traditional approach App Center has taken, but this year we want to do even more.

This post will focus on one of these new services: Data. We’re aiming to solve some of the biggest problems associated with data. The App Center Data service, currently in preview, lets you manage, sync, and persist your application data in the cloud across different devices and platforms in both online and offline scenarios. Whether it’s global data that every user can see or private account data, you can manage both with our easy-to-use client SDK.

What We’re Building:

Our new data service is built on top of Cosmos DB, Microsoft’s globally distributed multi-model database service, which scales as your user base and number of apps grow. We empower you to utilize some of the best Cosmos DB functionality within the mobile realm and provide some additional App Center magic!

For public preview, we have a one collection model, which is made up of documents with no schema where your objects are stored as JSON. These documents exist in two different types: public read-only and private.

So, what does this mean? Let’s say we have created a simple app to browse restaurants near you. This app has two features as a part of its core functionality:

1. The ability to see a list of the 10 best restaurants in your area
2. The ability to save your favorite restaurants to your own “My Favorites” list

The public and read-only documents would be represented by the list of the 10 best restaurants in your area. This is an example of data that anyone using your app could see. These documents allow you to create instances of data that are global and consumable by all users.

This brings me to the second type of document: private user documents that may be read/write by a given authenticated user via Azure Active Directory (AAD) B2C. These are the documents that belong directly to a user. Continuing with our example, they would be the list of restaurants saved to the “My Favorites” list. Since these belong to a user and are tied to their identity, logging into another account would potentially present an entirely new list of restaurants!

Below is a diagram detailing the architecture of both public and private documents within the Visual Studio App Center Data service. As detailed by the diagram, documents live in partitions. All documents belonging to an authenticated user lives in their partition and is read/write by that user. Public documents, on the other hand, are read-only by all users. You can utilize both types of documents to create a seamless experience for users around private and public data.

One of the most notable features of App Center Data is the offline functionality. The Data service supports both writing data offline with a simple store and forward model and reading information offline with a built-in SQLite cache. This enables your users to continue using your apps anywhere and everywhere. While our offline functionality is still in the early stages, we plan on releasing some great new additions such as real-time syncing and remote listeners across all our SDKs.

Getting Started:

To get started with App Center Data, first log into the App Center portal and click the Data menu item located on the left navigation pane. Once you select the Data menu item, you will be presented with a “New Database” button. In this post, we’ll be focusing on the new database flow, but we also support connecting to existing databases.

The New Database option allows you to provision an entirely new Cosmos DB database in App Center complete with an estimate of your pricing in a digestible format.

When provisioning a new database, you will be asked for the following:

Resource Name: A unique identifier of your choice, which serves as both the resource name and database name in Cosmos DB.

Database Location: The preferred location of where you would like your data stored. This allows for a catered data experience for your user base and ensures you have the fastest possible transfer of data.

Throughput: The estimated throughput for your application, which has a direct relation to the pricing and amount of traffic/operations in your app. Pricing is determined by a Comsos DB concept called Request Units (RUs). This serves as the currency of Cosmos DB and a certain number of RUs are charged with operations such as Read, Writing, and Querying.

App Center will initially offer two tiers for throughput. The first of these tiers is our Getting Started tier, which was created for small apps and developers aiming to get some experience using the data functionality offered in App Center. The minimum throughput is initially applied to this tier, but can be adjusted as you see fit.

The second tier is for more developed apps and individuals who may have a bit more experience with Cosmos DB and the pricing model. In this tier, you will be asked to estimate your reads and writes per second and pricing will be calculated as a result of this. This allows you to provision just what you need based on your app’s traffic.

Once you’ve completed this flow, you’ll be able to start using the Data service in App Center with your newly provisioned Database.

The Client SDKs

The new client SDKs are a critical part of the Data development experience. We currently support Native iOS, Native Android, Xamarin iOS, and Xamarin Android SDKs for usage in our new data service and plan on expanding on this in the future. Our SDKs gives you complete CRUD access over your data. You can create, read, update, and delete documents all with a few lines of code. We keep it simple, and integrating the SDK is done in a few easy steps. All you need to do is add the SDK to your build.gradle, podfile, or add the appropriate NuGet packages to your solution and then start the SDK using the library’s start function.

We’re Currently in Public Preview, but this is Just the Beginning.

We have many things planned for the road ahead, including real-time syncing via App Center Push and SignalR, shared documents, and Data management and Utilization metrics in the App Center Portal. You can see the full details of our plans on our roadmap.

Our goal through all of this is to maintain a position of visibility as we create this new service and would love for you to be a part of it. We share our planning directly in the App Center Repository. If you have any feedback or want to request a feature, you can do so on our issues page. We take everything you say into account and your suggestion may be the driving force behind our feature work!