iPhone Game Development - Chris Craft [88]
[dialog show];
You might have noticed that on the second line you set the FBPermissionDialog's delegate to self. That means that the FBPermissionDialog has a delegate that you will need to implement in the MainViewController, just like you did for the FBSessionDelegate.
The FBPermissionDialog's definition is named FBDialogDelegate. All of its methods are optional, and it has three methods available for you to take advantage of: dialogDidSucceed, dialogDidCancel, and didFailWithError methods. Notice that all of the methods have meaningful names. A method has a meaningful name when it is easy for other developers to guess what the function does from reading its name.
FIGURE 6.29
Extended Permission screen
If you show the user the FBPermissionDialog and then the dialogDidSucceed method is called, you know the user wanted to grant your application an extended permission and Facebook made it happen. If instead the dialogDidCancel method is called, you know the user did not want you to perform the requested action. If the didFailWithError function happens, you know something went wrong, and you will have to look at the provided NSError object to learn exactly what happened.
Caution
Always try to give your methods meaningful names. This not only helps prevent confusion when others read your code, but it also makes it easier for you to remember a function's purpose when you return to it later.
You will use the status_update extended permission with the FBPermissionDialog to get permission from the user to access his profile information. If the user agrees to give you permission, you will read his user name and display it in an alert view. In order to be able to do this, you need to implement the FBDialogDelegate's optional method dialogDidSucceed so that your application will be notified if and when the user agrees to share his profile information. For good measure, you will implement all three of the FBDialogDelegate's optional methods.
First, update your MainViewController.h file by adding the FBDialogDelegate to the MainViewController's declaration:
#import #import “FBConnect/FBConnect.h” @interface MainViewController : UIViewController FBSession* session; } @end Next, edit your MainViewController.m file to add all of the FBDialogDelegate methods: ///////////////////////////////////////////////////////////////////// // FBDialogDelegate - (void)dialogDidSucceed:(FBDialog*)dialog { NSLog(@”dialogDidSucceed Called”); } - (void)dialogDidCancel:(FBDialog*)dialog { NSLog(@”dialogDidCancel Called”); } - (void)dialog:(FBDialog*)dialog didFailWithError:(NSError*)error { NSLog([NSString stringWithFormat:@”Error(%d) %@”, error.code, error.localizedDescription]); } NSLog provides one of the most important debugging tools for your iPhone arsenal. It allows you to write debug output to Xcode's Debugger Console window (see Figure 6.30). The code you wrote to implement the FBDialogDelegate uses NSLog to record which method was called. And in the case of didFailWithError, it records the error code as well. FIGURE 6.30 Debugger Console window NSLog(@”Logged in as %@”, name); Tip NSLog is an iPhone developer's best friend. Be sure to look up NSLog in the Research Assistant, in the API Reference, or online again and again until you learn to fully master its capabilities. Now you need to update the dialogDidSucceed method to display the name of the logged-in user. The following code does just that: - (void)dialogDidSucceed:(FBDialog*)dialog { NSLog(@”dialogDidSucceed Called”); NSArray* users = result; NSDictionary* user = [users objectAtIndex:0]; NSString* name
As applications become more and more complex over time, NSLog allows a developer a back door into the application's workings so that troubleshooting is as little trouble as possible. You can pass variables into NSLog as well, as shown in the following code: