This is the technology that Apple is trying to put with 3.0, right? If a 3rd party application (like Facebook) wants to notify you, it goes through Apple's server. It's the same thing as SMS, but how much battery does it use? If you have your phone on "push", it's not always checking for mail every second, but it leaves itself open. If something like email or an ESPN notification will use the same server as an SMS message, does it still take away from iPhone battery? I'm thinking of putting my phone on Push, how much battery does it take away
Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Push notifications?
- Thread starter SephirothXR
- Start date
- Sort by reaction score
As the keynote says, background notifications bring standby time down by 80%, but 23% only for push notifications (as far as I can remember)
Standby time? So when your phone is in sleep mode, but you have push on, the phone checks occasionally still? I'm a little lost, sorry. If notifications are sent through PUSH as text messages, is that better than sending them through PUSH as emails?
Push is push, it doesn't matter if you're talking email or new push notifications. The way push works is your phone keeps a constant connection with the Apple servers and anything that comes in to Apple(email or notifications) and is destined for you phone goes to Apple and down that connection to your phone. The reason this works better is the phone only has to have one app running in the background accepting connections instead of countless others. Apple has optimized this app so it works the best it can and save battery.
They're not sent as SMS text messages to the phone.
Most likely they're done the way most "push" implementations are: the phone talks to the notification server as often as needed to keep a connection alive between them, which usually means anywhere from 5 to 45 minutes. When the server has a notification, it sends it down to the phone.
It is up to you to manually start the application, which then talks directly to the application's servers (not Apple).
Note that it's a one-way path, which means there's no acknowledgement that the phone actually got the notification.
Actually no, the ADNS will send back whether or not the message was received. This allows the developer (such as AIM or facebook) to know that the app is deleted, and not send any more messages
They're not SMS and they're not emails.
They are their own breed of notification. How much battery life they take up is going to depend on how many apps you have notifying you and how often each one does and what kind of notifications you are getting. Turning on pop up alerts and sound alerts instead of just badges are going to use more battery (has to make a sound or turn on the screen).
As long as you don't have a huge number of apps sending you a ton a messages, you probably wont even notice.
Remember, YOU can control who sends you notifications and how. If you dont have enough battery life, turn some off.
They are their own breed of notification. How much battery life they take up is going to depend on how many apps you have notifying you and how often each one does and what kind of notifications you are getting. Turning on pop up alerts and sound alerts instead of just badges are going to use more battery (has to make a sound or turn on the screen).
As long as you don't have a huge number of apps sending you a ton a messages, you probably wont even notice.
Remember, YOU can control who sends you notifications and how. If you dont have enough battery life, turn some off.
I haven't looked at the API in a while, but are you sure each message is acknowledged? That wasn't part of the protocol at first.
Or are you talking about the monthly list of bad ids that Apple said they'll send to each app server, so you can mark off non-existent clients?
mackmgg is somewhat incorrect, the developer doesn't get acknowledgement of any notifications sent (good or bad). However, APNs will notify the developer if the device doesn't receive notifications for a while.
Apple says APN is one-way, but also that APNS will resend notifications that weren't received in the situation that the device was off.
The one-way comment in the documentation is regarding communication between the developers and the APNs - they can't expect any sort of advisory that a specific notification wasn't received. However, there is two-way communication between the APNs and the device. In other words, the notification acknowledgement is sent to the APNs, but not to the developer. Developers can pull a list of non-responding devices that APNs generates.
If APNs blindly sent notifications, how would it know which notifications to resend to which devices? And how would it eventually know to send a bad device id (uninstalled app alert) to a developer?
And I'll state it again, according to the APNs documentation, the device does not send keep-alive requests. Turning on Notifications opens a port and notifications can be received without contact with the server. If the device does not send an acknowledgement back, the APNs stores it for later sending. It appears you've stepped back on notch from your last comment regarding Apple's APNs, "Except for Blackberries, "push" is really an repeated pull."
Which is exactly what I said. Getting a list of non-responsive devices, perhaps days later, is not a realtime message acknowledgement.
That would only be possible if every world carrier assigned a static IP address to each iPhone. That's extremely unlikely.
They might not call it a keep-alive, but each phone has to send the notification server its UID whenever its IP address changes. Otherwise the server would have no idea how to address a notification.