Where in the world is background notifcations!

[cere]

You're missing the point.

If Apple announced nothing then people would moan that the background process issue on the iPhone is unresolved. So basically, however Apple announce this feature would result in moaning. They wouldn't have announced it for October if they felt there wasn't a reasonable chance of it doing so.

If Apple announced nothing, then yes, people would bitch about no background apps because a single function device is not much of a communications device. Their solution of push notifications through the OS is elegant. As far as having missed the deadline, sure unforeseen things happen and deadlines are missed. They don't help by dedicating resources to useless, unannounced features like emoji. If you miss a deadline, deal with it and try to catch up. Changing your focus to worthless projects doesn't help.

And for the dude who said their sidekick did push - give me a break. This is hardly the same thing. We are talking about a centralised push system for potentially thousands of apps to millions of users. Push email is ONE app. Push IM is ONE app. Now consider every app in the store pushing out notifications constantly to users. It's a serious piece of engineering and the fact it's ran over schedule is hardly surprising. But given that it was available in the betas suggests they are making progress with it.

RIM has a few million BB out there and they appear to have push privided to the apps through the OS figured out.

And for those who criticize every feature but the ones they want... Get real. It's not like there is one team working on a feature at a time. And the likes of emoji are quite important for uuum, 150m potential Japanese users.

emoji were not announced. They would have been better served to take those developers and use them to help catch up to already missed, public deadlines.

 

[macbookairapple]

So I guess Apple should release it, if it's a buggy mess so y'all can complain about it?

 

[anjinha]

They have to sort out the problems of reliably handling MobileMe push and notifications before they let thousands of developers add to the load on their servers.


.

What do you mean? Mobile Me is very reliable, I get my emails on my iPhone faster than on my mac.

 

[cere]

So I guess Apple should release it, if it's a buggy mess so y'all can complain about it?

Yes, that is exactly what everyone is asking for. Maybe they could announce a couple dozen other features that are to be released next month to spur holiday sales and then not release them at all. (or maybe they should just focus on getting it out in a timely basis, since there are obviously users that are anxiously awaiting the feature that they announced and set a public deadline for...or they could work on a flashlight app or something first.)


Some people like to post nothing but complaints about Apple. There are many, many haters who hate the iPhone for no other reason than it comes from Apple, though they would hardly admit to this. These people are fools. Just as foolish are those that cannot see fault with a product when there obviously is for no other reason that it comes from Apple. The idiot fanboies are what give Apple users a bad name.

 

[Project]

If Apple announced nothing, then yes, people would bitch about no background apps because a single function device is not much of a communications device. Their solution of push notifications through the OS is elegant. As far as having missed the deadline, sure unforeseen things happen and deadlines are missed. They don't help by dedicating resources to useless, unannounced features like emoji. If you miss a deadline, deal with it and try to catch up. Changing your focus to worthless projects doesn't help.

Yes, because those working on emoji are also working on Push notifications...? Apple is capable of developing more than a single feature at a time you know. Its not like they said mid-way - "I know, lets stop doing Push and create emoji!". Your point shows a naivety to the realities of the software business. You don't just add developers to a problem and expect to shorten the development cycle. I presume you are familiar with the mythical man month.

RIM has a few million BB out there and they appear to have push privided to the apps through the OS figured out.

Again, comparing push email to what Apple is doing is hardly like for like. And even if it was, RIM has been in the mobile business for 25 years. Apple just 2.

emoji were not announced. They would have been better served to take those developers and use them to help catch up to already missed, public deadlines.

sigh.

I'm sure the artists who designed the emoji icons are well versed in building a hugely scalable architecture for real time messaging on an arbitrary application level.

 

[Masquerade]

Why Apple’s “Push Notification Service” is Not Enough to Replace Background Processin

good article:
http://www.thomas-fitzgerald.net/2008/08/19/why-apple%E2%80%99s-%E2%80%9Cpush-notification-service%E2%80%9D-is-not-enough-to-replace-background-processing/

 

[cere]

Yes, because those working on emoji are also working on Push notifications...? Apple is capable of developing more than a single feature at a time you know. Its not like they said mid-way - "I know, lets stop doing Push and create emoji!". Your point shows a naivety to the realities of the software business. You don't just add developers to a problem and expect to shorten the development cycle. I presume you are familiar with the mythical man month.

My naivety to the realities of the software business must come from my years as a software developer and project management.

Yes, Apple is capable of working on more than one feature at a time, and it would be good form for them to work on features that they have announced and are already late than to devote resources to other less important features. And yes, in many cases, adding developer resources (and QA etc) will often shorten the development cycle.

Again, comparing push email to what Apple is doing is hardly like for like. And even if it was, RIM has been in the mobile business for 25 years. Apple just 2.

Umm...you did know that RIM's push architecture goes beyond email, right? Please say you knew this. Maybe you didn't, it would explain a lot. Yes, RIM has been doing Push longer. Not 25 years with the BB or their modern push architecture, but longer than Apple. Having said that , Apple has been around a lot longer than RIM and should have their development planning at at least as good a level as RIM. I believe they have the best planning and execution in the world. They need to live up to that standard with Push, which was one of their premier flagship features for the iPhone 3G

sigh.

I'm sure the artists who designed the emoji icons are well versed in building a hugely scalable architecture for real time messaging on an arbitrary application level.

And you think that no developers were involved? That is not just naive, it is just a stupid comment. This doesn't mean the developer from one project could easily be migrated to the other. But to believe that Apple could not redirect resources to Push to finally get it done (and done right) is just making dumb excuses for the sake of defending Apple.

As I said, those who blindly defend all things Apple, just because they are Apple are as foolish as those that hate on Apple just because they are Apple. There are too many of both.

 

[cere]

Maybe this explains where Push went. If the carriers, specifically AT&T, are pressuring Apple to delay, change or constrain the utility of their Push implementation, that might explain why we have not seen nor heard a thing about it since it was quietly pulled from 2.1 betas.

It isn't like a precedent hasn't already been set with Apple pulling existing and denying new tethering apps, at the request of AT&T. This was done across the board for all AppStores, even though some carriers (like mine in Canada) allow tethering with their data plans. AT&T made enough noise and everyone else loses. Perhaps something similar at play here.

 

[bettykoyle]

it was likely delayed.. they likely couldnt do it right without draining battery

you will hear about it at macworld 09

 

[question fear]

What I don't get is why Apple won't allow certain apps background access. A game doesn't need it, but why not put other requirements on devs if they want background support, like for AIM, and let them meet whatever exacting standards the native apps have that allow them to multitask.

The only reason Apple is having issues with background notifications is because they, for some odd reason, absolutely refuse to allow any 3rd party to have access to the OS to multitask. If they're having bandwith or battery issues with their hamstrung system it's their own damn fault for being foolishly stubborn.

 

[kdarling]

good article:
http://www.thomas-fitzgerald.net/2008/08/19/why-apple%E2%80%99s-%E2%80%9Cpush-notification-service%E2%80%9D-is-not-enough-to-replace-background-processing/

What I don't get is why Apple won't allow certain apps background access. A game doesn't need it, but why not put other requirements on devs if they want background support, like for AIM, and let them meet whatever exacting standards the native apps have that allow them to multitask.

+1 to both

Central-server based notification is an answer to a question that very few types of applications asked.

It's okay for IM type apps. It's useless for navigation. How will a server know where you are, in order to wake up your GPS app and tell you to turn? How will your phone know when to change profiles based on where you are? So many location based apps are impossible with this no-background-task lockdown.

Apple-server-based notification is super overkill for reminders, and totally worthless if you lose connection (like, say on an airplane).

The upshot is, Apple's desire to prevent any kind of slowdown sounds great on paper, and even works on the surface in practice. But owners and developers will have to come to grips with the fact that the iPhone will always be capable of less than other devices.

I hope that sooner or later, just as they had to do with allowing third party apps in the first place, Apple will give in somewhere.

 

[TheSpaz]

good article:
http://www.thomas-fitzgerald.net/2008/08/19/why-apple%E2%80%99s-%E2%80%9Cpush-notification-service%E2%80%9D-is-not-enough-to-replace-background-processing/

Good article. Thanks for that.

 

[cere]

What I don't get is why Apple won't allow certain apps background access. A game doesn't need it, but why not put other requirements on devs if they want background support, like for AIM, and let them meet whatever exacting standards the native apps have that allow them to multitask.

The only reason Apple is having issues with background notifications is because they, for some odd reason, absolutely refuse to allow any 3rd party to have access to the OS to multitask. If they're having bandwith or battery issues with their hamstrung system it's their own damn fault for being foolishly stubborn.

Having background apps running can be problematic. They tie up resources like CPU and memory and will result in memory drain. While individual apps running might not cause a problem, dozens running concurrently might impact performance and battery life substantially. For this reason, an OS supported Push platform is a good solution, as it requires only a single additional process to be running in the background.

 

[bit_bucket]

Read up on Agile Development

I see lots of complaints about Apple taking developers off of Push Notifications to work on the updates of 2.2. This is just nieve to think that this happens in modern software developement. Really they have multiple small teams working on each thing in quicker iterative developement cycles. In no way would adding more developers to a project make it get released faster. On the contrary it would make it much slower and error prone. Go check out Agile Developement mentality. It is replacing the old dev methods learned in your CS classes. There are quite a few companies that have adpoted this mentality. I bet Apple is one of them. Their betas kind of elude to it. And otherwise this is a huge undertaking on the backend infastructure.

 

[cere]

I see lots of complaints about Apple taking developers off of Push Notifications to work on the updates of 2.2. This is just nieve to think that this happens in modern software developement. Really they have multiple small teams working on each thing in quicker iterative developement cycles. In no way would adding more developers to a project make it get released faster. On the contrary it would make it much slower and error prone. Go check out Agile Developement mentality. It is replacing the old dev methods learned in your CS classes. There are quite a few companies that have adpoted this mentality. I bet Apple is one of them. Their betas kind of elude to it. And otherwise this is a huge undertaking on the backend infastructure.

Really, it depends. Sure, the rule of diminishing returns comes into play when considering simply adding additional resources. However, it is just wrong headed to make a blanket statement like " In no way would adding more developers to a project make it get released faster". Quite obviously, up to a point there are significant advantages to adding additional resources. At a certain point the diminished returns will result in the 'too many cooks' syndrome and productivity will suffer. The fact that they are two months late, without any updates as to why does not make me think they are suffering from having too many resources working on the problem.

Agile development certainly has its place and it certainly is buzzword compliant for the last few years. Apple may well be using an Agile philosophy, but that in and of itself does not rule out a benefit from additional resources. Push being so late is not necessarily directly related to a lack of resources. It does point to a lack of focus on the feature or a change in direction regarding the feature. Apple announced the feature to compensate for their decision to prevent background apps. It is a fairly good solution. They need to get it done. If that means more resources, then do it. If it means refocusing existing developers on the project, then do it. If it means a further delay, then announce that. There are apps that are just useless until Push is available. Some are functional, but crippled. Some buyer bought believing that Push was right around the corner and was a suitable compensation for the lack of BG processes. This needs to be rectified, regardless of the excuses or reasons.

No one said they pulled devs off of Push to work on other features. They do have the option of prioritizing projects. Push should be the number one priority right now.

 

[question fear]

Having background apps running can be problematic. They tie up resources like CPU and memory and will result in memory drain. While individual apps running might not cause a problem, dozens running concurrently might impact performance and battery life substantially. For this reason, an OS supported Push platform is a good solution, as it requires only a single additional process to be running in the background.

There are two ways to handle this:

1) The OS has a mechanism that goes through and shuts down programs after X amount of inactivity by the user, or if the memory reaches a certain low (with a pop up to the user explaining that if nothing is done, X, Y and Z programs will be exited to improve memory usage.)

2) Limit the background process to certain apps that meet a higher vetting standard than the regular apps. If you want your to-do program to have alarms, you have to prove it won't be a memory hog. Or if you want your IM program to have background notifications, you have to prove it works within certain parameters of CPU and bandwith use.

This isn't rocket science, and it's not like other OS companies don't already do this. For all the complaints piled on Windows Mobile, I haven't had any memory issues with my Epix (which replaced my iPhone as my main phone). Is it perfect? No, but neither was the iPhone. And as a user, I recognize that certain programs have a bigger memory footprint and choose to actively exit them.

And what really boggles my mind is that a simple flip phone for free from AT&T can run AIM in the background. Apple is working incredibly hard to prove that square wheels work just as well as round wheels, if you don't mind all the bumping and shaking and sometimes on rough ground you won't go anywhere.

The iPhone is a neat device, but it fails miserably in certain areas for no reason other than Apple doesn't want to play well with others. It's their right, but that's what it boils down to.

 

[cere]

There are two ways to handle this:

1) The OS has a mechanism that goes through and shuts down programs after X amount of inactivity by the user, or if the memory reaches a certain low (with a pop up to the user explaining that if nothing is done, X, Y and Z programs will be exited to improve memory usage.)

2) Limit the background process to certain apps that meet a higher vetting standard than the regular apps. If you want your to-do program to have alarms, you have to prove it won't be a memory hog. Or if you want your IM program to have background notifications, you have to prove it works within certain parameters of CPU and bandwith use.

This isn't rocket science, and it's not like other OS companies don't already do this. For all the complaints piled on Windows Mobile, I haven't had any memory issues with my Epix (which replaced my iPhone as my main phone). Is it perfect? No, but neither was the iPhone. And as a user, I recognize that certain programs have a bigger memory footprint and choose to actively exit them.

And what really boggles my mind is that a simple flip phone for free from AT&T can run AIM in the background. Apple is working incredibly hard to prove that square wheels work just as well as round wheels, if you don't mind all the bumping and shaking and sometimes on rough ground you won't go anywhere.

The iPhone is a neat device, but it fails miserably in certain areas for no reason other than Apple doesn't want to play well with others. It's their right, but that's what it boils down to.

I think option 1 sort of defeats the purpose of backgrounds apps. If the apps are just going to close because of inactivity, what's the point? Even the most basic apps would be almost useless. IM messages might not come in frequently, but if the app terminates, even with a warning, what's the point? You won't get your messages. Having a prompt would just force user to constantly be monitoring for these prompts, and again, if you have many apps open and running, you might be constantly answering prompts.

Option 2 might work, but then you would have everyone bitching that the requirements are too restrictive or too arbitrary. While you may not have had memory problems with WinMo, it is certainly a concern. I am of both minds with Push vs. BG apps. I see definite advantages to both and limitation to both and am not arguing in favor of one over another. Want I do want is one or the other. If it is Push, ok, I will live with that. I think it is a good solution, even it not everyone agrees there was a problem to solve. If Push is not happening, then let us know and open the OS to background, third party processes. A multi-function device that can only handle a single purpose at a time is of limited utility.

 

[kdarling]

I see lots of complaints about Apple taking developers off of Push Notifications to work on the updates of 2.2. This is just nieve to think that this happens in modern software developement. Really they have multiple small teams working on each thing in quicker iterative developement cycles. In no way would adding more developers to a project make it get released faster.

Right, adding more developers to a single section of code won't help.

But adding more developers or contractors *just* to work on background notifications, should work out just fine. In fact, you'd want to get experts on it.

Apple's certainly got the bucks. Yet they spend far less than most other tech companies on R&D, and they're known for overworking its developers.