Merged sessionDelegates in the Hackbook sample.

Summary: Current Hackbook example implements two FBSessionDelegates. Switching
between them requires modifying the internals of Facebook class and is very
confusing. The solution is to remove FBSessionDelegate implementation from
APICallsViewController, and modify the code in a way that will work with only
one sessionDelegate.

Test Plan:
Try the following (two times every plan :) ):
  - login, execute any method, logout
  - login, execute any method, uninstall app
  - login, cancel login, login, execute any method, logout
  - login, request additional perms, cancel, request additional perms, grant,
logout

Reviewers: yariv

Reviewed By: yariv

CC: jimbru, lshepard, kamil, yariv

Differential Revision: 377641
Handling parallel requests

Summary: Current SDK doesn't support multiple requests at the same time. To
change this I added a new container to the Facebook class that stores all the
requests. Whenever the request finishes it's work (by loading the response or by
returning an error) we remove it from the container. Since FBRequests are
autorelased they will be deleted at the end of the event loop.

Test Plan: Check if the app works + tried to call the GetMe API method twice.

Reviewers: yariv, toddkrabach, jonathan

Reviewed By: toddkrabach

CC: yariv, toddkrabach, jonathan, jimbru, lshepard, jgabbard, kamil

Differential Revision: 378930
Added session expired error handling.

Summary: Whenever we call an API that returns a "session expired" error we
should clear the session data (acessToken / expiring date) and notify user about
it.

Test Plan: Login to app, then log out using www, then try calling rest / graph
method.

Reviewers: yariv, jimbru, brent, toddkrabach, jonathan

Reviewed By: yariv

CC: lshepard, yariv, kamil, brent, jonathan, toddkrabach

Differential Revision: 378197
Removed unnecessary inheritance

Summary: Quick code cleaning - Facebook class doesn't need to inherit from
FBRequestDelegate.

Test Plan: Check if it compiles and login in / login out works.

Reviewers: yariv

Reviewed By: yariv

CC: jgabbard, yariv

Differential Revision: 380359
Update README.mdown
Update README.mdown
Added the extendAccessToken method to facebook-ios-sdk

Summary:
Whenever user makes an API call the SDK checks if the access token is about to
expire.  If that's the case SDK will try to silently refresh the token.
Developer can also force the refreshing process by calling [facebook
extendAccessToken] method (this might be useful for apps that doesn't make
frequent API calls). Also provided an example of this functionality in the
Hackbook.

Test Plan:
With prod: tried refreshing the token and check if the expirationDate is
correct.

With sandbox:
 - disabling checking the ssl certificates in the sdk (done by following lines
(src/FBRequest.m) - I'm sure there's an easier way, but I don't know it :P):

  LANG=C
  - (BOOL)connection:(NSURLConnection *)connection
canAuthenticateAgainstProtectionSpace:(NSURLProtectionSpace *)protectionSpace {
    return [protectionSpace.authenticationMethod
isEqualToString:NSURLAuthenticationMethodServerTrust];
  }
  - (void)connection:(NSURLConnection *)connection
didReceiveAuthenticationChallenge:(NSURLAuthenticationChallenge *)challenge {
    if ([challenge.protectionSpace.authenticationMethod
isEqualToString:NSURLAuthenticationMethodServerTrust])
      [challenge.sender useCredential:[NSURLCredential
credentialForTrust:challenge.protectionSpace.serverTrust]
forAuthenticationChallenge:challenge];
    [challenge.sender
continueWithoutCredentialForAuthenticationChallenge:challenge];
  }

- changing the rest server url (in my case:)

  LANG=C
  static NSString* kRestserverBaseURL =
@"https://api.kamil.devrs332.facebook.com/method/";

- after that I switched to app which access expires after 10 minutes and tested
if the refreshing process behaves correctly (had to modify isSessionOld
function)

Reviewers: yariv, jimbru, brent, ekoneil

Reviewed By: yariv

CC: lshepard, ekoneil, jgabbard, brent, yariv, kamil, trvish

Differential Revision: https://phabricator.fb.com/D371702

Task ID: 823099
Update and Optimize iOS SDK for XCode 4

Summary:
Made the following changes:
- Removed obsolete compiler flags
- Exposed Public Headers
- Set the Installation Directory to $(BUILT_PRODUCTS_DIR)
- Set public header path to “$(TARGET_NAME)”
- Set “Skip Install” build setting to Yes
- Updated project format to XCode 4

Test Plan: Added project to XCode 4 workspace, tested FB Login + SSO

Reviewers: yariv, jimbru, brent

Reviewed By: yariv

CC: lshepard, caabernathy, security-diffs@lists, selekman, yariv

Differential Revision: https://phabricator.fb.com/D383376
Merge remote-tracking branch 'origin/expiringAccessTokens'
Invalidate session only if access token errors when extending token

Summary:
Currently when there is a Platform API call that has any error or if there is a
connection error, e.g. timeout, the access token is invalidated. This was due
to
diff D378197 where any errors call invalidSession. To fix this narrow the
invalidate call to the scenario where the access token has expired when an API
call
is made.

For now, only REST API error codes allow us to easily identify an invalid token
(error code 190). A separate diff will be implemented by the Platform team
to provide an error code for Graph API auth token errors.

Test Plan:
Case #1
1/ Login
2/ Tap Graph API
3/ Tap Get your friends
4/ Go off LAN and WiFi
5/ Tap Get your friends

Case #2
1/ Turn WiFi back on
2/ Tap Get your friends
3/ See friends list
4/ Go back to get to Graph API page
5/ Remove app from https://www.facebook.com/settings/?tab=applications
6/ Tap Get your friends

Case #3
1/ Temporarily modified code to force a Graph API error
     //[[delegate facebook] requestWithGraphPath:@"me" andParams:params
andDelegate:self];
     [[delegate facebook] requestWithGraphPath:@"000000" andParams:params
andDelegate:self];
2/ Tap Graph API
3/ Tap Get your information

Before this change, here were the results
Case #1: Session expires message, which is incorrect behavior
Case #2: Session expires message, which is correct behavior
Case #3: Session expires message, which is incorrect behavior

After this change, here are the results
Case #1: Get the Hackbook "Oops something went wrong" message, which is desired
behavior
Case #2: Get the Hackbook "Oops something went wrong" message, which is not
ideal, user should also be logged out
Case #3: Get the Hackbook "Oops something went wrong" message, which is desired
behavior

Reviewers: yariv, jimbru, brent, toddkrabach, jonathan

Reviewed By: yariv

CC: lshepard, selekman, beau, bgolub, danmuriello, jacl

Differential Revision: https://phabricator.fb.com/D402481

Revert Plan: OK

Task ID: 900407
Fixes breaking change introduced by  (e79d072)

Summary:
The problem is that e79d072 fixes odd behavior in Hackbook,
which had support in the SDK code’s logout function. Prior to e79d072
Hackbook was more convoluted, and the logout behavior broke
encapsulation. The solution is to put back a deprecated logout method that
matches the original signature, and keeps most of the original behavior
(though it does not break encapsulation, which was badness.)

Test Plan:
Manually modify Hackbook, and whitebox test each of the following
permutations:
* login with no delegate (call the cached delegate)
* login with a delegate matching the cached delegate (call the cached delegate)
* login with a delegate different from the cached delegate (call both)

Reviewers: yariv, caabernathy, mmarucheck, vijaye

Reviewed By: yariv

Differential Revision: https://phabricator.fb.com/D405235

Task ID: 905137
Provide developers script they can use to get a static library version of the
iOS SDK

Summary:
For developers who are building apps with Automatic Reference Counting
enabled using our current iOS SDK will produce errors. One solution is to
provide a static library version of our SDK that they can include in their
project. We could provide detailed documentation to do this but it is easier to
provide a script that they can run. This diff introduces this script. We
considered actually packaging the desired library with the SDK but that would
involve a process change on our end because the current SDK development flow
does not include building a library. So for now we will push this on the
developer and perhaps in the future look at a more streamlined way to provide
this library to the developer.

Additionally, needed to make sure deployment target was set to iOS 3 for the
project.

Test Plan:
In terms of testing the script just run it a few times from various initial
locations, e.g.
% sh
/Users/caabernathy/Facebook/Code/iOS/StaticScriptTest/facebook-ios-sdk/scripts/build_facebook_ios_sdk_static_lib.sh

Also run it twice to see the output library properly overwritten

Once the library was produced, tested it worked well by doing the following
Scenario 1: Use the library with an app that does not have ARC enabled
1/ Built a simple app with Facebook SSO and a news feed dialog
2/ Tested SSO works and that the dialog UI has all the relevant resources and
works

Scenario 2: Use the library with an app with ARC enabled
1/ Built a simple app with Facebook SSO and a news feed dialog. (When creating
this app, made sure ARC was turned on)
2/ Tested SSO works and that the dialog UI has all the relevant resources and
works

Scenario 3: Switch out the Facebook SDK in the Hackbook sample app with this
library
1/ Removed the FBConnect folder from the Hackbook sample app
2/ Dragged in the new library, chose to copy the contents over
3/ Ran the app and went through all the flows. Note: Found some cases that do
not work that also appear to be broken in the current app, namely video upload,
and recent check-ins listing. These can be addressed separately.

Reviewers: yariv, jacl

Reviewed By: jacl

CC: mmarucheck, vijaye, selekman, brent

Differential Revision: https://phabricator.fb.com/D415047

Revert Plan: OK
Adds frictionless apprequest support

Summary:
Here are the mods to the sdk:
1. adds four methods to the Facebook class, for use by applications
  * enableFrictionlessRequests
  * reloadFrictionlessRecipientCache
  * isFrictionlessEnabledForRecipient
  * isFrictionlessEnabledForRecipients
2. extends dialog method and support class to support frictionless behavior for “apprequest” dialogs
3. extends Hacbook sample to add frictionless app-request support

Notes:
* enableFrictionlessRequests method of FBFrictionless turns on frictionless apprequest behavior in the SDK
* frictionless apprequest behavior means
  a.) a cache of allowed frictionless recipients is maintained
  b.) cache checked by dialog, and dialog is invisible for frictionless recipients
  c.) send responses are checked and recipient list is updated
  d.) logout and login cause clear and refetch of cache respectively
Added FBFrictionlessRequestSettings.m to the xcode project
Merge pull request #440 from alvarezm50/master

FBFrictionlessRequestSettings.m is missing from xcode project
Fixes url parsing bug -- reenables in-app auth flow

Summary:
Introduced a bug in URL parsing with the frictionless fix, which
failed to recognize urls that begin the parameter section with #

Test Plan:
Whitebox test using hackbook to force the in-app auth flow, and
confirm that the new line enables parsing of the returned URL

Reviewers: yariv, caabernathy, mmarucheck, vijaye

Reviewed By: mmarucheck

Differential Revision: https://phabricator.fb.com/D425267
Fix issue causing blank white dialog when loading friends list

Summary:
Set the UIActivityIndicator color to gray to stop it from blending into the background.
On iOS5 we do this by setting the color to gray. On older iOS versions which don't support this
property, this is done by setting the style to UIActivityIndicatorViewStyleGray instead of
UIActivityIndicatorViewStyleWhiteLarge which results in a slightly smaller indicator.

Test Plan: Testing using Hackbook.

Reviewers: jacl, dgibson

Reviewed By: jacl

Differential Revision: https://phabricator.fb.com/D426894

Task ID: 908016
Use [NSDictionary objectForKey:] instead of [NSDictionary valueForKey:] to access objects in dictionaries

Summary: valueForKey also works in this case since none of our keys are strings staring with "@". However, objectForKey: is the correct selector to use for the desired behavior.

Test Plan: Verify behavior with HackBook app

Reviewers: jacl, dgibson

Reviewed By: jacl

Differential Revision: https://phabricator.fb.com/D427850

Task ID: 854847
Fix a bug that caused request: didLoad: to be called with the raw response instead of a string when the response does not represent a valid JSON object.

Summary:
If the response is not a JSON object, convert the actual response to a string instead of using the NSData object.
This will break clients that depend on the current behavior. If you need access to the raw response, use request: diReceiveResponse: instead.

Test Plan: Test with stream.publish requests

Reviewers: jacl, dgibson, yariv, caabernathy

Reviewed By: jacl

CC: leon

Differential Revision: https://phabricator.fb.com/D427844

Task ID: 842334
Fix memory leaks in Hackbook

Summary:
1) img was alloc'ed and never released while uploading a photo
2) alertview was alloc'ed and never released
3) friendswithapp was alloc'ed twice and never released, updated the logic to use obj c syntax
4) UIGraphicsGetImageFromCurrentImageContext() returns an autoreleased imageView - retaining it is the incorrect solution. See http://stackoverflow.com/questions/1529667/memory-allocation-and-release-for-uiimage-in-iphone

Test Plan:
Run Hackbook in the profiler and verify no memory leaks when loading userpic from the graph api
Upload a photo, verify no longer leaks
View friends with app, verify no longer leaks
Pop the alertview and verify no longer leaks

Reviewers: jacl, caabernathy, mattwkelly, selekman

Reviewed By: jacl

Differential Revision: https://phabricator.fb.com/D430905

Task ID: 980129