wFace – windows phone 7 facebook integration part 1

This article shows how to use the Facebook graph_API (http://developers.facebook.com/docs/API) in a windows phone 7 (wp7) Silverlight application. All used tools are free software - for downloads take a look at the links at the end of this document.

The wFace – windows phone 7 facebook integration Series

This article series shows how to use the Facebook graph_API (http://developers.facebook.com/docs/API) in a windows phone 7
(wp7) Silverlight application. All used tools are free software - for downloads take a look at the links at the end of this
document.

The Idea behind

This article shows how to use the Facebook graph_API (http://developers.facebook.com/docs/API) in a
windows phone 7 (wp7) Silverlight application. All used tools are free software - for downloads take a look at the links at the end of this document.

We made a .NET iPhone
application using MonoTouch. The thing is a Rock Paper Scissors game (RPS).

A well known game I would
say. The special thing about our implementation is a tight Facebook integration.We hold a game server to store high-scores and allow internet playing. Instead of handling user
management ourselves we use Facebook to do this.

Further we post results (new rank reached, game won / lost) on the user's Facebook wall.

Since the code is .NET it
looks as if a port from iPhone to wp7 is an easy task. But there are some problems and differences between the two platforms. A part of the problems may disappear after wp7
(beta at the moment) reaches RTM.

The sample - and what’s missing

This sample consists of two parts. In part one I'll cover authentication. Part2 will be about data retrieval posting data to Facebook.

Missing things:

UIX. I'll use simple stiles to focus on content. The nature of Silverlight projects allows you to make the things looking cool without the need to "recode"
anything.

Excessive Error handling. In a real world application there would be "error pages" which provide meaningful user information. In this project we just show the plain
error messages.

Some experiences with Silverlight and .NET development. I'll only focus wp7 specific Silverlight topics. There are tons of good Silverlight articles on the web to
get the basics.

The “project”

Our project will have 2 screens, one "Main Screen" and a "Login Screen". In wp7 such screens are (there are other options to) "Pages".

Facebook integration - a closer look

The Facebook application

A Facebook application is a piece of information which interacts with the user. There are different types of application but they share some common information.

First
of all (and primarily important for us) imagine a Facebook application as a kind of contract between you (the developer) and the user (Facebook account owner). You identify
yourself via properties of the application and further (via code) you ask for permissions.

The user is redirected to a special page. At this point we get some kind of credentials for further use. This is a "token" which we further use to make calls to the
Facebook API.

Creating your Facebook application

To create your first Facebook application login with your Facebook account and visit http://www.facebook.com/developers/ - this is an application and you see a dialog as explained in paragraph 2 above.

Figure 1: Developer Application Permissions

After you allow the application access to your Facebook account you'll be redirected to the developers home page. Near the top
(right side in main content) is a button "+Set up new application". Click this to create a new application.

Figure 2: Create application part 1

Enter a unique Name and click "Create Application". An error may occur - ignore it (if it is not "Name not allowed") and follow the next steps.

Go
back to http://www.facebook.com/developers/ and notice that below the "+Set up new application" button is a list
of your applications. Click on your newly created application and make a note of the two fields "Application ID" and "Application Secret". You need these two values later in
your wp7 application.

Figure 3: Application Settings

IMPORTANT: those two values are confidential! Do not post them like I do here. I'll use this application for the article and delete it later. So again:
please do never publish these values!

NOTE

Do not change the application settings (unless you know how the things work) - the default is perfect to use it in this sample.

Create the wp7 application in Visual Studio 2010 (Express)

Create a new project

Don't worry - later I'll explain in more details what's going on behind the scenes. But at the moment just follow this guide. Select "File/New Project" from the menu to get
the following dialog:

Figure 4: New Project Dialog

In this case we use a simple "Windows Phone Application". Select a directory and give the thing a meaningful name. In the next step you should see a XAML file and a
preview of your application.

In simple words the things work like this: we provide the user a webpage (the page comes from Facebook) and there he enters his
credentials. We'll never get access to the credential values. Further we pass our "Application ID" (see above) to this page and last not least we inform the page about the
access we need.

You may notice a "publish_stream" value which is important for us to post on the users
wall. And we (just to show "extended profile permissions") will also ask for "home_town".

After this we will get an "access_token" which has to be passed to every API call
we make.

Our “desktop application” login page

From what we have learned on the desktop authentication page we need the following URL to provide the user with the appropriate login page:

The base URL including our
"Application ID"

https://graph.facebook.com/oauth/authorize?client_id=10181612...

next the "special redirect
url"

&redirect_uri=http://www.facebook.com/connect/login_success.html

followed by the application type (determines how login works)

&type=user_agent

further the layout of the page (touch or wap) is OK for devices

&display=touch

and finally the privileges we
need

&scope=publish_stream,user_hometownFacebook

The last step

After everything was ok we will be redirected to success page and retrieve the access token
http://www.facebook.com/connect/login_success.html#access_token=...&expires_in=... This kind of information (parameter) passing is known as "fragment".

Bug in wp7 beta

Unfortunately there is a bug in the wp7 beta which suppresses this value. Here are the details:

It is almost the same
as the "desktop authentication" except of 3 differences.

We do not set the type to "user_agent". No problem at all - we just don't pass the type parameter

We have to pass our "application secret". This is the real problem - normally we would never give a user access to this value. With web application it doesn't matter
- the value never leaves our web server. But for client applications we have to "ship" this value inside our application.

We have to make an extra call to get the "access token". We will do this in a very simple manner - no problem at all

Anyhow - this is a workaround so I hope with the wp7 RTM we'll no longer have a need for this.I also use the "special desktop authentication return URL" - it works also
in our case.I'll include the "bug free" code in this sample - so if the bug is gone you'll already have to uncomment it.

Our start page

Silverlight differences to other platforms

Wp7 Silverlight is some kind of Silverlight 3.0 with extra controls and some (a lot?) missing features compared to the "full version".

We have special support for the
application lifetime (state storage, extra events), access to hardware features (GPS, accelerator, Phone, ...) and the control set is different.

Important for our case -
we have a "PhoneApplicationPage" and a navigation framework.

Both things are already included in the template - so we just have to use them. The most basic controls (Grid,
Button, Text..., StackPanel, Image, ...) do also exist; so we don't take too much care about it and simply start coding our project.

The navigation framework

This framework provides us with the ability to navigate through our pages. The typical behavior is to open a page via a control (Button, List element ...) and leave it with
the "Back Button" - a piece of hardware which every windows phone 7 device provides.

Screen orientation

In general there are three possible orientations (unfortunately "reverse portrait" which exists on the iPhone is missing) - portrait, landscape left and landscape
right.

In our sample we'll only use landscape but the idea behind supporting different orientations is either a "fluid layout" or some "rearrange code".

Basic layout

"Metro Style applications" should have a common look and feel. On part of it is the information provided on top of a page. It consists of an application title and a page
title. Both elements do already exist in the template so (if you want) simply change these values.

Notice there is a grid "LayoutRoot" which holds a StackPanel (the
titles) and a second grid "ContentGrid" where we'll place our content.

Time to code

You can simply copy and paste the following XAML to your application. BUT - notice that you'll not have the used event handlers in your code behind (this results in XAML
errors). Either ignore them (we'll add the handlers soon) or got into XAML - delete the name of the handler, type a blank and intellisense will ask you to create a handler for
you.

Figure 5: Layout provided by this xaml

The buttons "Load User Data", "Post to wall" and "Show friends" will be handled in part 2 of this article series. Here we'll focus on
Login.

Navigate to the top of your XAML (place the cursor there) and via "Properties / Events" add a page loaded event handler.

So after all we have layout the
loaded event handler and our button handlers. This is the code:

Our approach is to load the "Login page" which shall (after a successful login) provide us with the "access_token" we need for further calls to the Facebook
API.

Understanding navigation

Although you can provide your own navigation framework we'll use the built in one. This works by removing the current page and loading the page we are navigating to.

Or
in other words - every page is created from scratch when we navigate to it. This is also true for the calling page. So navigating to PGLogin.xaml and coming back to the main
page after login means:

MasterPage is destroyed

PGLogin is created (loaded event)

PGLogin is destroyed

MasterPage is created (loaded event)

The problem now - how to pass parameters to / from PGLogin. The navigation framework works pretty much like HTML navigation, so we can pass "Query strings" and retrieve
them in a special event: OnNavigatedTo

Controls are not loaded in OnNavigatedTo

Be aware that controls are not fully loaded in this handler. So for an example a "webBrowser.Navigate" will fail with
an exception "must be fully loaded before you navigate..."

In our case we'll take a different approach - we'll keep the shared information (access_token) in a global static variable. The best place for this is App.xaml.cs (the
code behind App.xaml).

Select App.xaml in the Solution Explorer, right click it an choose View Code (F7). Add the following code;

Save and close the file.

Next let us navigate to our Login page - I assume you named it (like shown above) PGLogin.xaml.In MainPage.xaml.cs change the login
button handler to:

What are we doing here? We use the Navigation service and tell it to navigate to our login page. We don't care about coming back - you remember - this is done via
the "Back Button" on our windows phone 7 device.

Before we first run the application we will simulate a login. This has two reasons - first it is time to see something
going on - second this will show how we can intercept the "Back Button navigation".The reason for doing this could (for an example) be a data entry form where we detect changed
data, and ask if the user wants to save the changed data before he leaves the page.

Open PGLogin.xaml - place the cursor on top of the xaml and via "Properties / Events"
add a handler for the BackKeyPressEvent. Add the following code to the handler.

The only thing left is some kind of "Logged in signal" on our main page.Did you notice the text (second line from the bottom) on our Main page? "Login to
enable..."

So let's enable the buttons. Change the page loaded event handler to:

Run your application and check if the things work like expected. They should, if you didn't make a copy and paste error.

The Login Page

The best things come in threes

As on the main page we'll add 2 informational controls on the bottom of the page. And as real content we need a WebBrowser Control. Replace you PGLogin Content grid with the
following markup:

Remove the BackKeyPress handler from PGLogin.xaml

This is important else it would override our access_token.

Notice that I set IsScriptEnabled to true on the WebBrowser control. The Facebook pages use a lot of scripts and by default scripting is
disabled. So in order to have functional pages we need to enable it.

URLs URIs and more

The whole Facebook API access is done via "web links". Silverlight wants to have URIs instead of URLs (strings). And we'll need a lot of them. So I decided to create a helper
class which provides those URIs.Since we'll need other helper classes for part 2 of this article series I first add a folder to the solution, so the things are better organized.
Right click you project in Solution Explorer and add a folder call "HelperClasses".

Next right click this folder, choose "Add / Class" and add FBUris to the project. The
project should now look like this:

Figure 6: Project tree

Our
FBUris class will provide us with well formatted URIs. I decided to make the class static.

Please ensure that you use your own application Id and application secret

The used values are no longer valid - I deleted the application.

Don't take too much care about the TokenLoadUri and GetAccessTokenURL - I told you above, that we need a third step to retrieve the
access_token since we have to use "web authenticate". I'll explain this later when it takes place in our code. Notice also that I provided the "not bugged" URL as
comment.

The rest is pretty simple - the changing parts of our URLs are marked as "string format placeholders" {x} so that we can pass these values as
parameters.

Now that we have got our "navigation addresses" (URIs) easily use them in our code. The first thing we want to do is to load the Facebook login page into our
WebBrowser control. A good place to do this is the PageLoaded event handler. Add a Loaded event handler to PGLogin and change it to:

When you run the application our login page should look like this:

Figure 7: Empty login form

After entering your credentials, click login and you'll be redirected to the "application permissions" page:

Figure 8: Application asking for permissions

Scroll down (drag content) and you'll find the "allow / Don't allow" buttons. Don't press a button now - just close your
application.

You see, it was pretty easy to get this going - now comes the (a bit) harder part. In a "bug free" situation the things are easier - but we have to do a bit
more.

Reading the Facebook documentation (in this case for Web-Login) we learn that

If the user authorizes your application, we redirect the user back to the
redirect URI you specified with a verification string in the argument code, which can be exchanged for an oauth access token.Exchange it for an access token by fetching
https://graph.facebook.com/oauth/access_token.Pass the exact same redirect_uri as in the previous step:…

So (for a web application) this means to place the "redirect
URL" to a page at your site where you check and use the parameter sent to the page. But we have no web server - we have a windows phone browser control.

Fortunately there is an
event when the WebBrowser control loaded a page. Goto XAML of PGLogin, locate the WebBrowser Control and inside the tag type LoadCompleted= - which brings up
intellisense and allows you to add an event handler. The LoadCompleted event fires when the WebBrowser finished loading a page.

This event handler has a
parameter of the type "System.Windows.Navigation.NavigationEventArgs". This class has a property called Uri - which represents the address (and parameters) of the page the
browser loaded.

We could simply use the "Fragment" property of the Uri to check for the presences of
such an address.

If it is there we parse the fragment - and get our access_token - done.

To get the "bugged" version going we simply check if we reach an address that starts with the expected value and behind this the "code" can be found. So the handler
should look like this:

For the first step we just display a message that we got the code - and in the last line (blue one) of our form we display the code itself. There is no need to
lower the URL - but I prefer this. Maybe Facebook decides to forward to the same URL with different casing...

Web authentication get’s a code and has to change this to an access token

As I told above there is an extra step to obtain an access_token needed with
workaround. This is how it works.

The code is no help at all for us. For web applications to retrieve the (needed) access_token it requires an extra step which must provide the applications secret and
the (just received) code.

In the class FBUris we already have a method which builds this request for us. The URL looks like this:

First again a URL where we pass our
application ID

https://graph.facebook.com/oauth/access_token?client_id={0}

then we must provide the exactly same URL as in the call before as
redirect

Instead of sending the access_token as a parameter this value is passed as content of the page. So we
could also use a web request to do this. But since the browser is already there we'll use this guy to do the job.

So again we check for this page - but this time without
the parameter ?code=…

When we find it we access the page content and parse it for the access_token. The content of the page looks something like
<HTML><BODY><PRE>access_token=….</PRE></BODY…

The final code has a commented option. In fact it could be a good idea to just bring the user away from this page to where he came from
(NavigationServices.GoBack()). So PGLogin would act like a login dialog which closes when the login is done.

Let's make a change in the MainPage Loaded
event handler. It will display the access_token instead of "OK".

This ends part one of the article series. In part two we will retrieve and send data using the Facebook API.

The wFace – windows phone 7 facebook integration Series

This article series shows how to use the Facebook graph_API (http://developers.facebook.com/docs/API) in a windows phone 7
(wp7) Silverlight application. All used tools are free software - for downloads take a look at the links at the end of this
document.

This project is great.The only problem is the Telerik components.I had to clean all these components out and in doing so some parts do not work. Any luck of someone posting the project without using Telerik components?!

Hi I have made an application that will upload a picture on facebook.. It is working fine only after i login. Means if i am trying to upload a second picture from same login it is returing "server not found error". I need to login again for uploading second time. Is there any problem related to access token?