While the answer is very much dependent on the objectives of each individual app, the use of Facebook Connect seems to be on the rise. This first look will be an initial investigation into what it is, how to implement and what are the pros and cons of using Facebook Connect for iPhone.

What is it?

Facebook Connect for iPhone is a Objective-C library that you can include in your app. It handles login, user session, user feed and can be used to call methods in the Facebook API.

You can see it in use in apps here:

1. 10 Fantastic iPhone Apps that use Facebook Connect
Notably “PhoneBook”, which syncs the iPhone Address Book with Facebook friend’s profile photos; “ThisMoment”, which lets an author posts ‘moments’ to his/her Facebook stream.

2. Facebook Connect for iPhone now like, First apps released (back in 14th March 2009)
“Who has the biggest brains” app uses is to share user’s top scores on Facebook.

How to use it?

1. Create a Facebook application for your iPhone application. You need to create the FB app, to get an application ID that will be used by your iPhone app. See “Using Facebook Connect for iPhone“.

2. Add FB Connect to Xcode project. Code currently lives at Github Facebook Connect for iPhone. Also remember to grab the official FB Connect buttons.

3. Do interesting stuff with it. Developer documentations are at http://wiki.developers.facebook.com/index.php/Facebook_Connect_for_iPhone.

Pros and Cons?

A custom/internal user management system is not trivial to implement, especially from scratch, and more so if it is not a core feature required for an iPhone app. But if there already is an existing user system, then I guess that should be the clear choice in order to grow the registered user base.

Facebook Connect, on the other hand, provides a “quick and dirty” way to manage users. Chances are, most users already have a FB account. Users are probably more comfortable revealing information about themselves to FB than to a relatively unknown web service (well, compared to FB, who isn’t?). Facebook Connect can also be a first step towards “social apps” that take advantage of a user’s existing friend networks to do interesting stuff.

Some questions left unanswered at this point are:

1. Is there a way to list / manage all the people who have logged in through my application?

2. Can I access additional user demographic information (gender, location, age, etc) through FB Connect?

This post is password protected. To view it please enter your password below:

Password:

APNs runs on iPhone OS 3.0 to handle:

• “Pushing” text, sound and badges to an installed application without requiring any action from the user.
• Even while the application is not currently running on the iPhone OS device.
• An application’s “background processes” to be run — on a server, not the device.

Apple has a one-page overview of the feature.

User perspective

An application can receive text notifications that show as an alert; sound notifications that are played; or a badge notification that adds a number badge to the app icon (like unread emails for Mail). If the application is already running, it may choose to handle the notifications differently.

User’s can change each push-enabled application’s settings by going to Settings > Notifications. For each push-enable application, user can select whether or not to enable Sounds, Alerts, and/or Badges. There’s also a setting turn off notifications for all applications.

A device will only receive notifications for/form applications that are installed and have been run at least once on the device.

Developer Perspective

Think of it as a client-server model. Developer deploys the client as an application on the user’s device. The server uses APNs to push notifications to the device, even if the application is not currently running on the device.

In actual implementation, the server only sends notifications thru the APNs to the device. There isn’t a direct path from the provider to the device, and it is sent asynchronously. Should the device be offline at the time notification is sent, APNs stores the notification for later delivery. Only 1 notification will be stored per application.

The basic security model is: an application registers itself with APNs on its first launch. The device-application pair is given a “device token” by APNs. The application is expected to send the device token to the provider’s server. With that device token, the provider can communicate with the device thru APNs.

The actual message sent from provider is a JSON object. It can hold a text message to be alerted, a number to display as a badge on the application icon, or a sound name (referencing a system sound or a sound file in the application bundle) to be played. Combinations of the above is possible too.

Apple provides a separate Sandbox and Production APNs. To use them, developers need a SSL cert (available at the iPhone Developer’s Portal). The SSL cert is to be install on the provider’s server.

Requirements

• iPhone OS 3.0 or later
• Internet connection (wifi, 3G, etc) that allows communication over port 5223
• Wifi will only be used if there is no cellular data connection
• While on wifi, device will only receive notifications if the device is plugged in or if the device display is on.

My Questions

1. Can I push sounds dynamically to the device?
   No. “Pushing” a sound is actually pushing the filename of a sound file within your application bundle. Scrap the thought of pushing…. voice mails (example). Fart-Push however, will work. I dread the day Fart apps get Push functions.
2. How reliable is Push Notifications — rather, under what conditions will APNs not be able to push?
3. If I remove an application, will I still receive push notifications for that app?
   No. The device will refuse the notification if the target application has been uninstalled. APNs has a feedback service to inform the providers which devices are refusing the notifications, so that it can stop sending to that device.
4. How long does APNs store notifications for offline devices?
   Not sure at this point.

References

developers.apple.com: Apple Push Notification Service Programming Guide

mobileorchard.com: The Hidden Costs of Apple’s Push Notification Service

arstechnica.com: The problem with push: can small developers afford it?

highscalability.com: Apple’s iPhone to use a centralized push based notification architecture