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.
Apple Turns on Push Notification Services for Developer Testing
- Thread starter MacRumors
- Start date
- Sort by reaction score
So what? TCP provides the reliability, and IRC servers are quite happy to wait a minute or thirty before ping timeouting you, depending on configuration. Even young whipper-snappers should remember tying up the family 'phone line with their unspectacular modem connection, and the Interweb was designed to run over media far less reliable than that.
Great, so we have two more points of lag and failure - the third party server and Apple's push notification servers. And we haven't even got on to the privacy implications.
Audio notification is something I want when I'm not using the equipment and I'm expecting something important. Otherwise I want something visual but non-modal, a la Growl. If something like that is provided, then strike off this complaint.
This straw-filled gentleman betrays your motives. I want Apple to produce better software, and I don't think Apple always knows best. What about you?And on that note... Apple REVIEWS ALL APPS. That means apps that spam crap all the time won't be accepted. This isn't a free market like the Android. Oh wait, they deny apps too if the cell network tells them tooThey just don't have a junk filter.
If you think the platform will be profitable until the end of days, you're insane: when the profitability stops for Apple, they'll stop supporting the App Store. Just as Apple pulled the plug on third party developers in the late '90s: in that case, it was of Mac-compatible hardware, which became profitable for everyone but Apple.
Dude, there is nothing wrong with a constant connection. You can keep a TCP/IP connection open for a week if you want and exchange no data.
Please, not another annoying buzzword-compliant lock-in framework.
Because there are only so many years one can take of marketing and their neophyte engineer lackeys fixing what's not broken before one gets bored and moves to another field. I thought I might spend my life in software engineering, but now I'm a mathematician-in-training - it's so refreshingly bull-free.
Happy Easter!
Apple has made it the same issue, by bluntly claiming that push notification removes the need for background apps. (Of course, they ignored their own background apps.)
Other OS's have had push notification for years. Most especially Java on phones, which has had a push registry since 2002. But it also had auto-start on notification or timed alarm, which adds to its usefulness.
Reminder, location based, and background music apps need real multi-tasking... not user initiated upon a remote server notification.
As for tasks that usually require network activity, yes a few of them fit the notification model. Others, such as background video downloads or Pandora, don't. Moreover, it's quite a burden on a developer to create a server app, pay for its existence, and maintain its user database, just to save some battery.
Smartphones:
Blackberrys ( certain models ) can manage 3 days
Some Nokia E-Series can manage 3 days
My old SE P900 could manage easily 3 days
I hope your not trying to say because the iPhone can't manage 3 days then no other (smart)phone can't.
I really hope there are smartphones out there that can manage 3 days, but what 3G smartphones out there can run for three days with all those programs running in the background like the OP described? It sounded like quite the exaggeration.
Besides you do lose quite a bit CPU cycles. The Palm Pre video is a good example. I am waiting to see how Palm Pre's real-use battery life is going to be when the actual product is released to public, and how does Pre handle the background processes - especially when WM is already a pain in the a%$.
The "Pre" is an awful name IMO, but if Palm can get the battery life, save the cpu cycles, and do background processes effectively at the same time, I say Apple should worry a little bit then. But based on the technologies we see as of today, Pre doesn't look good, as Apple made it clear: it was easier to do the background processes than the push notification detour if battery life and cpu cycles are not issues.
Agreed. During the keynote, Apple made it sound as if PUSH was going to totally eliminate the need for background running apps. However, apps like Pandora are not going to benefit from PUSH (not unless they are going to constantly be pushing songs to your iPhone). What would be a good compromise is to allow 3 or so apps at a time running in the background, in addition to PUSH.
You also make a good point about developers' resources. In oder for a Todo app to benefit from PUSH, the developer will have to have a server that knows your Todo list. No longer can a developer just produce an app and release it the App Store. Now, if they want to take advantage of Apple's PUSH, they're going to have to keep a database of your Todo's and set up a server to send them to Apple. We're probably going to see a "survival of the fittest" here and amateur developers are likely going to see the demise of their apps (if an alternative app exists that psuhes your content). Sort of like how family owned stores were put out of business by Wal-Mart. But, hey, maybe this will be a good thing for the App Store.
What would be good is for modern consumer operating systems to have less primitive scheduling algorithms. The literature has been discussing methods of prioritisation since the '60s. Your goals are simple:
1. Don't let background apps harm the UI experience of the foreground apps _at all_, by giving them little to zero quantum when a UI response/update is required;
2. Use flow control to improve network performance of interactive applications;
3. Don't let background apps suck up too much total CPU power over time. Publish recommended limits and the throttling algorithm used on misbehaving processes. I still don't understand why modern consumer operating systems don't react more gracefully to that runaway 99% process: why isn't it customary to inform your OS if you're about to use a huge amount of resources, so if you're doing it otherwise it can be assumed you're broken and need aborting?
The consumer scheduling method prevalent in the late '80s through to mid-'90s was cooperative multitasking, of course. Now I'm certainly not suggesting that across the OS, but imagine as a first approximation the foreground app never relinquishing control to other apps (ignoring necessary background daemons) except when it's idling. When there's a UI event, the foreground app immediately gets control back.
I was happy to read upto then, but 2.5 days, every iphone I've seen will last 7 hours with WiFi turned off, 2.5 days, just aint possible unless its in airplane mode.
Yay
You're the man.
You're missing the point. An iPhone IRC app should be connecting you from a third party server on the internet. Even WITHOUT Push this is necessary because cellular connections are NOT that reliable. Your phone, with its unique identifier, simply synchronises with the server that is holding your actual messages.
Push can be a simple audio notification when someone says your name. OH NO, HOW INTRUSIVE. As intrusive as, oh I dunno, any IRC client on a computer. And just like a computer, any decent app will allow you to turn features on and off. There are plenty of ****** apps in the store at the moment, and of course ****** Push implementation is no exception. If the app is bad, don't buy it. Easy. Quit your bitching.
And on that note... Apple REVIEWS ALL APPS. That means apps that spam crap all the time won't be accepted. This isn't a free market like the Android. Oh wait, they deny apps too if the cell network tells them too
Someone also said "What if Apple pulls the plug?"... the chances of that are about the same as them pulling the plug on the app store. Doesn't happen.
Push is a good solution. Yes, it doesn't suit everything... AirSharing, for example, still needs to have the ability to run in the background. But by releasing Push NOW you prevent a bombardment of ****** apps that expect a constant connection when it's absolutely unnecessary. What they should do is release an API for building 'Services' in a few months, with VERY strict guidelines as to what will be allowed. If it can be done with Push, a service with the same functionality should be denied.
Why do people always do this? No matter what the product is, you all flame without thinking about what you're saying. Just let it be released and learn the culture before starting a war.
You're the man.
I have to clarify, that my experience of 3 days+ isn't with 3G turned on nor having constant internet connection. The internet connection is turned on as required. Bluetooth is always on. ( Why have your phone connected constantly to internet if you don't require it?)
Yes, using 3G will kill your battery life, no doubt about it.
Having said that I still stand by saying that it is still possible to get 3 days battery life on other smartphones ( and not just in offline / airplane mode!!).
Like I said, don't compare other smartphones battery life to that of the iPhone. The iPhone battery isn't that great.
No, what happened is that they were surprised to see the amount of devs interested in PNS. They had to do a total PNS rewrite to deal with massive amounts of people who will be using the system. That's why it's so late.
And that's underestimating it. My iPhone easily lasts 24 hours with WiFi on (I'm on EDGE not 3G) and with normal usage. 3G is the biggest battery hog by far. However, I don't buy the 3 days bull either. You can definitely get 3 days if you don't use it much for sure. What would be the point of that though?
iPhone isn't a gold standard!
Get out of the mentality of "if iPhone can't do it then no other phone can"!
I still don't know what phone this is. Turning data on and off doesn't work for me. Why? Well for one I have my emails pushed directly to me, not possible with data off, and if I want to look something up quickly, or check Facebook quickly, or check a pending IM, I'd have to wait 6-7 seconds at least for data to connect.
QuaterSwede said that quote..not I.
Based on reviews for other cell phones, it seems they all compare them to the iPhone. Wonder why..
Actually the iPhone has decent battery life..better than other 3G smartphones. I charge it once a day. And I do a lot of browsing. The problem isn't that mentality but with money as tight as it is for me, I'd like to feel like I'm getting the best bang for my buck..My software is kept up to date with almost quarterly firmware updates. I'd gladly get a Touch Diamond or a G1..problem I have with them is that battery sucks on TD and it doesn't have a glass screen, and the G1 is bulky and a hard qwerty keyboard isn't necessary for me. (I'd consider switching to Palm's WebOS if it came in a GSM version with no keyboard..)
Haaa
Dr. Manhattan & his hefty blue swinging.......ahem... would someone get that guy a bathing suit!
I'm so geek'd over all the new features & speculations!
Push Notifications
MMS
Landscape everything
Copy/Paste
Global Search
H2DP
Turn-By-Turn Navi
A new iPhone with:
a better camera (perhaps 2 cams, one forward facing?)
a magnetometer
video recording
802.11n
native tethering support
a processor speed bump
better battery life!
Did I forget anything?!
I'm greedy & impatient.... Is it July yet?
Dr. Manhattan & his hefty blue swinging.......ahem... would someone get that guy a bathing suit!
I'm so geek'd over all the new features & speculations!
Push Notifications
MMS
Landscape everything
Copy/Paste
Global Search
H2DP
Turn-By-Turn Navi
A new iPhone with:
a better camera (perhaps 2 cams, one forward facing?)
a magnetometer
video recording
802.11n
native tethering support
a processor speed bump
better battery life!
Did I forget anything?!
I'm greedy & impatient.... Is it July yet?
That research literature doesn't mention anything about starvation?
What is the utility of giving background tasks zero quantums for an extended period of time? How is the OS scheduler suppose to know what is OK to starve one to death. And if it is OK to starve an background process to death why is it running in the first place? Do you alert the user you are about to starve it?
Second, once you allow unbounded background processes they will compete against each other in addition to with the foreground app. It is not just a one foreground and one background problem.
iPhone OS can simply borrow from the unix priority/nice mechanism that Mac OS X uses (if it already doesn't). There is little evidence that foreground apps not getting enough cycles is problem for iPhone OS. (the CPU is severly underpowered) Everything Apple has talked about in the design rational for turning off apps has been about battery life. Not that their selected ARM core is underpowered.
Finally, you say "foreground apps". Well if you start enough of those then you eventually run out of resources. Or you want the priority to follow the UI focus? (I'll dive deeper into adding lots of inserts into the scheduler and multithreaded apps later ). And it isn't them consuming UI events that is really going to kill off performance and/or resource consumption. Unless adding multiple users you are limited by how many events a user can generate. No single human is going to overwhelm a modern CPU running a managable workload.
Is it really going to improve performance? It is one thing to run traffic shaping on a external router. All the overhead in that case get sucked up on that external CPU. Likewise, if you have "too many" cores inside your box and you are plugged into the wall for power, you can throw the overhead at these under leveraged resources.
Does that even remotely sound like the normal context of an iPhone?
Furthermore, traffic shaping is usually on protocol/pattern. You are talking having to track not just what is tracked now, but also ports and the process id that each port is using. Then your shaper has to factor yet another dimension into its shaping process. Sure it could be done, but how much overhead have you added?
Again.. where is the evidence this is primarily a bandwidth problem?
Lots of home network routers use ARM cores very similar to the one in the iPhone. They can do traffic shaping and what not also. However, they are also plugged in.
A couple of factors to consider:
And if low CPU cycles but turn on the radio full blast for an hour?
Or low CPU cycles and burns lots of energy rewriting flash cells?
It doesn't have to be a runaway fork bomb that is burning up the power. It is not solely a "misbehaving program" problem. If there 5 programs all chirping away at moderate rate the internet over a 3G network that is going to be a significant power drain. 6, 7, or 8 of them will be even more. It isn't the individual programs managing but the aggregate power. That is yet another data structure for your scheduler to count and manage. You'd have to be able to do accurate blame assignment for all the downstream energy consumption. Don't really even do that for CPU consumption. The scheduler hands out the quantums in the first place. Furthermore you going to have to insert lots more data into your kernel schedule data structures. That requires getting locks. While you structures are locked up the scheduler can't do its job of doling out new quantums because it is not much more busier getting updates.
Fourth what about zombies? There could be mostly comatose processes but they sip resources over a long time.
Why isn't it customary? One, if you inform the OS about every loop construct you are about to enter how many more kernel traps is your program going to take now? Is that kernel trap going to prematurely end your quantum ? ( what if there are 5 other programs all insisting they are more important than you. ) Aren't these kernel costing you overhead. In normal circumstances how much more energy/time are you burning up
The pre declaration makes sense for batch jobs. Regularly run and fairly predictable jobs. For anything that depends upon either user input and/or shared resources how is the code doing to do a accurate estimate?
Never mind that you now need a GUI application to show folks what is running on their phone. You want the average joe blow phone user to manage deamons. Seriously?
Also just how huge is your scheduler? The more complex you make it and the more time it takes to get in and get out of it.
First, the kernel is further in front of the line than the foreground app. It has to get the UI event that is already prioritized ahead of all of the apps. The notion that the event is not caught and handled immediately isn't true now. If the foreground app is paused on a "wait next event" kernel trap it will get put on the "ready to run" queue and get the next quantum it is priority allows it to get.
Second, your ignoring multithreaded applications. One thread in an app could be doing a "Wait next event", but other threads could be off doing other work. A app doesn't have to idle just because it is waiting on UI events. For it to be idle all the threads would have to join and declare they all had nothing to do. (for example on a game even if the user doesn't do anything they could be competing with objects in the game. Those objects in the game aren't going to stop just because the user isn't doing anything. )
The current iPhone application approach now is somewhat a form of cooperative mutlitasking now. When you are in foreground you run. When you go background you turn yourself up. The emphasis is on startup/shutdown store/recovery state.
P.S. another reason is security. One reason folks don't want to drop background worker drones onto the iPhone is that you can't have installable background worker drones. Your virus or trojan would only run when the user ran it explicitly.
Apple's service is to push small notification messages. It is basically an alert to bring some application into the foreground ( in general. ). It is not a bulk file transfer service.
Running a radio isn't a "background" app. What some folks seem to advocating is running two (or more applications at a time). That is questionable with such a small screen.
If talking about an alarm clock notification. Can't do that with the current Alarm clock (or its API). Set an alarm entry that says "Start application xxxx now for some breifly explained reason". There is zero reason to use PUSH for that.
Apple isn't positioning this as a way to run background apps. They are positioning it as a service that can tell you when to wake up an app when there is some external event. If the events are on the iPhone/iPhone there is now need to externally drive them. But that still won't get you a background service.
If developers need better API to an alarm clock notifications then ask for it. It has to be there because the iPhone has an alarm clock. Posting an event entry though doesn't mean your app has to be running in the background. Your trying to build the alarm clock into your app when it already exists outside your app.
Also don't really buy into the background download video thing and just download the video went matched with home/work computer. If you are in a location with crappy bandwidth you don't want to slow that process down by competing for resources. It is a bit restrictive, but it is a phone/ipod... not a general use computer.
Nobody mentioned privacy, if my information is being jumbled around on 5000 different server's theres bound to be a exploit somewhere. I highly doubt each developer is going to put any type of encryption on there server's due to load it takes to constantly en/decrypt information etc. If my information gets lost somewhere or i'm now a victim of identity theft I'de be one unhappy fellow, then who get sued? Apple or the Developer? Apple must have SOME plan for this.. if not, there jumping out a airplane 15000 feet over ocean without a parachute and diving gear.
Not really. I want to talk to clients on Skype while checking my calendar, mail, or looking at a PDF or maps. Push won't do this. This is huge for productivity. I don't care about radio--it won't help me get work done on the road. The items I mentioned will.
To me, the PUSH notification is not the best solution at all.
Let´s say in IM is good idea, but how about radio stream?
Secondly, I hope, that there will be an option to set it in all apps differently.
in some apps only badge, in others popup window.
But I still dont think, that apple is right about battery usage. A use backgrounder with one or two backround apps(usually for a limited time) and battery life is not that bad as the say, and solution to have one or two apps in background is allways better.
With new model-with better RAM, better battery, ...
PALM pre is able to have BG, why an iPhone isn´t?
and how about capacity of apple push servers? if millions of users will for every app use this service, I would preffer shorter battery life, then situation, that the push service will not be runnig due to data overload
Let´s say in IM is good idea, but how about radio stream?
Secondly, I hope, that there will be an option to set it in all apps differently.
in some apps only badge, in others popup window.
But I still dont think, that apple is right about battery usage. A use backgrounder with one or two backround apps(usually for a limited time) and battery life is not that bad as the say, and solution to have one or two apps in background is allways better.
With new model-with better RAM, better battery, ...
PALM pre is able to have BG, why an iPhone isn´t?
and how about capacity of apple push servers? if millions of users will for every app use this service, I would preffer shorter battery life, then situation, that the push service will not be runnig due to data overload