My name is Lestat. I am an iOS software engineer and I'm here to talk to you about integrating with Facebook, Twitter, and Sinai Weibo on iOS and OS X. So let's get started. So far this week you've been fire hosed with a lot of announcements, I'm sure. So we're going to start by just having an overview of the lay of the land on iOS and OS X, see some of the new social features that we've brought to both platforms. On iOS 6, you're all familiar, I'm sure, with Twitter integration, which we added in iOS 5. And in iOS 6, we have finally brought the long anticipated Facebook integration.

And-- For our Chinese customers, we have added integration with Sinai Weibo, which is a Chinese microblogging service. On OS X, Mountain Lion, we brought Facebook, Twitter, Sinai Weibo, and in addition, we brought Flickr, Vimeo as social sharing options and a few other social services that are popular in China.

What does that all mean to you? You are developers and you're sitting here wondering what that integration means to you and your apps. So I've prepared this diagram to kind of help us look at the world as it is now and how you can benefit from these integration features. So on one hand, we have shareable content. This is user land.

They have text, movies, files, they have media, all provided by your apps. And on the other hand, we have social networks like Facebook, Twitter, and Weibo. And your app is sitting there in the middle, right? Your users are using your app and they are interested in sharing some aspect of their experience of their app with the world. This is the 21st century. We live in an age of social media. And you can be sure that people want to do that. So you all know people love your apps. They download them by the billions from the App Store. For both iOS and OS X.

And if you want to deliver a more modern, a more compelling and engaging experience to your users, you have got to do social integration. This is the thing that's happening now. So how is it that you can enable your users to share content seamlessly with social networks? And how can you get information from those social networks, information from that social graph, and deliver it to your users to give them a better experience? And I know many of you are are clear sort of on the sharing aspect but might not be so clear how the arrow goes the other direction. And an example I can think of right now is Flipboard. It's a great app.

You know, it shows you, like, your RSS feeds or New York Times or whatever newspaper, very nice, great UI. But it also does something great. It gets your Facebook or Twitter feeds and it shows them to you, delivers them as newspapers that you can read in the morning.

Very relevant. Very direct. A great example of how you can bring the social graph to your your users and make great apps. And there are many other examples out there. So you're wondering why do I care if I already have social integration? Well, we're going to show you our APIs that will make your life a lot easier. You can adopt these APIs and you will have More maintainable code, simpler code, lots less of the code.

Let's see, what will you learn? This is sort of a very broad agenda. Our first half of the talk is going to deal with what I'm going to call UI integration. I'd like to clarify the term now because I know it can be a little vague. UI integration is basically anything you add that is a UI element, a view controller that will let your users share on social networks.

We're going to cover how to do that both on iOS and on OS X. And then we're going to talk about advanced integration in the second half of the talk. And you can think of advanced integration as just the way you get access to a user's account with their permission. And then you can use that account to communicate with the service directly. So you can, if you want to talk to Facebook API on behalf of the client, get information from their Facebook feed, that's the section you really want to listen to.

So let's do a quick overview of UI integration. There's a lot to talk about, so I want to summarize from the beginning, give you the TLDR version. Back to that diagram, your app sitting there in the middle, you're wondering, well, what API is it going to use to make my app UI integrated? And the answer we're going to give you to begin with are these two APIs, UI Activity View Controller on iOS and NSSharing Service Speaker on OS X.

And the really great thing about those APIs is that they're going to hide all the details about what the content being shared is and where it's going. So you don't have to worry whether the person is sharing a movie and is that going to be uploadable to Twitter or maybe not, maybe it's Flickr. You don't have to worry about that.

You don't have to worry about what networks are available, what integration is available on the device and how it fits with the content. And there's a lot more benefits to using this built-in UI, not just the ones that I mentioned. You are creating a very, very consistent user experience by adopting those APIs.

Your users will open the app and if they want to share something, they're going to see the Facebook sheet that we built in every app. They're going to see the tweet sheet. They're going to recognize that UI immediately and they're going to be able to use it. And people love that. It's attractive UI. It's present everywhere. It's familiar. People trust it and they will use it.

And you're making use of Single Sign On. What that means is that user has entered their password once in settings and they don't have to keep entering it every time an app wants to access their account to post. So what you get from that is not just that it's a one-time password entry, you're getting automatic credential management. That means the user goes on Facebook, changes their password, you don't have to worry about that. We take care of prompting them again for their password on the device so that you can continue to share without worrying about these details.

Another benefit is that it's really easy to integrate. You'll see in the next few slides, often all you need is like four, three, four, five lines of code. Not sure exactly how much it is, but that's all you need to integrate a view controller into your app that will let your users share. So maybe five minutes of work, that's it.

You can even take the code samples that we give you, copy paste them, and they're almost ready to use. That's how easy it is. And you get improvements over time. So that's the it's all in the SDK. You upgrade your SDK, you link against it, and you've got a new UI, maybe a bug fix. It's all great for you for free.

So let's get started with the iOS part of the integration. And in this talk, we're going to start with UI Activity View Controller. And for the purposes of explaining how this View Controller works, we're going to use a demo app called Daily Cat Facts. Some of you might have heard of the Cat Facts meme. This is going to play on it a lot.

So this app basically gives you a daily cat fact, as it's called. And there's a picture of a cat there just for fun, because I want to share that cat. So I see that, and I just want to share that, right? So how can I do that? There's a Share button right there. It's sitting lonely in the toolbar at the bottom. Let's say the user taps that.

What they see is this. This is UI activity view controller. Notice how all the sharing options are there. Twitter, Facebook, Weibo, and a few other things that the user might want to do to share the picture and the text. And let's say they hit the Facebook button. That's what they get. They get the Facebook sheet. And it's already populated with the image that the user wants to share. It's populated with the text that the user wanted to share. All they have to do is hit post and there, it's on Facebook.

So how do you do that in code? That's it. That block of code is all it took to create what you saw, that UI experience. First we start by allocating a string, which is just hello world or whatever it is that you want there, your daily cat fact, for example. Then we allocate a UI image.

We use image name to get that image. And then we put the image and the text in an array using the new collection syntax in Objective C3. And then we take those activity items. We allocate a UI activity view controller. And then we pass those in as an argument. And that's all it takes. Next up, you just present the view controller and you get exactly that experience that I showed in the slides before.

For some of you, this might be a little too broad. Maybe you're not interested in supporting all these social networks. Maybe you do care about integrating specifically with Facebook, with Twitter, with Weibo. And for you guys, I would recommend targeted integration. And we have APIs that support that.

So, you might remember the tweet sheet, right? From iOS 5. We have equivalent sheets like the Facebook sheet that you guys just saw a minute ago. And we have the Weibo sheet, which is similar to the tweet sheet. And if your app wants to integrate one of those sheets only, that's definitely something you can do.

In the past, the Twitter framework that we shipped in iOS 5 enabled you to do that. So you had a TW Tweet Compose View Controller that you would present and there you go, you got a tweet sheet. But the Twitter framework is now deprecated and we'd like you to move away from using TW Tweet Compose View Controller. Instead, we're going to deliver a new framework that supports all of our social integration features.

So say hello to the Social framework. The Social framework, you can think of it sort of as an expansion over the Twitter framework. So here's Twitter and here's Social. It not only supports Twitter, it's not going to give you APIs specific to Twitter only, its APIs will also support Facebook and Sinai Weibo.

And the one thing I want to first stress for this part of the talk is that you're going to want to learn more about SL Compose View Controller. That's the API that's going to help you display the tweet sheet, the Facebook sheet, or the Weibo sheet. And to do that, all you need is just to use this factory method, a class method on SL Compose View Controller. It's called Compose View Controller for type.

So how do you use that? You're going to have to specify a service type, right? That's the one parameter it takes. And there are three different options. If you want to display the Facebook sheet, you would start with SL service type Facebook. If you want to display the tweet sheet, SL service type Twitter. And for the Weibo sheet, you would use SL service type Sinai Weibo.

Now how do you present an SL Compose View Controller? Again, the code is very simple. You start by using the factory method that I just mentioned, Compose View Controller for type. And here we're trying to get a Facebook post sheet. So what we're going to do is give it SL service type Facebook. Then we will set the initial text on that View Controller.

And then we add an image to that view controller using add image. And finally, we present it. And that's all it takes to just show a Facebook post sheet with an image and text in it. Now for UI integration on OS X, I'd like to welcome Julien Robert to the stage.

Thank you Lestat. Hello, my name is Julien. I will show you how easy it is to add some sharing capabilities to your application running on Mountain Lion. First thing I want to talk about is the share menu. So the share menu is the class NSSharingServiceSpeaker. And it displays a menu as you can see.

But the good thing about this list of menu is that it will only show the services that make sense. So what does it mean? It means that it's based on what you want to share, but also what accounts are configured for the current user, as well as in which region the user currently is. Also, this menu can be customized. You can remove some services that do not make sense for your app, but you can also add some entries to this menu if you want to plug existing services that you may have already in your application.

And finally, I want to stress that this is the easiest way to share. And as you see, it's a class that is in AppKit. So you don't need to link against any other framework. And even better, if your app is sandboxed, you don't need any entitlements because everything is done out of process.

So once a user will pick a sharing option, what happens? Well, we'll display what we call a share sheet. We have one for Twitter, another one for Facebook. So you can see they are very similar to the iOS counterparts. But we support a few more services, like you can easily upload some photos to Flickr. But also you can easily send some pictures or movies to your friends on iMessage. And also bigger fries over airdrop on a local network.

Let's see the sharing architecture. So this is a schema we saw earlier with the shareable contents and the social networks. So you would give the shareable content to the picker, and the picker has a list of sharing services which points to social networks. So the thing to note is that the sharing picker has a delegate, but also each service has their own delegates.

But first, let's see what can you share. Well, it's easy. You can share any basic types such as images, text, which can be attributed or not, as well as URLs, which can be local URLs pointing to files on your system or remote URLs like for websites. But you can also use your custom object providing the implement and writing.

So now let's add this sharing menu to your app. So what do you need to do? First, create this button. This is a standard button, and we want all share buttons to look the same. On click, you will present the picker. And then when the user will pick a service, you will want to specify a delegate for this service. And finally, implement some delegate methods. Okay, now let's dive into the code and see how to create this button. So it's a regular NS button. But we have a shared template image that you can use to add this arrow.

An important detail is that since we are displaying a menu, the menu should appear on mouse down. And since the default action of a button is on mouse up, you have to specify that you want it to be called on mouse down. Then we set the targets and the action of the button. And now let's see the action of this button. So first, we gather what we want to share in an array of items.

Then we create the picker from this array. We set the delegate to be self. And finally, we ask the picker to be displayed. So it's displayed relative to a rect in a view. But in this case, we want it displayed relative to our button, which is sender. And another rect means bounce. And then preferred edge lets you display the menu above or below the button.

So let's go back to our previous schema. So we've seen that the picker has a delegate and when the user will select a service, the service needs a delegate too. But where is it coming from? Well, the delegate for the service is given by the delegate of the picker using this delegate method.

Okay, so now we've talked a lot about this delegates, but what is it, what it is used for? Well first, the delegates will allow you to be aware of what's happening with the sharing. So you will be called when the share sheet is displayed with a will share item. But also, when the sharing did complete successfully, with the did_share_item delegates method.

But since bad things can happen, we also have did_fail_to-share_item method with an error. And you may want to display the error somewhere in your UI. But you need to special case the NSUserCancelledError, because it means that the user just cancels the share sheet. So don't display an error in this case.

But the delegate of the service also is useful to make sharing a beautiful user experience by animating the share sheet. And for that, we need a few information from your application, like the item of the-- the frame of the item that you are sharing, if it's an image. But also a transition image, the source window, and the content scope. But before going back to all that, I would like to do a quick demo so that you have a better idea of what I'm talking about. OK, so this is a very simple recipe application.

We have recipes with images. We want to share that, like to invite some friends for dinner. So I cheated a bit. I already added a button here that I created with the -- I set the template image that we've talked about. But for now, as you can see, nothing happens because there is no code in the action of the button.

So let's go into the code. And before implementing the action, the first thing we want to do is to call this action on mouse down. So let's do that when the application finishes launching. Okay, so now the action will be called and now it's done. And let's implement it.

So it's here. The first thing we want to do is get the current recipe to gather the items we want to share. So in this case, we want the name of the recipe, the image that corresponds to this recipe, and the contents, which is a description of the recipe. Then we create the picker. We need it with the items we just created. We set ourselves as a delegate of the picker. And finally, we tell it to be shown relative to the button. OK, so it's very simple. Let's run now and see what happens.

So now you can see we have a menu of all available services. And I can pick one, like for example, Twitter. And we have a tweet sheet that appears. But as you can see, it's not very nice because it's not bound to the window of our application. And there was no nice animation. So let's see how we can improve that. Well, first we want to set a delegate for the service. So for that, we use a delegate for sharing service method that we've seen earlier.

And now we are the delegate of the service and we can implement the animation delegate methods. The first thing is we will return the frame of the image. And since we already support Quick Look, we have a convenience method that we can use to return this frame. Next, we want to return a transition image.

And this will be the image that is shown in the button. And finally, We want to return the source window, which is self window, as well as the content scope. And we'll talk about the content scope later. And now if I run again, And I want to tweet. We have a nice animation. And we can send the message.

Okay, so let's review what we did to have this nice animation. Well, first, we provided a frame for the image using the source frame on screen delegate method. And the frame should be in screen coordinates. Second thing we did is provide the transition image. And as you can see in the delegate method, there is this content rect.

But what is this content rect thing? So for example, if you use quick look to generate a thumbnail, the image you would return is this thing. But as you can see there are borders. And the content rect corresponds to this area, which is the core of the image without the decoration. So again, if you use quick look thumbnail, you can get this frame using the get content rect function.

Next, we implemented this method to return the source window, but also you saw the content scope. And let's talk more about content scope. So content scopes are hints for us to tweak the share sheet animation. So you will declare from the context of your items so that we make the best animation possible.

For example, if you share some items that are in a list, like files in the browser, you would use an item content scope. But if you are sharing something that is part of a bigger content, like an image in a document, you would use a partial content scope. And finally, if you want to share the whole document, you would use a full content scope. So if you implement that, this will make sure that your animation looks as good as possible.

But maybe the sharing picker is not what you need. And for that, you need more targeting integration. Example is if you want to customize a trigger UI, like in this example, it's a custom contextual menu. Or if you want to target a specific service, like if you want to add a tweet button in your application, you can use a sharing service directly. And of course, when the user will call NS serving service, it will display the same share sheets as we've seen before, including the animations will be used if you set the delegate.

So how to do that? So it's very easy. So when your trigger URL is clicked, so for example when the button is clicked, you will get the sharing service that corresponds to the action you want to do. In this example, if you want to post on Twitter, You set yourself as a delegate for the service. And you just call perform with an array of items that is the same array of items that you use for the picker.

You may want to enable your control conditionally, like to disable the tweet button if there is no Twitter account configured. To do that, you can use the can perform with items method on the service and it will tell you if it's possible to share with this service or not. And that concludes the OS X part of sharing. And Lestat will continue.

So let's recap the two important points we've talked about in the first half of the talk. If you want a beautiful, a simple, a seamless sharing experience in your app, on iOS all you have to do is present a UI activity view controller and an OS X and NS sharing service speaker. And that's really all there is to it.

Now let's jump into advanced integration. And this is really the exciting part of the talk. This is for the ultimate integration experience. It will give you the power to access the account and will show you how to use that account to communicate with service APIs on your own. So there's really the sky's the limit at that point.

So here's a sample request. Sort of to ground us in this discussion, we're going to look at an example of what you can do once you have advanced integration. It's a very simple example. There's your app on one hand, and on the other hand, we have the Facebook server. And my app is going to try and get the me object from the me graph object from Facebook. So it's going to send a request to graph.facebook.com slash me. The server is going to get the request.

It's going to build my me object with information about me. And it's going to send that request to me. And it's going to send that back to your app. Now, if you've ever done that in real life, you know the cake is a lie. This is not how it happens.

This is completely oversimplified. So what you're going to have to worry about is how you're going to authenticate with the service. You're going to have to set up your request properly. There's a lot more than there is in that slide. But what we're going to show you with the APIs that we have, it will be almost that simple.

You will feel as if you just animated one little object from one side of the screen to the other. That's how easy it will be. So let's get started. All right. I want to just do a quick overview because there are three main sections we're going to deal with.

And the first is going to be how to access user accounts. Then after we see how to access user accounts, we're going to talk about how to construct requests. And finally, we're going to have a quick discussion of permissions. And this is mostly geared towards people who want to do Facebook integration because it's a little more nuanced than it would be with Twitter and Weibo.

So the social framework that we just introduced a moment ago not only gives you SL ComposeViewController, it also provides a class called SLRequest. And I want to just take a moment to, I think many of you may have seen the deprecation sign and gone like, "Oh my god, don't worry.

You only have to change prefixes in 90% of the cases." TWRequest and TWT ComposeViewController are very similar classes, so transitioning will be very easy. Anyway, for SLRequest, you are going to be able to talk to Facebook, Twitter, and Sinai Weibo. So it's a more generic API. It's a lot more flexible. It's a lot better than TWRequest.

And to use it, first you get the user's account. You request access, actually. You need their permission, of course. And then you get the account. And then you create the SL request. And you provide it with the account. This is a very important step. That's where you associate the account with the request.

And that's how we know to authenticate the request for you. And finally, you send the SL request. You wait for the response to come back and continue your app's behavior as usual. So to access user accounts, and this is step number one in the grand scheme of how to request something.

You'll need to become friends with the accounts framework. That is where all accounts, all social accounts are stored on iOS and OS X. And in order to get access to accounts from that framework, we provide a method on AC Account Store called Request Access to Accounts with Account Type with Completion Handler. And we'll see how to use that in just a moment.

Now for Facebook, you're going to need to add a special dictionary in your info.p list. We're going to cover that in detail once we get to the Facebook section of the talk. But for now, just keep that note in mind because it's really important. Otherwise, you will not be able to get access.

Now let's look at code. This is how you get a Facebook account. Not a whole lot of code. You just have to do it once and then you're good. First you start by allocating and initializing an account store. And I would like you to note how that account store is actually a property on the class I'm in. And that's really important because the lifetime of the account store is tied to the accounts that it vends.

You should not release your account store when you're just done requesting access. It needs to live for as long as the accounts live. All right? So then we get the account type object. Very simple call. We just say account type with account type identifier. We pass in the string identifier for Facebook.

Then we go on to call the request access method. We pass in the account type object we just got and then we pass in a completion handler. And that completion handler is going to take two arguments. It's going to provide you back with two arguments. One of them is going to be a Boolean and it's going to say, "Yes, you were granted access" or "No, you were not granted access." And then the second argument is going to be an NSError object that will contain information about anything that may have gone wrong during the request.

Now, if you were granted access, hooray, all you have to do is just call accounts with account type and pass in the account type object that you got a moment ago. And then you have an array of the accounts that are on the--that have been added to the device.

Now, for Facebook accounts, this is not true for Twitter and Weibo, but for Facebook accounts, on iOS and OS X, there's only one account per device. So you can call last object on that array and you've got a Facebook account ready to use. So we're going to hold that in our property and self.facebook account and we're going to get back to it in just a moment.

So to build your request, you've got your account, right? That's great. You initialize your SL request instance. You're going to have to have a URL. You need to know what you're going to talk to on the server. You need to have an HTTP method. You need to know what that endpoint accepts. Is it get? Is it post? Is it delete? And then finally, you're going to need to know what parameters that endpoint is expecting. And this may be a nil dictionary. It might be a dictionary of several parameters.

And finally, you set the account property on the on the SR request. That's where the association is happening. I can't stress how important that is. And then finally, you perform it and handle the response. So the reason I keep stressing this is that the association between the account and the request is what allows us to take care of the signing the request for you. And I'm going to show you how to do that. So let's go ahead and start with the OS. So the OS is a service that allows you to authenticate your code. And that is awesome.

It just you cannot imagine how much code goes into writing a lot of one or two implementation. And how many bugs get written fixed just to be able to authenticate a request with a service. And we're going to do all of that for you. So many of you might be familiar with the We're calling the OS sandwich.

And it's basically your app on the top and the top one and the bottom one. There's the API for Twitter, Facebook, or whatever you want to talk to you. And there's all sitting in the middle all the time because you need to authenticate with a service somehow. And that's the way it works. So the OS is a service that allows you to authenticate your code. And that's the protocol everyone's adopting. And we know how much fun that is to implement.

But when you use SL request, that's all gone. You don't have to worry about it anymore. Yeah, I heard that. You've written the code before. So how to access a user's profile. That's the example we sort of started with at the beginning, if you remember, my me object. And now I'm going to implement it in code. And look at all that. It's like four or five lines. Nothing more is needed. First, you get your URL. We already know what it is. Graph.facebook.com slash me.

And then we use the class method on SL request to get the object. So we use SL service type Facebook. That's the service type we used to get the Facebook sheet, if you remember still. And then we pass in the method get because we're going to that's the HTTP method accepted by that endpoint. And then we give it the URL. And there's no parameters necessary for that endpoint.

So we just pass nil. Then we associate magic happens behind the scene. And we perform the request with this handler. And the handler is going to come back with it's very similar to the request. So any URL handle handler. So you're going to get NSData, which is a response from the server. You're going to get an NS HTTP URL response describing the response from the server with things like the HTTP status code.

And finally, we're going to get an NSError object indicating if an error happened or not. Now I would like to demo the great APIs for account access and for SLR request. And for that purpose, we're going to use the app daily cat facts. We're going to see an improved version of that by my colleague, Kal Haglunds.

So, hello everyone. The app I'm dev'ing today is, as Lestat said, the Daily Cat Facts. So the purpose of Daily Cat Facts is to give a nugget of cat information to the user every day. So you already have this app installed in the iPhone simulator. Just dive in and see what this looks like. So here you see the daily cat facts app. And at the top, you see a kitten. Its only purpose is there to be cute. And below the kitten, you see a cat fact.

Did you guys know that a cat can jump up to five times its own height in a single bound? I sure didn't know that and we'll see that my immediate urge is to share this amazing fact with my friends on Facebook. So to do that, I've added a button below the fact.

But if I press that button now, nothing happens. That is because even though I wired this button up to call a method in my view controller, there's no code in there yet. So, how can we make this app a social app? Well, first I would like to point out that this app would be a prime candidate for the U Activity View controller. It would be very easy to implement that.

But for the sake of this demonstration, we'll do the deeper integration here and try to post this fact directly to the Facebook timeline. So the first thing we need to do is to add the dictionary with keys into our applications plist. So let's start Xcode and see how we'll do that.

So now we're in Xcode. Let's try to locate my application plist. And I drop it right in here. As you can see, I added a dictionary with the key AC Facebook Client Access Info. If I open this dictionary up, you can see there's a bunch of keys in there.

I won't go over them in detail now because Lestat will do that later. But I would like to point out that this dictionary in the P list is only for seed one. In a future seed, you'll pass this dictionary in with the request to the account store. I will show that later.

So, now that we have the dictionary in the application's plist, let's go and try to request access to the account. To do that, I open up the view controller for this app. And here you can see I have my post method. This method is the method which is called when we tap the button in the user interface.

So to start up, we are setting the status label at the bottom of the app to waiting for authorization. We then check in for our account stores, Neil. If it is, we allocate it into the new account store. And as Lestat said, it's very important to keep this account store around as long as you're using the accounts you got from that account store. We then go ahead and fetch the Facebook account type from the account store.

If we have that Facebook account type, we can request access to the account. We do it by calling request access to accounts with type, we pass in our type, and we pass in a completion handler which will be called when the user has made a decision. So in that completion handler, we check for success. That means that either we already had access or the user pressed OK, I'll show that later.

If you're successful, we set a status message so you can keep around for later. And then we go ahead and fetch the Facebook accounts from the account store with accounts with account type. And as Lestat said, there will only be one Facebook account on the device. So here for simplicity, I just go ahead and fetch the last object from that array.

When we have that object, we'll be posting the cat factor to feed by calling in the post cat factor feed method. Also, we have to handle the failure case in case we don't have access to user press no or something like that. And you probably need some more intricate error handling here, but keep it simple for now. So if I scroll down now, you see there's no code in the post cat factor feed method. But before we implement that, let's build and run the app and see what it looks like.

So here's the daily catfacts app again. It looks as it did before, but when I hit the post to Facebook button, You see that a dialog pops up. This is the accounts framework asking the user if it's OK that this app uses the user's Facebook account. And we want to post this cat effect to the timeline, so we just press OK.

If you now go into the settings app, and go into the Facebook section. You see that a daily CatFacts app is listed. This means the user can turn on and off access at any time. The users are in control. So let's see how we can implement posting to Timeline in our app. Open up Xcode again.

We start by creating a dictionary with the parameters we want to send to Facebook. In this case, this is the message parameter, and we have set a value to cat fact. Then we create a URL which points to the endpoint we want to talk to on the Facebook platform. In this case, this is the Me Feed endpoint.

Then we just go ahead and create a request. We're calling it request for service type. We pass in as a service type Facebook. This is an HTTP post request, so we pass in as a request method post. We pass in the feed URL we just created and the parameters dictionary we just created.

So, very importantly, we then set the account property on the request so the request can authenticate itself against the Facebook platform. Then we simply call perform request with handler and In the completion handler, we should probably check HTTP status, check for platform errors. But in this case, I'm just going to set the status label text to fact posted to Facebook.

And please note that I'm dispatching this to the main thread in the app. That's because any completion handler in both the accounts framework and the social framework will be called an arbitrary thread. So if you want to do UI updates, you have to dispatch that to the main thread. So let's build around and see if this works.

So now when I press the post to Facebook button, we won't get an alert because the counselor has already asked us about that and it remembers that we gave it access. Press post to Facebook. And set fact post to Facebook. So let's go in mobile Safari. and as you can see, the fact was posted to my timeline so all my friends can see it. Thank you very much and I would like to welcome Lestat back up on the stage.

Thank you, Kal. That was a great demo. Don't you just love it when people can spam you with daily cat facts every day on your Facebook wall? We're going to get to the section with dealing with permissions, but. Since we're running really tight on time, we're going to have to go a little too fast for some of you guys. You might not appreciate how fast I'm going. Our lab is just after the session. Please feel free to come talk to me if anything is unclear.

So you may have been tipped off by that more info button in the access request that there's something to Facebook permissions that's not as clear as maybe Twitter or Weibo. And so you do have to handle access to Facebook accounts with a little more nuance than with Twitter.

And the reason is people put a lot of personal information in the Facebook accounts, maybe a little more than Twitter. So access to those accounts is protected in a more fine-grained way because you kind of want to tell the person what it is you want to do with their account.

Most people will not feel comfortable just handing you over access to their account and you can do whatever you want. There's a lot of potential for misuse. So you have to tell us what permissions you want for that account. You have to tell us what you intend to do with it and we're going to pass that information onto the server so that Facebook knows what you're planning on doing with the account.

And those permissions are all documented on Facebook's website. You'll see an example of them in the slides, but there's a lot of them and they're very well documented on the Facebook developer website. So the Access Dictionary that we've been keeping mysterious for so long. Finally, we're going to get to it.

We're going to talk about it a little. It's something that you have to pass under AC Facebook Client Access Info in your InfoP list only for Seed 1. So for those of you watching this in the future, do not put this in your InfoP list. This goes as a parameter in the access request method.

Now, the Access Dictionary is pretty simple, just four keys. The first key is App ID, just pass in your Facebook App ID, that's on the website. The second key, don't worry about it, it's going to become optional in C2. It is for those who are planning to do more of an advanced integration and they have to deal with different platform versions. Most of you will not have to care about this and you won't have to enter it C2 and onward.

The next key is the permissions key and that's where you enter an array of the permissions you're requesting from Facebook. Now, this is the one we use for daily cat facts. The permission is called publish stream and it means we're going to write to the user's timeline. And that's the only thing we want to do with the account, so that's the only permission that we requested, but you may request more.

Finally, AC Facebook permission group key is the last parameter you have to pass and it needs to describe as closely as possible the permissions that you are requesting in that array. So there are three values. There's read, there's write, and there's read write. And you pass in a value, basically we're going to talk about how to determine the value, but conceptually speaking it's simple. You just describe what you're about to do with the account, what permissions you're requesting. We want to write to the timeline, so we just pass in write.

Now, how do you choose it? I prepared a few examples to help you get the right permission group. If you want to use permissions like user about me, basically read anything from the user profile. Or if you want to read from their friends' profiles, or if you want to get a list of email addresses, you should be passing in read.

Now, if you want to do things that write to their profile, like publish actions on their behalf or publish things like status updates to their stream, then you need to use the permission group right. And if you want both kinds of permissions, you would pass in read right.

Pretty simple. Now one tiny caveat is you can't request all permissions right now in Seed 1. There are some permissions labeled as extended permissions and those you can't request in your Info.plist. So this includes reading the entire user's timeline. And this is a little different from reading status updates or some items that they post.

Reading their timeline includes other friends posts and so that's why it's labeled an extended permission. Or managing pages on the page. So you can't request all permissions on their behalf and a few other permissions that are going to be documented online. And this may or may not change in the future. Just stay tuned. We're working on it.

Right, so the last topic that's Facebook specific is you need to make sure that you always have access to the account. It's not as clear as it might be with Twitter and Weibo. And Kal actually showed you one way you might lose access. If you go to settings, if the user goes to settings, they might flip the switch on your app, right? And then you can't access the account anymore. But there are other things that might happen. And every app basically gets issued a token when they request authorization to access the account. And that token will expire. And when that token expires, you need to be ready. And I'm going to show you what to do.

Also, the user can remove your app from the Facebook website. Every profile, there's an apps tab. You can go there and hit X next to any app you want. It goes away right away. So, and finally, there's also the switch in settings. Keep that in mind. So, what do you do? The way you find out that you lost access most of the time is you get an error 190 when you send a request to the Facebook API. And that comes back in the NSData. When you serialize that to JSON or whatever your preferred format is, you're going to see an error object in there.

And it's going to have code 190 in it. And what you need to do at that point is you renew your token by calling an AC account store method whose name is renew credentials for account with handler. You pass in the account. You pass in a completion handler. In the completion handler, you're going to get one of three results. One could be credential renewal renewed. That's great. Your token had just expired. That's normal. We renew it for you. Great.

Now, you may have been rejected by the user. What that means is the user has performed some action that indicates that they no longer want you to access their account. And that might be that they turned off the switch in settings or it might be that they removed you from the website. That's when you get that completion callback.

Finally, you might get renewal failed and that indicates that some sort of error happened beyond our control. You might try again and succeed. Now, if you have FB Connect already, some of you have integrated that with their apps. That's great. You'll be pleased to know that support will be pretty much automatic.

We're just going to update our own APIs in the next year to help FB Connect build on top of that. And there's going to be a major update to FB Connect soon enough that will allow you to just get automatic support. So there's really very little you have to do.

Now, if you need more information, please contact Paul Marcos or refer to the documentation online. I'm going to have to quickly go through that. For those of you watching online, just pause and get the links. And finally, just a summary before you guys leave of the things we talked about.

If you want UI integration, very easy. All you have to do is use UI Activity View Controller on iOS and NS Sharing Service Speaker on OS X. If you want deeper integration, talk to the accounts framework for access and then use SL Request to send requests to the service. And finally, if you have FB Connect, really, there's not much to worry about. You'll get automatic support. That's it. Thank you, everyone, for coming. I hope you have a great beer bash.