Why does the push notification matter so much?

[daihard]

This is my honest question. I cannot see any significant benefit of the push notification service that a lot of folks here seem to want so badly. E-mail (at least Yahoo!, MobileMe and Exchange) already has push. What other application can benefit from it?

TIA...

 

[jmann]

notes, calendar, im applications, etc. I'm sure there are others.

 

[Masquerade]

This is my honest question. I cannot see any significant benefit of the push notification service that a lot of folks here seem to want so badly. E-mail (at least Yahoo!, MobileMe and Exchange) already has push. What other application can benefit from it?

TIA...

are you on drugs?

 

[ChrisBrightwell]

What other application can benefit from it?

AIM and Twitteriffic are two that I can think off, just off-hand.

 

[daihard]

notes, calendar, im applications, etc. I'm sure there are others.

Notes and calendar, as in the built-in iPhone apps? I'm not sure how beneficial push would be for them. Push makes sense for e-mail, because you may wish to know right away when someone sends you mail. For notes and calendar, it's usually yourself who modifies your entries; then should it not be enough if Notes (or Calendar) grabs those new/changed entries the next time you open it?

AIM and Twitteriffic are two that I can think off, just off-hand.

As for IM and twitter apps, I don't think the SDK allows third-party apps to run in the background now. How will push get around it? Or is the introduction of push supposed to remove this restriction as well?

 

[Michael CM1]

I would love for all of my news apps (AP, NY Times, ABC, USA Today, etc.) and my RSS reader to put the little badges on the icon when a new story comes up. That's my main desire for it, although maybe I'd use AIM if I didn't have to be logged on to the app to get an IM.

 

[cellocello]

As for IM and twitter apps, I don't think the SDK allows third-party apps to run in the background now. How will push get around it? Or is the introduction of push supposed to remove this restriction as well?

Oh wow.

Are you answering your own question? Or are you kidding? I don't know what's going on here.

 

[bluenoise]

As for IM and twitter apps, I don't think the SDK allows third-party apps to run in the background now. How will push get around it? Or is the introduction of push supposed to remove this restriction as well?

This is precisely why it's needed. Steve Jobs himself described this very issue when he promised this feature last Summer. The idea is that apps won't need to run in the background. The push notification service would handle the requests and, presumably, launch the appropriate handler app for each notification. So, if the system gets an IM notification, it could launch the AIM app and display it. At least, that's the gist of it AFAIK.

 

[Michael CM1]

This is precisely why it's needed. Steve Jobs himself described this very issue when he promised this feature last Summer. The idea is that apps won't need to run in the background. The push notification service would handle the requests and, presumably, launch the appropriate handler app for each notification. So, if the system gets an IM notification, it could launch the AIM app and display it. At least, that's the gist of it AFAIK.

I think you kinda have it right. The way I understood it for AIM was some part of the app or service would be active on a remote server run by Apple. When someone sends you an IM, it would do its magic on that server and then put a little badge on the AIM icon and probably play a sound on your iPhone/iPod touch letting you know that an IM has been sent to you. Basically what the SMS app does. That would use power on the server side instead of the iPhone, which would die quickly if it ran apps in the background.

 

[Masquerade]

As for IM and twitter apps, I don't think the SDK allows third-party apps to run in the background now. How will push get around it? Or is the introduction of push supposed to remove this restriction as well?

that's the nature of push notification. Instead of running app in background the running app configure through "push notification API" how their service should work in the central apple server. then when you close the app, a deamon on iphone will mantain a persistent and unique connection to the apple server. the apple server talks with the application server, instead the app itself. this design is scalable to many apps and needs only one connecton...

 

[nfl46]

BeeJive...

well Applications in general!

 

[kdarling]

It's nothing new

It's a simpler copy of what Java Mobile (J2ME) devices have had since 2002: a push registry.

Under Java an application registers for a type of incoming connection, or even an onboard timer event. When a push message arrives or a timer fires, the registered application will be either started, or woken up if just sleeping.

AFAIK, on the iPhone the push notification simply shows a sound, message and/or badge... and it's up to the user to start the app. (There are no timer events on iPhone.)

What it's good for:

It's good for any apps that would normally expect INCOMING information from a server. Like IM, or mail, news alerts, or even a shared game.

What it's not so good for:

For normal background apps, like voice navigation while you're on the phone, it's useless because that kind of app doesn't normally expect a server to tell the phone where it is. (Other phones keep navigating while you're doing something else.)

Other phones have background apps that watch your GPS location and change your ringer profile, or alert your friends / kids that you're close. The iPhone can't do that in the background for you.

Why it's a poor replacement for timer tasks

My favorite example is an app that wakes up and shows you a picture of the pill you should be taking (which would normally be done by an onboard timer).

Yes, you _could_ register with a server and have it push a notification down. Of course, if you're out of server contact, as you'd be on an airplane, the app is useless.

Who pays for the server?

And all of these assume the app programmer has the desire to maintain or pay for servers to begin with. Perhaps Apple is trying to figure out a way to host apps as well... for a price no doubt.

 

[daihard]

that's the nature of push notification. Instead of running app in background the running app configure through "push notification API" how their service should work in the central apple server. then when you close the app, a deamon on iphone will mantain a persistent and unique connection to the apple server. the apple server talks with the application server, instead the app itself. this design is scalable to many apps and needs only one connecton...

Thanks, Masquerade and others, for the explanations. I think I got it. So instead of the applications themselves running in the background, this one daemon process will keep track of the push notifications that come from Apple-maintained server. For instance, an IM app can tell the daemon to launch it when the notification server sends a push saying someone sent you a message... do I get it (roughly) right?

 

[milani]

As for IM and twitter apps, I don't think the SDK allows third-party apps to run in the background now. How will push get around it? Or is the introduction of push supposed to remove this restriction as well?

That's the point. That is why we currently don't have push. They're trying to figure out how to best go about background applications so as to minimize battery loss and system taxation.

 

[ChrisBrightwell]

... do I get it (roughly) right?

Close enough. Push Notification lets you put a badge on your icon and trigger an alert (a tone or vibration) to get the user's attention, but that's it. The notification daemon will handle all of that, then the user will open the app to get the actual update.

Some apps are ripe for this, as the AIM client doesn't log you out when you exit it by default. This leaves the door open for folks to IM you and, when you get the Push Notification from Apple, know that you got the message and offer a response.

That's the point. That is why we currently don't have push. They're trying to figure out how to best go about background applications so as to minimize battery loss and system taxation.

Push Notification was designed, from the beginning, to work without having apps run in the background at all.

 

[tusharbhatta]

launch application on scheduled time

Hi,

Could you please show an way how could I launch my custom iPhone application in a specified time ?
I would like to build an application like task scheduler/reminder using 2.0 sdk. It will launch automatically in a specified time and show user about his/her task for that time.

Could you throw some light ?



Thanks

 

[deadsouls]

This is my honest question. I cannot see any significant benefit of the push notification service that a lot of folks here seem to want so badly. E-mail (at least Yahoo!, MobileMe and Exchange) already has push. What other application can benefit from it?

TIA...

wow. you must not know much at all.

 

[markgamber]

It's a simpler copy of what Java Mobile (J2ME) devices have had since 2002: a push registry.

Under Java an application registers for a type of incoming connection, or even an onboard timer event. When a push message arrives or a timer fires, the registered application will be either started, or woken up if just sleeping.

AFAIK, on the iPhone the push notification simply shows a sound, message and/or badge... and it's up to the user to start the app. (There are no timer events on iPhone.)

What it's good for:

It's good for any apps that would normally expect INCOMING information from a server. Like IM, or mail, news alerts, or even a shared game.

What it's not so good for:

For normal background apps, like voice navigation while you're on the phone, it's useless because that kind of app doesn't normally expect a server to tell the phone where it is. (Other phones keep navigating while you're doing something else.)

Other phones have background apps that watch your GPS location and change your ringer profile, or alert your friends / kids that you're close. The iPhone can't do that in the background for you.

Why it's a poor replacement for timer tasks

My favorite example is an app that wakes up and shows you a picture of the pill you should be taking (which would normally be done by an onboard timer).

Yes, you _could_ register with a server and have it push a notification down. Of course, if you're out of server contact, as you'd be on an airplane, the app is useless.

Who pays for the server?

And all of these assume the app programmer has the desire to maintain or pay for servers to begin with. Perhaps Apple is trying to figure out a way to host apps as well... for a price no doubt.

Well put. The fact that the whole thing falls on it's face when you're out of contact with the server is why I think Apple's vision of push as a replacement for background processing is as shortsighted as only allowing web apps on the original iPhones. And as mentioned, it does nothing for Orblive, Slingplayer (if it ever happens), radio apps, GPS apps and so on. Plus I simply can't imagine Apple relegating control of a "push server" to just anyone and giving up the chance to micro-charge the user when he or she gets an IM, has to take a pill or whatever else they set up for notification. After all, a tiny percentage of a huge number is significant. It's much easier to see Apple controlling everything and giving the developer a cut. The bottom line is that I believe Apple's push notification will fall squarely into "Be careful of what you wish for, it might come true".

One other thing...this talk of how Apple wants push to save battery life doesn't sound all that legit, either. Windows Mobile phones have supported full multitasking since, as far as I recall, day one and the considerably older battery on my Tilt will most definately outlast that in my iPhone...right now...any day of the week. This isn't to promote Windows Mobile, it's to point out that push "extending battery life" is either an admission that the iPhone's battery is crap or that Apple is looking for a better reason for no true background processing than "Because we said so". C'mon, my mom stopped using that excuse when I was 5. And again when I was 38.

 

[kdarling]

Could you please show an way how could I launch my custom iPhone application in a specified time ?

You can't. The iPhone's OS is deliberately crippled to prevent non-Apple programs from running either in the background or via a system event / timer.

If/when it gets application push notifications, then you will be able to, but in a convoluted manner:

1)The user would enter the desired wakeup time, and your iPhone client would send the information to a server that you own or rent.

2)At the entered time, your server would send a notification to Apple's servers.

3)Apple's servers would send the notification down to the iPhone, where it would display a badge, sound or popup alert.

4)The user would hopefully notice the badge/alert and restart your application.

5)Your application would either look locally in storage, or ask the server, what the alert was about.

Wrong topic... thread hijack, etc.

But good timing.

 

[kdarling]

Plus I simply can't imagine Apple relegating control of a "push server" to just anyone and giving up the chance to micro-charge the user when he or she gets an IM, has to take a pill or whatever else they set up for notification.

IF they continue with their scheme, it would also not be too surprising if each user was required to have a MobileMe account for the background push notification to work.

 

[cellocello]

Well put. The fact that the whole thing falls on it's face when you're out of contact with the server is why I think Apple's vision of push as a replacement for background processing is as shortsighted as only allowing web apps on the original iPhones.

I don't think Push is meant to "replace" background processing - I think it's truly and purely a messaging system. What other applications are there for Push (in this scenario) that aren't just notifications / messages?

Background 3rd party processes may come in the future (in some future version of the hardware no doubt )

And battery life ... ya, it's not the longest thing in the world. But in fairness, your Tilt isn't half the phone the iPhone is. With a screen this big and a CPU this fast, and multi touch awareness and full hi-colour hi-res moving graphics ... I wonder how long the tilt battery would last powering the iPhone.

 

[markgamber]

I don't think Push is meant to "replace" background processing - I think it's truly and purely a messaging system. What other applications are there for Push (in this scenario) that aren't just notifications / messages?

Background 3rd party processes may come in the future (in some future version of the hardware no doubt )

And battery life ... ya, it's not the longest thing in the world. But in fairness, your Tilt isn't half the phone the iPhone is. With a screen this big and a CPU this fast, and multi touch awareness and full hi-colour hi-res moving graphics ... I wonder how long the tilt battery would last powering the iPhone.

Err...the Tilt is considerably MORE phone than the iPhone. The CPU speed is nearly the same....400MHz on the Tilt, 412MHz on the iPhone. You'd never notice the difference. Never. The Tilt also has full multitasking support, A2DP support (plus lots of other devices) with bluetooth, a slide-out keyboard, resistive screen (you don't need some half-assed Apple gloves to use it when it's 3 degrees outside) etc. The Tilt battery would last longer in the iPhone just like it lasts longer in the Tilt. I have an iPhone because I develop for it, not because it's better than most smartphones available on the market today. Even my old Blackberry 8800 supports background processing, A2DP audio and TBT GPS.

 

[cellocello]

*shrug* I dunno, it's just another not particularity impressive WinMo phone. To me, at least.

Anyways .... my first two paragraphs were the real "point" of my post.

 

[markgamber]

I do know, I develop for lots of platforms. Regardless, considering it took a near riot for Dear Leader to even lower himself to grace us with more than web apps, I seriously doubt we'll be seeing true multitasking any time soon, if ever. There might be a 3rd party app here or there that does it if the company chokes up enough in licensing fees and Apple doesn't steal their idea outright, but it won't be a generic feature of the OS as it is with pretty much every other high end phone on earth.

 

[Niiro13]

As for IM and twitter apps, I don't think the SDK allows third-party apps to run in the background now. How will push get around it? Or is the introduction of push supposed to remove this restriction as well?

Push allows a server to send notifications to the phone.

For IM applications, it would work like this:

Open AIM app.

Sign on. Phone sends message to AIM server saying to sign on.

Close AIM app. Phone sends message to AIM server saying that we haven't logged out, but we're closing the AIM app.

AIM keeps you signed in on their side.

You receive a message.

AIM sends that to the phone in the form of a vibration, sound, badge, and pop up.

Currently BeeJive, MobileChat, and Palringo does everything except for the last part. Instead, they simply save the message until you open the application again.

Push doesn't allow background apps. But it allows for the server to send messages when they receive it instead of waiting for you to open it back up again. That's why you can receive SMS without having the SMS application running (it doesn't even run in the background). That's also why Push won't solve radio applications, timer applications, and the fitness applications.

Remember, the server is the one that handles the buddy list, status, received messages, sent messages, etc. All the application does is show you all this (and of course letting you change it)...kinda like looking at a really nicely formatted log.