Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.

skwoytek

macrumors 6502a
Feb 15, 2005
706
0
I think push will end up just being a failure for a few reasons:

I don't think it will end up a failure, but I could see it not satisfying every developer's needs. Also, I agree that notifications need to be less intrusive and they do indeed appear stone-aged.

First, I'm sure Apple has thought of most of the possible scenarios that push notifications don't cover. For those they hadn't, I'm sure some developer like the Pandora or ToDo app developers have let Apple know that push notifications don't fill their needs.

Second, I think the next logical step is for Apple to allow developers to add to the internal system notification daemon. This would cover all ToDo apps, timer apps, etc. by allowing them to set internal timed notifications through iPhone's current scheduling process without adding any additional overhead. All the push notification methods would be allowed: sounds, badges and pop-ups. Allowing a ToDo app and a timer app to actually run in the background would create three processes where the current active one (for internal calendar, timers and alarms) would suffice and reduce battery use and system resources.

A potential problem is that background apps can be closed - even accidentally. While this is technically on the user, you can never accidentally close an important notification with Apple's implementation. Say a stock trader is waiting for a limit alert on AAPL but accidentally closed their stock application last night. On the iPhone you still get your push notification limit alert - on the Pre, you don't.

Now we are left with the non-notification style applications, like Pandora. I'm guessing since Apple created the iPod, they're not too concerned about Pandora while clearly Palm would be. There's also the potential that Apple has their own streaming music solution waiting in the wings. But there are many other non-notification applications like a turn-by-turn GPS or fitness/run-tracking applications which would be pointless if you received a phone call in the middle. However, I'm sure that Apple will implement true background/multi-tasking soon. They already do with many of their applications, like the iPod app. But I think by urging developers to use the more system friendly push notification server when applicable, Apple is creating a better experience for when they do finally allow other applications to run in the background.

Finally, Apple improved many situations and ignored some. But I don't think push notification's going to fail for what it was intended to solve. The real advantage of background applications would be reducing the time to close and load and close and reload applications. In the mean time, I don't see a it killing the iPhone's market compared to Pre.
 

ArtursBoy

macrumors member
May 7, 2008
64
0
AZ
It's not going to happen with 3.0.

Apple has been talking about these push notifications and the 20% effect on battery life for a long time, they're not going to give up on it now.

Was anyone else unimpressed with a 20% loss in battery life btw? I think that's quite bad considering the small number of features that these notifications are going to offer.

Im sure they wont throw away the idea of push notifications, I didn't say they would. I was talking about something more along the lines of adding an option in the settings menu to "allow streaming audio connection to stay open", or some option similar to that. As you may already know, Safari on iPhone can already stream audio in the background (this is the workaround FlyCast currently uses to stream audio in the background). Im no developer, but it seems to me like Apple could simply offer an API on their SDK to allow such functionality for developers (such as Pandora or AOL Radio) to use on their existing apps.
 

pkoch1

macrumors 6502a
Oct 3, 2007
527
0
Boston
Absolutely. There was no context for their figures. They said nothing about how they were using the IM client either. Was it just that push was on, or were they receiving instant messages as well - if so, at what rate? Was the screen on the entire time for either background process or push?

I just want my to-do application to be able to alert me when my tasks are due. I want it to be able to update its own icon badge (which keeps track of the number of tasks that are "due soon") without me having to open the app. Push is useless for this.

[...]

I think push will end up just being a failure for a few reasons:

3) The notifications are impractical. Considering an IM client, every message interrupts your work flow. You have to either dismiss the pop up entirely or close the current app and open the IM app. Once you finish you again have to go to the home screen and open your previous app. "Ah ha, but you can turn pop-up notifications off!", you say, but then all you get is a number on your icon. You'll have to periodically close your current app to check for new notifications on the home screen. Doesn't this negate the whole purpose of push in the first place? If you have to keep opening the app, what's the benefit over not just running it in the background?

Hi.

1. They did provide context for their tests. I don't remember it exactly, but it was something like an IM per 10 seconds or something.

2. Developers could take advantage of PUSH for task applications. The network could push the reminders to you like an IM application. Pretend the developers have a bot that would IM you on a timer or something. It could totally work.

3. You can also enable sound/vibration alerts so it doesn't interrupt anything, but you still know you are getting it without going back to the home screen.
 

kdarling

macrumors P6
I don't think it will end up a failure, but I could see it not satisfying every developer's needs.

Agreed.

A potential problem is that background apps can be closed - even accidentally. While this is technically on the user, you can never accidentally close an important notification with Apple's implementation. Say a stock trader is waiting for a limit alert on AAPL but accidentally closed their stock application last night. On the iPhone you still get your push notification limit alert - on the Pre, you don't.

I betcha the Pre uses what Java midlets have ... and what Apple half ripped off... the background notification registry.

The registry has just one process that watches for incoming connections (sound familiar?). Apps can register to be started for a matching connection, and/or just notified if they're already running.

Thus you do not worry about a background app being closed, as in your scenario.

Many problems have been thought about and solved for mobile devices, long before Apple dipped their toes into the pond.

3. You can also enable sound/vibration alerts so it doesn't interrupt anything, but you still know you are getting it without going back to the home screen.

The whole goofiness is that the user is responsible for remembering what apps gave them a notice... could be a problem if notices are similar... and then go find and launch them so they can get the actual data. If we're busy, the notices are going to come and go and we're going to forget they came.

There's no excuse for not having at least a central notification list page. The current method is horrible UI design... or lack thereof.
 

pkoch1

macrumors 6502a
Oct 3, 2007
527
0
Boston
The whole goofiness is that the user is responsible for remembering what apps gave them a notice... could be a problem if notices are similar... and then go find and launch them so they can get the actual data. If we're busy, the notices are going to come and go and we're going to forget they came.

I agree that there should be better ways to go about this. And with the vibration, you are correct. Developers can customize sounds however, like the famous bleep from AIM.
 

bigmouth

macrumors 6502
Jul 24, 2008
331
0
No, would drain battery too much
Not necessarily. I haven't noticed a big difference in battery life since implementing background processes via jailbreak. The battery drain comes when people forget to quit programs that then hang in the background even when you're not using them. But simply running programs like Tuner, Fstream, WunderRadio, etc. while I check my e-mail doesn't make much of a difference. As long as you remember to kill the processes using a task manager when you're done, you should be fine.
 

matttye

macrumors 601
Mar 25, 2009
4,957
32
Lincoln, England
It says nothing about apps running in the background that don't need network data. I just want my to-do application to be able to alert me when my tasks are due. I want it to be able to update its own icon badge (which keeps track of the number of tasks that are "due soon") without me having to open the app. Push is useless for this. Does Apple really expect me to believe that a to-do app running in the background is going to cut battery life by 80%?

That would technically be possible using these notifications - if you're willing to let your TODO app use network data. It could send everything to a PHP script that uses cron to fire off a notification when the time arrives for you to do something. Of course, that is a ridiculously inefficient way to do this, but probably the only way to get around apple's silly restrictions.

At the minute I just use the calendar for TODOs. If you want your TODO entries to be separate from your actual calendar events, then just create a TODO calendar on your computer and sync.

I wish they'd just implement background tasks and an application switcher similar to the tab switcher in Safari.

If people complain about battery life as a result, I'm pretty sure Apple will cope. Other manufacturers do!
 

ArtursBoy

macrumors member
May 7, 2008
64
0
AZ
Not necessarily. I haven't noticed a big difference in battery life since implementing background processes via jailbreak. The battery drain comes when people forget to quit programs that then hang in the background even when you're not using them. But simply running programs like Tuner, Fstream, WunderRadio, etc. while I check my e-mail doesn't make much of a difference. As long as you remember to kill the processes using a task manager when you're done, you should be fine.

As much as the battery issue is emphasized as a downside of multitasking, a bigger issue for me is the overall speed of the device. I dont need the battery on my phone to last me a whole week without being plugged in, Im even good getting a whole day from a full charge, I got a home and car charger. What I can't stand is the device starting to choke up or drastically slow down.

Yes, we are smart enough to realize that the more applications we have open, the more resources the phone uses, but most people arent thinking about that constantly. When I had a blackberry, most of the time I didnt know what was open and what wasnt, I just didnt want to be constantly "managing" my apps. It was easier to take out the battery and restart it rather then going from app to app seeing if they were open or not.

Yes, a better executed and smarter UI would help, yes better hardware would most definitely help, but until then, given current hardware and OS's available, I disagree with the idea that the sole purpose of limiting background processes is to make the user experience a miserable one or because the company is too dumb to enable such a feature.

People like to point to the Pre when talking about multitasking, as if it could magically have as many apps open as one would want and have no effect on performance, or battery. Although I do like what is known about the Pre so far, it certainly is not without its shortcomings, here's an article posted on a blog site with a Sprint doc making reference to having many applications open among other things.

http://www.theiphoneblog.com/2009/0...eak-shows-iphone-users-multitasking/#comments

We all know other mobile OS's can multitask, and if you've used a BB or a WinMo device you know how it can slow things down. I for one, dont want to be "monitoring" an app manager so the phone is be able to perform at its best, I want it to do that on its own, and limiting background processes is one way of doing that until better hardware and smarter OS's change that.
 

kdarling

macrumors P6

A hilariously biased article.

They consider that rebooting or doing a full system recovery on an iPhone is more user friendly than ... a Pre user simply flicking task cards away, or clicking a clear memory button. (I wonder what they think of Apple's suggestions of clicking Reset Network etc.)

I for one, dont want to be "monitoring" an app manager so the phone is be able to perform at its best, I want it to do that on its own, and limiting background processes is one way of doing that until better hardware and smarter OS's change that.

All depends on your notion of "perform at its best". To me, that means I _expect_ to be able to pick and choose what's running.

One of the phones I have is a Samsung i760 running WM 6.1. I have a simple task manager button on the homepage. It displays just major running apps. Whenever it gets slow, I just click that button, and then click on the icons I don't need. It's so easy, it's ridiculous.

In return, I get instant context changes back to map search results from the browser, Pandora playing in the background. I suppose it's like having a standard drive auto or an automatic.
 

bigmouth

macrumors 6502
Jul 24, 2008
331
0
As much as the battery issue is emphasized as a downside of multitasking, a bigger issue for me is the overall speed of the device. I dont need the battery on my phone to last me a whole week without being plugged in, Im even good getting a whole day from a full charge, I got a home and car charger. What I can't stand is the device starting to choke up or drastically slow down.
Speed and stability are both issues I've noticed due to the iphone's limited RAM. I find that everything runs more slowly if I have a 3rd party app open in the background. A big memory hog is Safari -- I can't stream any audio if Safari stays open in the background. That's actually why I love having a task manager via jailbreak -- allows me to kill Safari the moment I quit.
All depends on your notion of "perform at its best". To me, that means I _expect_ to be able to pick and choose what's running.
I agree 100%. See my Safari example above.
 

ArtursBoy

macrumors member
May 7, 2008
64
0
AZ
A hilariously biased article.

They consider that rebooting or doing a full system recovery on an iPhone is more user friendly than ... a Pre user simply flicking task cards away, or clicking a clear memory button. (I wonder what they think of Apple's suggestions of clicking Reset Network etc.)



All depends on your notion of "perform at its best". To me, that means I _expect_ to be able to pick and choose what's running.

One of the phones I have is a Samsung i760 running WM 6.1. I have a simple task manager button on the homepage. It displays just major running apps. Whenever it gets slow, I just click that button, and then click on the icons I don't need. It's so easy, it's ridiculous.

In return, I get instant context changes back to map search results from the browser, Pandora playing in the background. I suppose it's like having a standard drive auto or an automatic.

It's a blog, hard to find a non-biased blog these days wouldn't you agree?

Regardless of what is commented on the blog about the document, it does point out to a sprint doc where a suggestion is made about how to improve the performance of the Pre should it become sluggish or as the doc itself says "If applications are running slower than normal..."

What I make that out to say is that as expected, running various apps at once does affect performance, even on the Pre.

Having a task manager on your home screen to control running apps is a great suggestion, it would certainly make it easier to find and kill apps you dont need; however, this is exactly what I don't want to be doing.

And you are right, it all depends on your notion of performing at its best. To me, that means no sluggish apps and no choking up when asked to do certain tasks. Using your own line of reasoning, in return for limiting background processes, I get a smartphone with snappy performance, extremely simple and easy to use UI, with no need to "manage" applications in order for the OS to remain snappy and/or stable.
 

ArtursBoy

macrumors member
May 7, 2008
64
0
AZ
Speed and stability are both issues I've noticed due to the iphone's limited RAM. I find that everything runs more slowly if I have a 3rd party app open in the background. A big memory hog is Safari -- I can't stream any audio if Safari stays open in the background. That's actually why I love having a task manager via jailbreak -- allows me to kill Safari the moment I quit.

I agree 100%. See my Safari example above.

Maybe it's the fact that compared to my previous BB or WinMo phones, the iPhone is by far fastest. But from what I've read, you are right, Safari on iPhone does consume alot of ram.
 

ki2594

macrumors 6502a
Apr 12, 2008
802
5
Carmel, IN.
You guys need to understand that if they do background notifications in 3.0, it has to be usable on the 3G as well as the new iPhone, and sure they can and will make the battery better on the new iPhone, but that doesn't mean that it won't destroy the battery of the 3G.

So i think making the background notifications "compatible" with previous devices would just be too hard. I do think they will do it on next years iPhone, and this iPhone coming out in June will be able to handle it.
 

bigmouth

macrumors 6502
Jul 24, 2008
331
0
But from what I've read, you are right, Safari on iPhone does consume alot of ram.
Yes, I speculate that's what was causing a lot of those browser crashes. I'm guessing that recent updates somehow improved how both Safari specifically, and the device generally, use the iphone's limited RAM. That's one hardware improvement I think is absolutely necessary for the next iphone -- more RAM.
 
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.