Q. How do I determine the best unique identifier to distinguish users?
A. Despite a number of initiatives to implement single-login services, there is still not a great answer to this question. Some candidates are unique username/password pairings, email addresses, or phone numbers. In the example in this hour, we relied on the email address of the player as a unique identifier, and we allowed the user to set up a password. Many social networking sites use a similar mechanism, but this approach is not without prob-lems—for example, email addresses change, users may have more than one account, and they have to keep track of yet another login and password combination. When you're integrating with a social networking website, you need to use whatever authentication and credentials are required by the site's API.
Q. What are some of the privacy concerns I should consider when developing social applications?
A. When it comes to social applications, you should always include information about how you'll use any information supplied by the user. You're going to be safest when you follow these principles: Don't access, use, or store any information your application doesn't require and do assume that any and all information supplied by the user is private. Now, by this definition, even the lightweight friend support you added to the Been There, Done That! application is sharing private data: the user's nickname, score, and avatar. (See the exercises for accessing friends' avatar images from the server.) Technically, if you published this application, you would want to make it very, very clear to the player that this information is going to be uploaded to the application server and accessible to other players.
Q. How do I find out if my application can integrate with a social network application that's not listed in this hour?
Was this article helpful?