Well, thanks for coming. We've got some things to talk about. My name's Matt Drance. I'm Apple's Sharing Technologies Evangelist. And for the next hour, I'm going to go into the details of the new Push Notification Service, which you all heard about on Monday. It's one of the bigger pieces of news at this year's conference. And I'd like to start by just setting the stage and explaining why you guys are here. Presumably you know why you're here, but why you're here and why this is such big news.

You guys are all working on iPhone apps, and some of them probably have connections to a server somewhere in the cloud. Now, when this app is running, You can go ahead and fetch new data as you see fit. Goes right over to the app. You update your user interface. Users of the app stay informed. But when your app quits, the connection to that server has been severed.

But life goes on, and more information becomes available. So how are you going to get that new information to the user in iPhone OS's model of only one running process at a time? This is exactly where the Push Notification Service comes in. This is a networked service provided and maintained by Apple that's going to allow you to notify users of new information right on their iPhone, regardless of whether or not your app is running. Once this notification has reached the system, the user can choose to bring your application back to the front, where you can then go ahead and pull the new data in and get that updated information to them.

So there are a number of reasons why we think this is a great solution. You heard about some of it on Monday, but I'm going to go over it again. First, just like everything that we do at Apple, it starts with user experience. And user experience is more than just icons and design and, you know, artistic stuff. User experience is about performance and responsiveness and stability.

So I know a lot of you have asked over the last couple months, why can't I just write a background process? I know what I'm doing. I can go ahead and create a connection to my server. And I can get that information to my users whenever I want.

Well, in your own perspective, that might be fine. But the fact is, you're not going to be the only application on the phone. So once we open those doors, now we're going to be talking about an unlimited number of background processes, doing an unknown number of connections to an unknown number of servers, sending unknown amounts of data for unknown periods of time. Look at this.

This does not scale. But I'll tell you what does scale. A single cloud in the middle that everybody communicates through, talking to a single point of entry on the phone, where we know how to balance for CPU consumption, memory usage, and battery life. This scales plenty. We're also providing a consistent UI to you guys, a UI that you've seen elsewhere, like in SMS and in the phone app.

We're going to allow you to specify a badge. We're going to allow you to give textual alerts with a button for the user to either dismiss the alert or launch your app, so you can go ahead and pull that additional data to your application. We're also going to let you specify custom sounds that you provide.

And we're going to have centralized settings. All of the applications set up for this service are going to show up in the Fetch New Data settings in the Settings app. So you can see here we've got a list of a couple of apps, and from here the user can specify how they want the push to occur, as well as turning notifications on or off for specific apps, as well as for all apps on the system. So you get that for free.

And finally, it's easy. It's easy both from a logistical standpoint as well as from a technical standpoint. First of all, it works over any connection, both Wi-Fi and cellular connections. And most importantly, it's available to every member of the iPhone Developer Program. The keywords here are "push" and "everybody." We are enabling you guys to send push notifications over the cellular networks just as being a member of our program.

So I don't know how many people have worked in the wireless space before. If you haven't, you should talk to somebody who has, because this is huge. You don't have to talk to the carriers. You don't have to go through any additional certification. Those of you who are in the program already have what you need to participate in this once it's available. Just send your notifications.

It's just as easy on the technical side. In order to make this work, you need to learn three new Cocoa methods, and on the server side, two HTTP methods. That's it. Done. So with that, let's go into the nuts and bolts of it. I'm going to start by talking about the registration process, what you need to do to start sending these notifications to a specific device, We'll talk about the process of actually publishing, sending these notifications, then receiving them on the client side, and then we'll go into some additional tricks you can do to manage the service to your liking. And then this will be a large part of the talk, best practices, things that you're going to want to remember to make this an effective and consistent experience for your users, because everybody, I suspect, is going to want to use this. Let's get started.

Registering for notifications is a straightforward three-step process. In the first step, your iPhone application contacts your server and lets it know that there's a phone here that's ready to receive notifications. In the second step, your server forwards that information about the phone to the Push Notification Service. The Notification Service will return the success value that you should then forward back to your app, and when your app has received the success, it goes ahead and registers for notifications with iPhone OS on the client side. So let's go over the details of these three steps.

First step, again, is where the app contacts your server and says, "I have a phone here, and I want to start sending notifications to this iPhone or iPod Touch." Now, all we care about is the device. We just need to know where these notifications are going to get forwarded to.

But a lot of you with networked services, of course, have usernames, passwords, accounts, so you need to know how to associate notifications on the server side with the person who's going to get them. So if you're concerned about accounts, usernames, passwords, credentials, all of that is going to be up to you. You just send that through to your server and make sure you've got the right person, and from there, just send us the phone. That's all we care about.

So what does this look like? This is it, seriously. We have a new method on UI application called Remote Notification System Identifier. And this is a unique ID.

So you have that unique ID, and you basically just send it over to your server. And this register with my server method is something implemented by you. It's not their API. I don't remember the last time we had something with my in it. Basically, you wait for a response. And we'll go into that again later.

So that was step one. You've told your server about a phone that needs to register for notifications. Step two is where you forward on information about that device to the Push Notification Service, and you set up what we call a publishing node to start sending these notifications through. And in this step, we do have some authentication required on the server side, so that we know the person sending these notifications is actually you.

And again, when the node has been successfully created, we will return a response to your server, which you should then relay back to your iPhone app, so your app knows that notifications have been enabled. So what happens here on the server side? How do you create this publishing node? You do it with an HTTP post to the Push Notification Service. And here's the URL that you see here. We're going to break that down in a second. It uses transport layer security with basic authentication.

And at the end, you're going to throw a query string on there with an action parameter set to create. In other words, I'm creating a notification, a publishing node, for this particular device, for this application. So that long URI you see there has a couple things in it.

It has a publisher ID, and this is basically your identifier, your username, if you will. And basically, that's just going to be the same as the bundle identifier of your app, since you're ultimately sending this to your app on your phone. And this is important because if somebody has 10 apps registered with the Push Notification Service, we need to know which app the notification belongs to. And then we're also going to add that device ID, which came from step one. Again, it's the Remote Notification System Identifier method, and that's what it looks like. It's basically just a hex string.

And finally, you're going to provide a node name. We haven't decided on the name yet, but we're just going to call it Inbox today. So this is your URL for creating and sending notifications. And here's some Ruby code that would show what this might look like. I construct the URL. I have the path there where I've got my publisher ID and my device ID, and an action of create at the end. Got my basic authentication in there.

And now this is important, I return that result to the client. This is HTTP, so we want a 200 back. And once that's been successful, we go ahead and we tell the client app that the registration is done and we're ready to go. So, you've told your server that you're ready to listen for notifications, and your server has told us that there's a new iPhone out there ready to get them.

Once you start sending these, they're not yet going to make it, because you haven't yet told iPhone OS that your application is specifically ready to start receiving them. So with apologies to Mr. Goldbloom, there is a step three. And no, it's not profit. Well, hopefully it is, but... Step 3 is your app registers for notifications.

And you registered on the server side, but you also need to tell the OS, "I am this application, and I am ready to start receiving these notifications from the service." So once that's happened, your app goes away, notifications get through, you get your badge, your alert, your sound.

And here's the client side code. And you've already seen most of this. The first couple lines here are right out of step one.

So we go ahead, we tell the server about the publisher ID, excuse me, the system identifier, the subscription ID. We wait for the response, and once the response is positive and we know the node is there, we go ahead and we get the publisher ID, which again is just the bundle identifier, and we tell a new method on UI application, register for remote notifications from publisher, and that is the third and final step. And from there, notifications start going through to the system.

Now this method does a lot of things. It doesn't just allow you to receive notifications when you're running, but it also adds the app to that list in the Fetch New Data Settings, as well as a bunch of other things. We'll talk about that a little bit later. So that's registration. Let's go over it again.

First, you contact your server about a phone or an iPod Touch that's ready to receive notifications. Your server forwards that information to the Push Notification Service. Push Notification Service sends you a response. Hopefully that response is success. And you send that back over to your application so that it now knows to ask iPhone OS to start listening. Once registration is complete, it's time to start sending notifications. Let's talk about that now.

Sending notifications is very straightforward. It's done with an HTTP PUT to the Push Notification Service. You're using the same URI path from the registration process we just went over, so this should look familiar to you. And the property list, the body of the transaction is just an XML property list. And this is where you have the contents, the context of that notification. And this code is nearly identical to what we had before. It's just the PUT instead of a POST. And you notice there's no query string either. But the URI is exactly the same.

So let's go over some more server-side details here. So all of the transactions you're going to hear about in this hour use HTTP over TLS with basic authentication. The data that makes up the notification itself is UTF-8 XML. It's limited to one kilobyte. So you need to remember that. No huge dialogues, no 20-line messages, please. We're going to keep it simple. We'll talk more about that in the Best Practices section.

And for those of you new to the platform, unfamiliar with property lists, you'll hear plenty about it in our introductory and tool sessions, but the DTD is available at apple.com. It's very straightforward. And another point, the service saves the last notification that's sent out per client, per node. And we'll talk about how that might be useful to you a little later.

So here's what the notification body looks like. This is that P list that you're going to put in the body of your HTTP put. The first key you see there is UI Alert Body, and this is what you specify for the message inside an alert if you want to send an alert.

So I already said this, but you want these messages to be short and clear. There's not a lot of room here, neither on the screen nor in the payload. You're limited to one kilobyte. You can already see there's a lot of administrivia in here with the tags, and not to mention the headers. So keep these messages short and sweet.

You also have the ability to enable or disable the button that activates your application. So by default, this button exists. There's a -- you saw the screenshot before. We have that view button that the user taps, brings your application right to the front. If for whatever reason you don't need the application to be brought forward, you can optionally set this UI alert show open button to false, which will just have a single dismiss button, kind of like the alarm clock.

Specifying badges is very straightforward. We have a UI application badge key. The value of this key should be a positive integer. I'll say that again: positive integer. No negative integers, no decimals, no fractions, no zapping bats, just integers. You've seen this on the phone before, and we want this to be a consistent experience with what's already there in mail and SMS.

And this is very important. Maintaining a correct value, a correct count, is going to be up to you on the server side. And we'll talk a little bit more about what that means and what you'll have to do. But we just take what you give us. So if you send us a one and then another one, the badge value is still going to be one.

And finally, to specify sounds, UI Alert Sound Key. And this is a string value, which is basically the name of a sound file that's already inside your application. So it's just the file name without the extension, and we know to pull that out and play it when these notifications arrive.

You can have any number of names, obviously, and we also have a constant that allows you to just use the system default sound, whatever the user has selected. But you probably don't want to get rid of this opportunity to have some personalization on your part and make your presence known on the phone. You don't want to confuse the user, and sounds are a great way to have something distinct going on.

So things to remember when you're sending notifications. Again, keep the alert messages small if you're going to use alerts. You've got a one kilobyte limit, including all the metadata you saw on the screen. And again, you don't want to aggravate the user and waste their time with long messages. Localization is up to you. I'm sorry to say we won't be magically translating these things for you as they go out the door.

So if that's important to you, you need to transmit your locale information maybe during step one, during registration. Just keep your server apprised of where the user is. It's important for you to deliver localized content. That's going to be your responsibility. And most importantly, track your badge count. I already said this before. The service does not track the count, and the OS does not track it either. So it's going to be your responsibility to provide an accurate number for the badge every time you send a notification.

So you've sent a notification, and the OS will handle it, put up the badge, the alert, the sound, whatever you've specified. But what about when your app is running? To handle these notifications while your app is active, we have an optional method that we're adding to the UI application delegate that allows you to receive the notification and all the information associated with it. And it looks very similar to any notification handler that you have dealt with in the past in Cocoa.

But the important thing is this is required to respond to notifications at runtime. Because we're turning off the system handlers while your app is active, and this makes sense. Presumably, you know what to do with your information if your app is running. We're not going to put up a dialogue while your own app is running saying that your app needs attention. Your app has attention.

So, you need to remember that. And you also need to maintain the general state. We're not going to update the badge count when these notifications come in, so it's going to be up to you to use the badge count property on UI application and set it however it's appropriate. And you also want to make sure the data is correct, because if you've got direct communication with your server going on, you want to make sure this notification that comes in is not redundant.

So why would I listen while I was active, or why wouldn't I? This is really going to be a choice that you make. That's up to you, because everybody in this room is going to have different use cases, different scenarios, different needs for this service. So basically, you just need to decide when this is going to be appropriate.

If you, for example, don't have a persistent server connection, and you don't do a lot of communication with the server, and things just trickle in very, very slowly and infrequently, then maybe it makes sense to keep listening to these notifications while you're active. And it saves you the trouble of having to maintain a connection and pull all the time when there's nothing there.

Conversely, if you have a persistent server connection or you do check frequently for various reasons, it might not make sense to listen to these notifications while you're active. And in that case, you can either conditionally ignore it in the delegate method or just don't implement the delegate method. Remember, it's an optional method. But these are things you need to think about and decide on when you start to write this code.

But mostly, most importantly, server side control is not recommended. You don't want to start playing clever games where your app launches and says to the server, "Hey, don't send any more notifications because I'm live now." And then on your way out when you quit you say, "OK, please start sending them again because I'm about to quit." That's a little risky because you could run into race conditions, the phone could ring, your app could crash, there are a lot of things that could go wrong here where the user suddenly misses out on notifications as they come through. So really, if you care about dropping notifications while you're active, just do so. Just stop listening.

You can also unregister your app altogether for these notifications. And this is a pretty heavyweight operation. The unregistration actually removes your app from the Fetch New Data settings. So it doesn't just turn off listening. It actually removes the app from the service registration on the client side. So really you want to use this sparingly. This is not going to be your mechanism for conditionally not listening.

It's basically if you're end of life-ing the product, if you're removing the feature, if you have problems and you decide you want to disable it altogether, this is basically the--I would call this the bazooka option. This is probably something that none of you are actually going to use.

But it's there for consistency and parity. And remember, users can turn off notifications manually. So it's not like it's something you have to manage in your own settings. Do you want to receive notifications, yes or no? That's being done in the Fetch New Data settings globally on the system.

And when you uninstall your app, we will go ahead and do the paperwork required to take you off of the notification system. So unregistering is probably not something that you'll do often. So that's it for listening, receiving. There are a couple other things that we could talk about, both on the client and server side, that you probably want to keep in mind.

I mentioned earlier that we keep the last notification that each client sends, but it's only one. So if you send four in a row, we only hold on to that fourth one. And you query this, you can actually take a peek at it using an HTTP GET. And this code is starting to look really redundant now.

It's the same URI, it's the same address, and a GET instead of a PUT or a POST. And what that'll do is give you that P list back that you sent last time, and maybe you can be clever about providing additional context in your second notification or your nth notification.

We just talked about unregistering from the client side. But you also have that publishing node up in the cloud with our service. And how do you get rid of that when the time comes maybe the user has canceled their account, they've uninstalled the app, all of the above? You do this with another HTTP post, and that action query string is now delete instead of create. So this is the exact same code you saw earlier during creation. Now we're deleting instead of creating. And again, this is not something you're going to do very often. This is just going to be in a case of uninstallation, of sign-offs, people not paying their bills.

Let's go over everything that happens on the server. This is really straightforward. If you're doing anything for managing the publishing nodes, you're doing a post. You specify a create parameter for create and a delete parameter for delete. You use an HTTP put to publish the notifications and a get to read the last one that was sent. And it's the same URI regardless of what you're doing. There it is.

So those are some additional tidbits that you probably want to keep in mind when you start implementing this. Now let's move on to best practices. This is probably the most important part of the talk, because it's really important that when this goes live and you guys start using it, that it's a consistent experience for everybody, for all users of all applications, whether they're on iPhone or iPod Touch.

So just some high-level thoughts on using the service in the first place. If you haven't gotten it already, these are notifications. This is not data you're sending. Data is to be pulled by your application when the user has elected to bring it back to the front. The whole point of this service is to put the power in the hands of the user to decide whether or not the information is important enough to be pulled at the moment.

And again, keep it simple. You want to keep the alert messages short, and you want to have good, solid logic that gets an accurate badge count. Remember you have that 1K maximum, and that includes all the tags and everything else, so keep the messages short and sweet. Additionally, just think about sending emails. If you have information that's not really time sensitive that you want to add some more verbosity to, an email might be perfectly fine. First of all, it's available today.

Second of all, like I said, you can add additional context. An email can be any length. And you can still trigger -- you can still prompt the user to go back to your application by adding a URL to your app. Your app can go ahead and define a custom URL scheme.

And you can send an email with that URL in it. And maybe in the query string, you've got some additional state, context, whatever. So email if you don't want to wait for this service and you don't have things that you -- you don't think you'll be sending things frequently and they don't need immediate attention. Email is a perfectly good alternative.

And finally, you don't want to depend on this service. You don't want to design a product around it. The goal of this service is to make good apps better and to put information in the hands of users in a more timely, more accurate fashion. But they could go out of coverage. They could drive under a tunnel. They could turn notifications off altogether, either for your application or for all applications in the Fetch New Data settings.

And also remember that the iPod Touch is Wi-Fi only. So there's no cellular activity for iPod Touch. People are only going to be able to get these notifications when they're on a hotspot. So things to remember: don't build an app around this concept. Now, client side, things that you want to keep in mind, keep track of. It's up to you to decide whether you want to listen to these notifications or ignore them when you're running. That's why we have that optional delegate method.

So if you've got active, persistent server communication, you may not want to listen. If you've got infrequent server communication, you don't want to waste resources polling all the time, listening for the notifications might be a good idea. And again, the importance and the frequency of the info is going to go into a lot of this decision-making process. We're going to talk more about that a little later.

You want to avoid unregistering, either on the client or the server side. You want to keep the service intact. You don't want to perform these heavyweight register/unregister operations repeatedly. If you decide the notifications are not important at the moment, just stop listening while you're active. So things you've got to remember on the server side.

We've gone through all of this before, but I want to lay it out on one slide for you. Your responsibilities will be your own user authentication. Again, all we care about is the device. We don't care whose device it is, what their password is, what their username is. That's up to you. If that matters to you, you need to track it.

Localization is up to you. If you want to translate things for different locales based on where the user is, based on where they bought the application from, whatever you decide is important, it's up to you to track it. And again, the badge count. It's going to be up to you on the server side to send an appropriate badge count every time so that that number doesn't jump all over the place with successive notifications. Let's visualize a little bit what that means.

I've got a piece of data, the app's not running, I go ahead and I send a 1 to the Push Notification Service because I know that this is the first notification I'm sending. Get a second notification. It's up to me on the server side to know that that first notification has not been handled, obviously, because the app hasn't been launched and it hasn't made a connection to the server to get the new data. So, second time, I send a two. And we just take that verbatim and put it right onto the badge icon.

When the app comes back to the front, you make your connection again, pull the data down, everything's been addressed and updated. So at this point, if the information has been read and addressed, you go ahead and set the UI application badge count property to zero and set us back down. And also tell the server, we've cleared everything out. New information comes while the app's running, you go ahead and pull it up, either with your own persistent server connection, or maybe you were listening for notifications while you were active. Again, that's up to you.

The app quits. Our badge count is zero. We have no unread things. Something else comes up, and we start over at one. So this is pretty straightforward, but I just want to make it clear to you guys that it's going to be your responsibility to do this. And anybody who's managed a server should be familiar with it. I mean, IMAP servers know how many messages are unread, so this is not really a radical concept at all.

So now we need to talk about user experience. We've done a lot of work for you by giving you the badge icons and the alerts, but there are things that you want to remember, regardless of which ones of these mechanisms or combination of these mechanisms you're using. Things to make sure that the experience is going to be good across all applications.

So the key principles here are that the notifications need to be actionable. If you're going to put a badge with a number on your application's icon, do you know what the user Do you know what the user is going to do to make that number go away? If you don't know the answer to that question, then you might not be talking about a notification. There may be something else you should do, like send them an email or a dialogue with just a dismiss button.

It should be important, and it should be important to the user. We all think our data is important. That's why spam exists. It needs to be important to the user. When they read that dialogue or they see that badge icon or they hear that sound, are they going to pick their phone up and go launch your application? Because they wanted to. And the answer to that question should be yes. And it should be consistent.

You really want to minimize the types of notifications. You don't want to have ten different kinds of notifications that you send and ten different sounds, because then you start overloading the user's brain with, "Well, what did that one mean? I have no idea. I can't remember." And you also start talking about really overwhelming numbers of dialogues.

Inform your users. Don't annoy them. That's really the main message here, and the thing you want to keep in mind when you start throwing things in front of them. So let's start by talking about badges. Badges are going to be your primary notification type. They're non-intrusive, they're informative, and they're clear. And again, this should be for actionable information. When the user taps on your icon, what are they going to do to turn that one into a zero? If you don't know the answer to that question, you need to think some more.

You need to keep a server-side count. I've said this plenty of times already, but I'm going to keep saying it. And test your logic, because there are a lot of things going on around here. A lot of things going on here. And you want to make sure that that number you send is accurate at all times.

The count can change while you're in the background. The notifications can arrive while you're running, and it's going to be up to you to marshal where you want to start listening from. Again, ensure that the information is accurate. We don't want to go from a 2 to a 7 to a 3 in 5 seconds.

So sounds. Sounds are the big deal because it gives you the ability to identify your notifications to the user without them even looking. I can have my iPhone in my pocket, and I hear a specific sound, and I know who it came from. And I say, oh, I've been waiting for a new message from so-and-so. I need to go look at the phone. And this is basically an opportunity for you guys to make your mark and be distinguishable from all the other apps that will likely sign up for this service.

Largely, these sounds will behave similarly to the SMS behavior. So it will respect the vibrate settings, and it will also interrupt the music. So if the user's listening to music on their iPod, The sound will dim, and they'll hear the chime, and then the music will come back.

So what that means is you want to keep these sounds short and distinct. I said, "It's an opportunity to have your brand in place here and really have users know where the notification is coming from without even looking and that's great. So go ahead and have a branded sound." But ringtones and songs are not going to get it done, not only because they're way too long for something like a notification, but because when you consider the iPod use case, you don't want music to fade out and then some more music plays. That's just going to confuse the user.

Did a new song start or did a notification come? Is my phone ringing? I have no idea. And you want to ensure high quality here, because you're going to have a short sound. You want it to be as clear as possible. So 16-bit, 44 kilohertz stereo. If I can hear your kids screaming in the background, it's not a good notification sound.

And most importantly, you can do this today. We said that the Notification Service would be available later this year, but there's nothing stopping you from going home this week and deciding which sounds are going to be used for notifications. Presumably, they're sounds that you already have in your app for when new data arrives while it's running. So go ahead and decide which sounds you're going to be using for your notifications and bundle them with the first version of your app. This is one of the things you can do right now.

Let's move on to alerts. Things to keep in mind with alerts. First of all, alerts are intrusive. They're a pretty major-scale type of notification. So you really want to use these sparingly. You want to make sure you're not going to overload the user with them. Is the data important, and is it infrequent? Both of those criteria should be met for something like an alert.

And this dialogue appears no matter what. Somebody else's app is running, your alert is going to show up. So ask yourself, do you really want to interrupt other apps? And remember, what goes around comes around. So do you want somebody else interrupting you and stepping in front of that user experience that you're trying to provide? So there's a good citizen thing going on here, where you really don't want to overuse these alerts, otherwise everybody loses, including the user.

You also want to keep them general, because the user might not have gotten to the first dialogue, or they might have forgotten it and dismissed it immediately. So if you're going to send some alerts in succession, will the third one make as much sense as the first? That's very important. You don't want to have a dialogue that talks back to two notifications previously, because the user might have long forgotten what you were talking about.

And I said this earlier, but you don't want to depend on delivery. This is something that's supposed to make your application better. It's supposed to augment the core functionality of your app. You want to get this information to them in a more timely fashion than you would have before the service existed. But you don't want to build an app around it. And you don't want to depend on this mechanism as the way to get really important things to the user right away.

So when would you use an alert? What's a good use case for creating an alert? Well, there's a couple of levels here. There's nice-to-know information, something where I'm walking down the street and I hear the ding and I look up and I see the dialogue and I say, "Oh, yeah, I've been waiting for that. I'll go ahead and deal with it right now. Or maybe I won't." That's why we have two buttons here. When we take a step up to something worth knowing.

In other words, I was heading somewhere and there's been a change of plans and I probably need to adapt to that on the fly. It's a good candidate for an alert. And then, of course, you have need to know. The kind of information that the user absolutely can't wait to hear and needs to do something about as soon as possible.

And this is really, this is where you really want to be is between worth knowing and need to know. I've got nice to know up there, but nice to know is pretty subjective. Like I said before, we all think our data is important. And we don't want to just send FYI stuff. We want it to be actionable things that are going to be important to the user, and we don't want them to happen too frequently. Otherwise, there's always going to be a dialogue up.

So that brings us to when you wouldn't use them. Obviously, if the user doesn't need to know. Can they wait until the next time they launch the app? Can they wait until they get an email? An alert is for timely and important notifications.

Don't waste the user's time. This service is supposed to make your app better, not worse. And we're trusting you to decide appropriately, because none of us wants the user to just uninstall your app because they've gotten too many dialogs.

So, combinations here, the scenarios. If you're going to be using an alert, you're probably also going to have a badge associated with that. And you're probably also going to have a sound. So, you're kind of all in if you've decided you have an alert scenario. There are a few cases where you have an FYI sort of thing where it might just be an alert and a sound. But like I said, you don't really want to concentrate on that. Because if it's not that important, it's probably not an alert. And for badges, you probably want to associate a sound with that as well.

And you may want to provide some settings to tweak that, which brings us to Settings and Preferences. We talked about this in the beginning, but the system fetch new data settings control the service and how the service is used. So things like push versus fetch versus manual, as well as just turning it on and off altogether.

And again, the user can enable or disable the service for just your app or for all apps across the system. And that's something you need to remember. But that's controlled by us. As soon as you register with iPhone OS, you get put in that list and you don't need to worry about the settings to turn things on or off.

And your inline settings should control the rest. So things like choosing a certain sound for a certain type of notification, and maybe things like how often you want notifications to be sent. And that would be something you, of course, relayed back to your user. Excuse me, to your server. And there are tons of things you can put in these settings, but you want to generally keep it simple. You don't want to go crazy.

You don't want to have numerous types of notifications, and I said this earlier. You want to just decide what are the things that are really important. And this is a good mental exercise anyway if you attended John's user experience session this morning. What are the things that the user really cares about? Why did they download my app? And do they want to know about this stuff as it changes at all times? That's what a notification is. You also want to avoid filtering. Stuff like, only send me a notification if these five of my 750 friends update their profile picture.

Managing a UI for that is not going to work out so very well. We really want to keep this simple. So think hard about what's important and what's going to be important to the user. So the key user experience points. Don't annoy the user. I would think that's common sense, but I have to say it out loud. If you annoy the user, they're going to disable notifications to your app, or they're just going to uninstall it, and nobody wants that.

Use badges as your primary notification type. It's usually more than enough to get their attention, especially with a sound associated to it. I pick up my phone, I say, "Wow, I have five unread messages. I'm going to go ahead and launch this app and go take a look at them." Provide clear and short sounds.

Clear as in high quality, as in distinguished and brand, you know, containing your brand so that you can distinguish yourself between other applications on the system. And short, because you don't want to annoy the user as the notifications come in. Maintain proper context. Make sure you have that accurate badge count and have clear and consistent alert messages. Make sure the third dialogue will make sense, even if the user hasn't read the first.

And finally, make sure you're aware of the changing conditions that could happen. You might have an iPod Touch user who's only going to be getting notifications when they're on Wi-Fi. And you have the variability of cell phone coverage. The user might be in Antarctica, they might be driving under a tunnel, they might have dropped their phone on the ground. Keep those things in mind.

So that's really it. This is a short session because it's a simple technology. But things you can do today Prepare your servers. Go home, think about your server architecture, think about what you saw today with these posts and puts and gets. And think about what you're going to need to do to make this work and integrate it easily into whatever you've got set up right now. Think about user experience. Think about what kind of notifications you want to send: dialogues, badges, sounds. Think about how important they really are to the user.

Decide on your sounds. You've probably got some picked already for your app while it's running. Make sure you've got those bundled. That's one thing you can not have to worry about when we finally launch this service. You'll have that taken care of. And finally, plan for a quick upgrade.

I know everybody's dying for the App Store to launch, but at some point we're going to push this thing live, so pencil in a quick update so you guys can move quickly when this service goes live, and you'll be ready to put something out that immediately takes advantage of it. You want to be there quickly after the server's live. You don't want to be there six months or a year later. You want to make sure you've got the edge here before somebody else who's doing something similar has already provided notifications.

We're early here, so we're still working on things. If you want more information, if you want a recap of what we talked about here, a little more detail, you can always get in touch with me. And I'm sure all of you are going to the iPhone Dev Center regularly. Just check back there for any updated information that we have on this service once it becomes available, once it gets closer.

Sessions you want to keep in mind when you go home and start watching videos: the application development fundamentals for the newcomers. I presume everybody was there. But that will get you a little more acquainted with things that I was mentioning, like UI application and notifications. Hopefully by now it's Wednesday. You guys at least know what UI application is.

And the User Interface Design Session, which talks a lot about thinking from the user's mental state. What does the user think is important? What does the user find important? And that should affect the decisions you make when it comes to sending these notifications, as well as designing your application in the first place.

And assuming we run out of time in Q&A, we're going to go ahead and run out to Twin Peaks right behind this for soft seating. And we can go ahead and hear some more of your thoughts and questions and what else you'd like to see out of this service as it moves forward.