Mobile Services from Windows Azure - Data Store (part 2)

Part 1
When we need a backed to store data for a mobile application Windows Azure Mobile Services can be a great solution.
Let’s imagine that we need to develop a mobile application that need to store the GPS location of our client. For this purpose we can develop a complicated solution, with a backed that exposes this functionality as services. Also we will need an authentication mechanism that will add another layer of complexity.
All this functionalities are already supported by Windows Azure Mobile Services. In this blog post we will see how we can configure.
First step is to configure our Windows Azure account to have Mobile Services active. In this moment Mobile Services is in the preview, because of this before creating a Mobile Services you will need to sign up to this preview. From the new command of the portal you will find a link to the sign up page for the preview. The activation time period is very short. Each Mobile Services has a unique name, which will identify our service. At this step you will notify that a database needs to be attached to this service. You can use an existing one, or you can create a new one. This database will be used to store data.
After creating our own Mobile Service we will need to create a new table in the data section. Only the name of the table needs to be set. The columns will be automatically updated when you will insert entities in it.
Each new table that is created has some special permission that can be set. Each CRUD operation (Insert, Update, Delete, Read) can have a custom permissions set. We have 4 permissions available:

• Anybody with the application key – anybody that has our application key can execute the command over the table
• Everyone – anybody with our Mobile Services credetinals can execute the command over the table (even if the request don’t come from our application)
• Only authenticate users – only users that were already authenticated in the application can execute the command over our table
• Only scripts and admin – only scripts and administrators can execute the command over our table

In our case we will add a table named GPSLocation where the permissions will be set to “Only authenticate users”.
Next step is to create the entity that needs to be stored. In this moment Mobile Services can be used from iOS, Windows Phone and Windows Store (Windows 8) applications. We will use Windows Store in this example.

[DataContract]
public class Location
{
     int Id { get; set;}

     [DataMember]
     string Lat { get; set;}

     [DataMember]
     string Long { get; set;}
}

You notified that I decorated the class with DataContract. All entities that are saved need to be decorated with this attribute. This attributed is used when the entity is send to the Mobile Services and need to be serialized. Each property of our entity need to be a value type.
The Id property needs to be added to all items that are saved using Mobile Services. Each entity will be unique identified by this id. The auto-incrementation of this field will be made automatically by the system. Also we don’t need to add the “DataMember” attribute on this property. If we would need to references another entity that we will need to store the Id of the entity.
Mobile Services offer the build-in the mechanism that is used to consume data. The only thing that we need to have is the application url and application key. The application key is very important, because based on this people will be able to access your application.
You can use the same application key for an iOS and Windows Store application without any kind of problem. If your application key is compromised, a new one can be regenerated from the portal. In that moment you will have to make an update to your application with our new application key.

MobileServiceClient mobileService = new MobileServiceClient( [url], [applicationKey] );

This instance will be used to communicate with Mobile Services. All the request are made using HTTP/S and JSON. Yep, data are serialized in JSON format not in XML.
In the next post we will see how we can authenticate users to be able to add their GPS location. Remember, we set the rights to “Only authenticate users”. Because of this we need to be authenticating to make any kind of operations on our table. We need this because we don’t want to share locations between users.
Part 3