Developers – introducing our GitHub code sample library with samples for iOS, PHP, ASP.NET and more

Since releasing the latest version of our developer platform, we’ve gotten a number of requests for code samples on popular smartphone platforms such as iOS as well as for Microsoft technologies like C# and ASP.NET. Today we’re pleased to announce that we’ve created a code sample repository on GitHub that we’ve seeded with code samples for integrating data from SkyDrive, Messenger, and Hotmail into a variety of application types.

We’ve made available three broad classes of code samples on GitHub today:

1. Mobile client samples that show how to integrate user data into applications written in Silverlight and Objective C targeting the Windows Phone and iOS platforms.
2. A desktop code sample that shows how to integrate user data into applications written in C#.
3. Server-side code samples that show how to access user data using server-to-server calls when the user has given the application long-lived access to their data (for example, the application requested the wl.offline_access scope).

Mobile client samples

In my previous post, I discussed the Windows Phone sample, which integrates data from SkyDrive into a Windows Phone application. We’ve added an iOS code sample that shows how to integrate data from Hotmail, Messenger and SkyDrive into an application targeting the iPhone, iPod Touch, or iPad.

As with the Windows Phone sample, there’s a key step that involves constructing the URL to our OAuth 2.0 authorization end point, and requests the appropriate scopes required to access the data that the application is interested in:

   1: NSString *OAuthAuthorizeUri =@"https://oauth.live.com/authorize";

   2: //replace the ##### with your client id

   3: NSString *ClientID =@"client_id=##########&";

   4: NSString *RedirectURI =@"https://oauth.live.com/desktop";

   5: NSString *Scopes = @"scope=wl.basic%20wl.signin&";

   6: NSString *Display = @"display=touch&";

   7: NSString *ResponseType = @"response_type=token&";

   8:  

   9: - (NSString *) ConstructURI

  10: {

  11:     return [NSString stringWithFormat:@"%@?%@redirect_uri=%@&%@%@%@",OAuthAuthorizeUri,ClientID,RedirectURI,Scopes,Display,ResponseType];

  12:  

  13:     

  14: }

  15:  

Once the user has successfully signed in, they are required to provide consent to the application accessing their personal data:

If the user accepts, the application can then access and display their information:

We’re planning to look at code samples for other mobile platforms as we get demand for them from our developer community.

Desktop code sample

Integrating data from SkyDrive, Messenger, or Hotmail into a desktop application follows a similar pattern to doing so in a mobile application. The pattern of having an application hosting an embedded browser that redirects the user to http://oauth.live.com/desktop after navigating the user the constructed OAuth 2.0 end point URL is the same in both cases. The key difference is that mobile applications specify a display parameter with the value set to “touch,” which indicates a touch screen-optimized experience, whereas desktop applications do not. This difference can be seen in this URL construction code:

   1: static string scope = "wl.basic";

   2: static string client_id = "[YOUR_CLIENT_ID]";

   3: private static Uri signInUrl = new Uri(String.Format(@"https://oauth.live.com/authorize?client_id={0}&redirect_uri=https://oauth.live.com/desktop&response_type=token&scope={1}", client_id, scope));

   4:       

   5: public BrowserWindow()

   6: {

   7:      InitializeComponent();

   8:      webBrowser.Navigate(signInUrl);

   9: }

In addition, desktop applications likely will have an explicit pop-over experience when signing in the user and requesting permission to access their data as opposed to the inline experience in a mobile application:

As expected, once the user gives their consent, the application can access their personal information. In the desktop sample, we also show the access token in a window so developers can cut and paste it into HTTP requests to try out various API calls; for example, appending it to “https://apis.live.net/v5.0/me/picture?access_token=” to provide the user’s display picture:

Server–side code samples

Lastly, we’ve heard from a lot of developers who want to see complete code samples showing how an application that is actually making server-to-server calls to access a user’s Windows Live data should work. To address these requests, we’ve provided both an ASP.NET code sample and a PHP code sample. Both samples show how to use our JavaScript SDK to create a sign-in or connect button that takes the user through the process of giving consent to the application accessing their data when clicked.

In both samples, the redirect URL that the user is sent to after granting consent is set to the server-side ASP.NET or PHP page, respectively:

   1: // Update the following values

   2:    var client_id = "%CLIENT_ID%",

   3:         scope = ["wl.signin", "wl.basic", "wl.offline_access"],

   4:         redirect_uri = "%REDIRECT_URI_PATH%/callback.aspx";

Thus, when the user is redirected back to the corresponding ASP.NET or PHP page, the user gets both an access token that can be used to make API requests and a refresh token that can be used to request new access tokens. The latter is needed because the page requests offline access to the user’s data, which gives the application access to the user’s data while they aren’t logged in. However, since access tokens expire after an hour for security reasons, the application needs to refresh them periodically using the refresh tokens.

When the server-side code is invoked by the user redirection, the application can then save both the access and refresh tokens, which it can then use to access the user’s data without the user needing to be logged in.

Updating the code samples over time

We expect to add more code samples to this repository over time to cover more platforms and as we add more functionality to our developer platform. Let us know what you think of the code samples in the comments and what you’d like to see us cover in more detail in future releases. Thanks for your support, and please continue to keep the feedback coming.

Dare Obasanjo – Lead Program Manager, Messenger Connect Platform