Dont Understand Push Notification

[cellocello]

No, I understood, but they fall into 2 camps:

1) Things that are hard for Apple: Yeah, they know. It took them an extra 8 months to work on it. They killed it the first time when it didn't work, so I don't see why they'd bring it out now if they weren't happy with it.

2) Things that are hard for developers: This service will be most useful to large organizations like ESPN, Google, and Facebook. I really don't think they'll have trouble paying the talent that's needed to do that kind of work. You're not getting push notifications to 'Trism' for any reason.

In other words, I don't consider any of that stuff things worth worrying about.

Ya, I guess he's saying that's it's going to be unlikely that a "mom and pop" shop can make a push-reliant piece of software that's able to take the App Store by storm.

that whole 'metiocracy' thing the trism guy talked about maybe doesn't apply to compelling push things?

 

[detz]

It'll be interesting to see how (few) apps implement push notification.

To use it, developers are going to have to learn to write extremely scalable server code, since half their darned application will be off in a server farm somewhere. And those kinds of apps aren't written in Objective-C, you know.

The server side won't be simple code either, since notifications aren't guaranteed to arrive, and you always have to keep track of the data that the app should know about.

In addition, the poor app server has to know WHEN you go offline, so it can start sending info via Apple instead of directly. Since that would be an enormous pain to figure out, I suspect most apps will simply use the notification service all the time.

Not to mention paying for those servers.

The whole Rube Goldberg scheme falls down for apps that should be able to run in the background, but your server is down. Or Apple's is, since they don't guarantee uptime. Or you're on an airplane.

And how many do you think will just use a badge? None, because how do they know that you'll ever see it? So be prepared for lots of alerts. Since they're individual, and not handled in a single Home screen location, be ready to remember what alerted you.

The Palm Pre (and the new HTCs) will be able to have processes that wake up, then go out while you're sleeping and pre-download the days' events, feeds, and your favorite websites. IPhone? No. That's just one example. What a pain for the user to have to click a popup every time that a background fetch should've happened.

Did you read over the docs for this, this is not how it works. I can write server side code for the push server in under a 100 lines and I don't need a large pool of servers for this to happen. Sure, just like any other online thing if you get tons of traffic you will need more servers to support it but the majority of apps that will have this will not need farms of servers since everything gets pushed off to Apple's servers first. You don't have to keep track of the iPhones and if they are online or offline either, Apple's servers will handle this.

 

[Night Spring]

Apple's servers will handle this.

Last year, when everybody tried to download the 2.0 update at once, Apple's servers didn't handle it very well. They must have anticipated increased usage, yet the demand exceeded their expectations. I suspect a similar thing will happen with push. Someone(s) will think of a way to use push that will trigger far more demand than anyone at Apple would anticipate, and bring the whole thing down.

 

[Smith288]

No, most documentation is written towards the audience, computer programmers. If you don't understand the docs then you're probably not a very good programmer.

Im not a very good iPhone developer (though I program in alternative languages). I admit that. Im a hack currently but im trying to teach myself (some might call that a person of initiative rather than an ignoramus but I digress).

All im saying is that their documentation usually consists of assumptions made that the reader already understands the topic they ultimately are trying to understand. This is more of a criticism of the documentation development. They write it like i already know how to do what im trying to learn how to do.

That doesnt make the subject easily understood for even the new crop of developers they seek. Me included.

The whole "people with computer science background" is a shot at my intelligence as if I don't understand basic programming principals. I've written two very solid selling, albeit simple, iPhone apps (no, not iFart) and would like to become more experienced and knowledgeable in the technology.

 

[Smith288]

It'll be interesting to see how (few) apps implement push notification.

To use it, developers are going to have to learn to write extremely scalable server code, since half their darned application will be off in a server farm somewhere. And those kinds of apps aren't written in Objective-C, you know.

The server side won't be simple code either, since notifications aren't guaranteed to arrive, and you always have to keep track of the data that the app should know about.

In addition, the poor app server has to know WHEN you go offline, so it can start sending info via Apple instead of directly. Since that would be an enormous pain to figure out, I suspect most apps will simply use the notification service all the time.

Not to mention paying for those servers.

The whole Rube Goldberg scheme falls down for apps that should be able to run in the background, but your server is down. Or Apple's is, since they don't guarantee uptime. Or you're on an airplane.

And how many do you think will just use a badge? None, because how do they know that you'll ever see it? So be prepared for lots of alerts. Since they're individual, and not handled in a single Home screen location, be ready to remember what alerted you.

The Palm Pre (and the new HTCs) will be able to have processes that wake up, then go out while you're sleeping and pre-download the days' events, feeds, and your favorite websites. IPhone? No. That's just one example. What a pain for the user to have to click a popup every time that a background fetch should've happened.

Server farm? To push notifications to Apple? Holy moly, what would you plan on pushing???

 

[detz]

Last year, when everybody tried to download the 2.0 update at once, Apple's servers didn't handle it very well. They must have anticipated increased usage, yet the demand exceeded their expectations. I suspect a similar thing will happen with push. Someone(s) will think of a way to use push that will trigger far more demand than anyone at Apple would anticipate, and bring the whole thing down.

Push is not downloading large files or even large amounts of data. When they released the new version everyone with an iPhone wanted to download a 300mb+ file. Each push notification is very small, here is a sample of a message form the Apple docs. We're talking bytes here, very quick and easy transactions.

 

[kdarling]

Server farm? To push notifications to Apple? Holy moly, what would you plan on pushing???

It's not the push. It's the accounting and possibly the need to put a duplicate of the app on the server.

So it depends on what your app is all about.

If it's just a case of one phone sending notes to another, then yes the server code is not large, but it's not simple either. You still need a server, or servers.

Even one server is an expense that might not have existed when your clients talked directly to each other.

You'll want to maintain a database of your registered users, and authenticate requests against it, since Apple expects you to send only to your current users.

Apple also expects you to keep track of the notifications you've sent the application, because they don't guarantee delivery. So if the notification doesn't make it, and the user just happens to start the client app, it'll expect to be updated from its app server. Thus the server must maintain per-user state if the app is to be robust.

Remember, Apple doesn't send data back and forth. It just alerts the user to start the "background" app, which is then expected to go to its app server to get its latest data. Ironically, the user has become the kernel's task manager.

The best background apps don't require user intervention, but Apple has made it a requirement. Unlike the Java Push Registry that Apple took the whole idea from, the server cannot start the app... the user has to be prompted to do so with an alert. Not exactly a grand solution.

So far, we've just mentioned super simple apps. When we start comparing truly intelligent background tasks, things get much more interesting. A great deal of the app might have to be written on the server, which is always running.

 

[kdarling]

My point is, push notification is not a replacement for background processing.

Consider what can be (and is) done on other phones, that just don't work with Apple's kludge:

Background GPS apps. Other devices can watch where you're going and make pro-active suggestions, keep a travel log for you, alert kids when you're close to picking them up. iPhone? Forget it.

Offline reminders. My favorite example is that of a nice pill reminder app, that pops up a picture of the pill(s) you need to take. On other devices, the app can register to start at a certain time. (Not even have to be active in the background.) Under Apple's plan, you'd have to grow this from a simple standalone client into a server app with the corresponding user authentication and alarm-time databases. Of course, if you're on a trip in airplane mode, the app can't get a notification.

Background loading. As mentioned before, other phones can learn what you like, and various apps can preload those sites and info while you sleep. Again, not possible with the iPhone, because there's no one awake to see the timed server alert and manually start those apps.

At the least, Apple needs to allow apps to register for timed background running of a stub or something.

 

[kdarling]

You don't have to keep track of the iPhones and if they are online or offline either, Apple's servers will handle this.

Apple expects your client to talk directly to your server, until such time as your client is not running (say, you answered the phone). At that point, your server is supposed to know to start sending notifications via Apple... not before... and again, not after comms are up if/when the app is restarted.

The notification path is ONE-WAY only (from your server to Apple's). There's no acknowledgement or guarantee of receipt, since Apple's afraid of the load.

The only way around this is to always send notifications via Apple's servers, at which point the app goes to the server to ask for what's going on. Assuming the user starts it. And that Apple is okay with you doing it.