Android Pointers: User-access tokens in the Facebook SDK 3.0

(Page 1 of 3)
Facebook offers developers a great way to personalize user experience with the rich data we expose through our API. To keep this information secure, and to ensure that our users know exactly what they're sharing and with whom, most API calls must be signed with an access token. Each access token identifies your app, the current user, the permissions they've granted your app, and the token's own expiration date.

You'll also need a new token if:
1. You change the permissions you require from your user
2. The token expires
3. The user changes his or her Facebook password
4. The user logs out of Facebook
5. The user de-authorizes your app on facebook.com

The Facebook SDK 3.0 for Android includes abstractions that remove the need to interact with access tokens directly. This article will walk you through how to manage access tokens through these classes, and how to handle the scenarios above. This SDK is also designed to be backward-compatible, so if you've set up access-token refreshing in an existing app, it will continue to work.

Access tokens and the session object
The Facebook for Android SDK 3.0 uses a new class, Session, to authenticate a user and manage that user's session with Facebook. API calls to Facebook will not use an access token directly; instead, you pass in a Session object that has an associated access token. Session automatically refreshes this token if needed. If you need a new token for any of the five reasons listed above, Session will automatically take your user through the authorization flow again. Note that this is a change from previous versions of the SDK.

The pre-built LoginButton and LoginFragment classes in the SDK provide an additional layer of abstraction, and handle the creation and update of the Session object for you. If you need to create a Session yourself, you can construct it like this:

Session session = new Session(context);

When the Session is created, it attempts to initialize itself from a TokenCache. If the cache exists and has a valid token, the session will be created using that token. If none exists, or if the token has expired, the Session object will create a TokenCache with an empty AccessToken object that has no associated permissions. You do not need to do anything for this to happen.

Source: http://feedproxy.google.com/~r/SdTimesLatestNews/~3/_ZZOgF83I30/article.aspx

key largo arnold palmer invitational ryan madson louisiana primary syracuse basketball chipper jones chipper jones