Fix semantic warnings in iOS5 and Xcode 4.2

Summary: Pulled from https://github.com/facebook/facebook-ios-sdk/pull/401

Test Plan:
1/ Ran on iPhone 4 device with iOS 5, Hackbook iOS app, launched feed dialog,
rotate all orientations and check works as expected. Also rotated device before
launching dialog and rotating dialog to see it performed well.
2/ Ran experiment (1) with iPhone 4.3 simulator.
3/ Ran experiment (1) with iPad 4.3 simulator.
4/ Ran experiment (1) with iPad 5.0 simulator.

Reviewers: yariv, brent

Reviewed By: yariv

CC: lshepard, yariv

Differential Revision: 354600

Revert Plan: OK

Task ID: 673148
Properly initialize FBDialog and Hackbook sample app data

Summary:
Related to pull requests
https://github.com/facebook/facebook-ios-sdk/pull/405
https://github.com/facebook/facebook-ios-sdk/pull/407

Test Plan:
1/ Tested Hackbook iOS app with iPhone 4 device with iOS 5, ran through various
screens and tested dialog.
2/ Tested Hackbook iOS app with iPad 2 device with iOS 4.3, ran through various
screens and tested dialog.

Reviewers: yariv, brent

Reviewed By: yariv

CC: lshepard, yariv

Differential Revision: 355088

Revert Plan: OK

Task ID: 786690
Update sample app to show how to handle dialog request results

Summary:
Part of the discussion of the abandoned diff https://phabricator.fb.com/D342789
was that we should update the Hackbook iOS sample app to show developers how to
process data passed back from the dialog. Changes were made to use
dialogCompleteWithUrl: instead of
 dialogDidComplete: method. Other tweaks made to display a success message back
to the user when an app request was sent. Also NSLog the post_id and request_ids
information so developer can check these out.

Changes still need to be made to the iOS SDK docs
(https://developers.facebook.com/docs/reference/iossdk/FBDialogDelegate/) to let
developers know how to handle the dialog data in the callback.

Test Plan:
1/ On iOS simulator 4.3 ran through the Publish Feed and Send Request flows.
Checked it works and shows the proper user messages and debug messages (that
developers could use in the future).
2/ Tested on iPhone 5.0 and tested feed and app request dialog flows.

Reviewers: brent

Reviewed By: brent

CC: lshepard, yariv, brent, caabernathy

Differential Revision: 360490

Revert Plan: OK

Task ID: 697899
Fix semantic warnings in Hackbook iOS sample app

Summary: Use UITableViewCellSelectionStyleNone instead of
UITableViewCellEditingStyleNone for selectionStyle.

Test Plan: On iOS simulator 5.0 test Hackbook iOS sample app, publish feed,
graph api sections.

Reviewers: brent

Reviewed By: brent

CC: lshepard, yariv, brent

Differential Revision: 365804

Revert Plan: OK
Code cleaning of Hackbook example

Summary: Removed trailing spaces, unified function definitions etc.

Test Plan: Check if this compiles

Reviewers: yariv, brent

Reviewed By: yariv

CC: jimbru, yariv

Differential Revision: 374136
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