Using Windows Phone with Windows Azure
Author: Glenn Gailey
Reviewers: Matt Stroshane and Turker Keskinpala
The Windows Azure platform provides highly scalable processing and storage capabilities, a relational database service, and premium data subscriptions that you can use to build compelling Windows Phone applications. This topic provides guidance for leveraging the Windows Azure platform to build great experiences on Windows Phone devices. The general guidance for optimizing Windows Phone for use with the Windows Azure platform is:
Windows Azure Services that Support Windows Phone
Leveraging the Windows Azure platform in your Windows Phone application is all about consuming and storing data. The data for your application might already exist in the cloud through existing services, like Windows Azure Marketplace. Marketplace is a subscription-based cloud service that simplifies publishing and consuming data by leveraging the Open Data Protocol (OData). Marketplace enables developers to discover, preview, purchase, and manage premium data subscriptions. For more information, see Windows Azure Marketplace.
The odata.org Web site also maintains a list of publicly available OData feeds. For more information, see the Producers page of the odata.org web site.
More commonly, the data required by your application to support your customer’s scenarios belongs to you. Again, an excellent way to make this data available to your Windows Phone application users is by using the Windows Azure platform. The topic Windows Azure Platform Overview for Windows Phone provides a detailed overview of the Windows Azure platform and how it can be used to support the data requirements of Windows Phone applications.
You should not access Windows Azure storage services directly from a Windows Phone application, except in cases where you are using the Blob service. This is because we recommend that you not distribute Windows Azure storage services credentials to clients. To enrich your applications with cloud-based data, you should instead create your own Windows Azure-hosted services that can take advantage of these other Windows Azure platform services. That way, only your Windows Azure-hosted service needs access to the storage service credentials.
You expose data to customers by creating Windows Azure-hosted applications and services that are deployed to Windows Azure as an ASP.NET web role. These applications can be Windows Communication Framework (WCF) applications or OData services. In Windows Azure, you can create OData services by using WCF Data Services. For more information, see Guidance for OData in Windows Azure.
The Windows Azure Toolkit for Windows Phone includes Visual Studio project templates for creating Windows Azure-based services for consumption by Windows Phone applications.
Building Apps that Access Azure-Based Services
Applications that access Windows Azure-based services must create HTTP requests against service resources, consume data in the message body of the response, and display this data to users, usually by binding to UI elements. For more information, see Networking and Web Services Overview for Windows Phone.
The Windows Azure Toolkit for Windows Phone includes a set of client libraries that can be used in Windows Phone applications to more easily consume these kinds of services.
The OData client for Windows Phone also makes it easy to build applications that consume OData feeds. For more information, see Consuming a Windows Azure Data Service by using the OData Client.
This section covers important security considerations when creating Windows Phone applications that access Windows Azure-hosted resources. For more information, see Web Service Security for Windows Phone
Authenticating to Windows Azure Services
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.
Encrypt Communication with Windows Azure
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.
Protect User Credentials
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.
Guidance for Optimizing Windows Phone Applications and Services
Compared to other computing platforms, mobile devices, such as Windows Phone, have much more restricted set of resources. Mobile devices can have less storage, processing, and battery resources than laptops or desktop computers. In addition, device customers are also often paying for the bandwidth to access external resources, such as Windows Azure-based applications and services. It is important to keep in mind these constraints when developing Windows Phone applications that consume cloud-based applications and services. Network bandwidth is a primary resource constraint for mobile devices. Many mobile networks charge users for the amount of data downloaded to and uploaded from the device. Customers might not have a good sense of how much bandwidth is being used when they run your application. If your application causes a large increase in their monthly cell phone bill, it will certainly reduce its use and overall popularity. Also, the Windows Phone platform limits the amount of isolated storage your application can use, and your application can fail certification if it uses too much memory.
Here are some recommendations to optimize the various the factors, depending on your application scenario and customer needs:
Use Local Storage Responsibly
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.
- 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.
- 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.
Check for Connectivity
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.
- 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.
- When users disable access to certain network connections or to background tasks, it might affect the performance or functionality of your application.
Use JSON for Exchanging Data
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.
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/jsonas the Accept request header. You can also specify a query option of
$format=jsonin 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.
- 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.
- 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).
- 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.
Devices and mobile applications highlight the strengths of a cloud-based platform. The Windows Azure platform and Windows Phone have been engineered to enable you to provide customer of your Windows Phone applications with flexibility and power. Now it is up to you to have great ideas, design great apps, and provide useful data to your customers.
For more information about Window Phone, see the AppHub portal page.
For more information about the Windows Azure platform, see the Windows Azure portal page.