Using Windows Phone with Windows Azure

When you create a Windows Azure-hosted service for your Windows Phone application, you can choose whether to require clients to authenticate. Authentication helps to mitigate malicious attacks on your services by making clients prove their identity. Also, authentication enables you to authorize access to client-specific subsets of stored data. This is known as a multitenant application. For more guidance on creating multitenant applications in Windows Azure, see Designing Multitenant Applications on Windows Azure.

There are two supported methods for authenticating a Windows Phone application to Windows Azure-hosted services:

Windows Azure Access Control Services

Access Control Services (ACS) is a cloud-based service that provides an easy way for Windows Phone clients to authenticate to web applications and services. Rather than having to maintain your own client access lists, you can offload this work to a trusted identity provider, such as Windows Live ID, Google, Yahoo!, or Facebook. For more information, see ACS Overview. For an example of how to access an OData feed from a Windows Phone application by using the ACS service, see Connecting to an OAuth 2.0 protected OData Service.

ASP.NET Forms-Based Authentication

ASP.NET includes its own membership provider, which is also supported for ASP.NET Web roles in Windows Azure. This membership provider is used by ASP.NET form authentication to authenticate requesting clients. Using ASP.NET forms-based authentication requires you to maintain your own client access lists. For more information, see Real World: ASP.NET Forms-Based Authentication Models for Windows Azure.

The Windows Azure Toolkit for Windows Phone supports both of these authentication schemes.

You must always use an encrypted connection when you exchange credentials with Windows Azure-hosted services. You should also strongly consider using an encrypted connection whenever your application sends or receives data that your users consider private. In Windows Azure, this security is provided by using a Secure Sockets Layer (SSL) or Transport Layer Security (TLS) connection. For more information, see Web Service Security for Windows Phone.

We strongly recommend that your application prompt for usernames and passwords each time your application needs them from the user; if you attempt to save the credentials on the phone. You risk exposure of those credentials to a malicious application if the Windows Phone is lost or stolen. Use the ProtectedData class and the associated cryptography classes to encrypt and store sensitive information in your application. For more information, see How to: Encrypt Data in a Windows Phone Application.

When possible, store any data needed by your Windows Phone application on the local device, even when this data originates from the cloud. This is especially important for reference data, such as lookup tables, for data that is needed when the application first starts, or for any data that improves the application experience for customers. For more information, see Data Synchronization between Windows Azure and Mobile Clients.

Implementation

Consider storing on the local device any data from the cloud that is needed by your application to run correctly or to start more efficiently. You can store this data by using either local database or isolated storage. For more information, see Local Data Storage for Windows Phone.

For an example of how to store data from OData feeds in the local database, see the series Synchronizing OData to Local Storage in Windows Phone.

Because Windows Phone does not enforce any storage limits on the device, it is up to your application to be responsible about how much storage to use. Be aware of storage levels on the device by checking AvailableFreeSpace, and be prepared to stop storing data when the application exceeds a reasonable self-imposed limit. You should also consider providing customers with a way to clear stored data manually.

Trade-offs

One of the benefits of cloud-based storage is that your data is available anywhere and on any device. While locally storing application data can improve application performance, locally stored data is not available outside of the Windows Phone application. This means that, should a customer lose or damage the device, the data is not recoverable. Also, you might want to make this same data available to your customers on any device or computer. Consider using an OData-based synchronization service to maintain critical customer data both on the device and in the cloud. For more information, see the post Synchronizing Windows Phone Data to Windows Azure Services Using the Sync Framework Toolkit.

Failure to run correctly without an internet connection can cause your Windows Phone application to fail certification. Make sure to check for internet connectivity before making a request to a cloud-based service. Also, because most users pay for mobile network bandwidth over some set limit, you should try to run any background data synchronization tasks over a Wi-Fi connection rather than the mobile network. You can also enable users to disable any background synchronization tasks or make them Wi-Fi only.

Implementation

You can check for internet connectivity by calling the GetIsNetworkAvailable method. You can also call the GetCurrentNetworkInterface method to check the type of the connection, whether it is cellular or Wi-Fi. For more information, see How to: Get Connection Information about a Socket for Windows Phone.

Trade-offs

When users disable access to certain network connections or to background tasks, it might affect the performance or functionality of your application.

Some data exchange formats are inherently more compact and efficient than others. If bandwidth is your primary concern, then create or use only Windows Azure services that support the JSON protocol. This is because the JSON data format is inherently more efficiently than XML-based formats.

Implementation

Try to use services that support JSON. OData services support the JSON format in addition to the default Atom XML format. To get a JSON response from an OData service, supply a value of application/json as the Accept request header. You can also specify a query option of $format=json in the URI of a data service request, but WCF Data Services doesn’t support the $format query option by default. For more information, see Best Practices for Leveraging OData Services. WCF REST also supports the JSON format.

There is no equivalent client library support for JSON like there is for Atom XML by using the OData client for Windows Phone. However, you can use the DataContractJsonSerializer class on the device to serialize a JSON response into objects on the client based on a data contract. For more information, see the post Inferring Schemas for JSON.

Trade-offs

The OData client for Windows Phone makes it easy to interact with OData services. However, this client library currently only supports the Atom XML format. If you want to take advantage of the convenience of using the OData client library, then consider using compression, which is more efficient for XML-based formats than it is for JSON.

You can reduce network bandwidth requirements by employing a compression scheme, such as gzip. Using compression is even more important when using an XML-based format like Atom. You should consider using compression to reduce the network requirements when you use the OData client for Windows Phone, which only supports the Atom XML format.

Implementation

Enable compression at the server, and make sure it is configured for the MIME type of the response from your service (such as application/json or application/atom+xml). For more information, see the post on IIS Compression in Windows Azure. To request a compressed response from the web server, set the Accept-Encoding header in the request to the supported compression scheme, such as gzip. Windows Phone does not currently have its own compression library, so you must use a third-party compression library, such as SharpCompress. The OData library for Windows Phone enables you to set the headers to request compression. It also provides an API to access a compressed response stream and return the decompressed response for the library to materialize into objects. For an example of how to use compression with the OData client for Windows Phone, see the article OData Compression with Windows Phone 7.5 (Mango).

Trade-offs

Compression saves network bandwidth, but at the expense of performance, both in the service and on the device. Fortunately, Windows Azure allows you to scale your hosted service to meet capacity demands. You can do this by increasing or decreasing the number of role instances that are running as part of your hosted service. However, increasing the number of instances of a running role increases the compute hours that are billed. For more information, see How to Scale Applications by Increasing or Decreasing the Number of Role Instances.

Performing compression and decompression also consumes processing resources on the Windows Phone device. This additional processing can negatively affect the battery life of the device.