Android devices with significantly less RAM handle it fine. When a Service is scheduled, it is only allowed to run while resources (battery, CPU, memory) are sufficient to keep the critical processes (currently visible UI, current application) running. The OS has permission to kill off background Services without warning as needed to preserve the user experience.
It's not just RAM, but it's not political either. It's battery life, I should think. Remember this is a phone we're talking about and if that phone has to be recharged every six hours because some application constantly wants to poll the internet, that's really not acceptable to most users (and they won't fault the app for the poor battery life, they'll fault Apple).
I agree strongly with the battery life argument. Its an important note to make that the battery is run down because of frequent wifi/edge use. I've seen accounts of pre-sdk iphone hackers making programs that ran the battery down in hours just polling for tweets every minute or something similar. That same hacker said that ideally there would be some sort of registration for wifi/edge time that would bring up a connection every T minutes and tell all the programs registered to that listener that they now have 1 minute of access to the internet to poll whatever service they needed.
i don't think an android comparison is appropriate. different implementation languages, different philosophies, different hardware expectations, etc. for example: "The OS has permission to kill off background Services without warning as needed to preserve the user experience" -- apple would NEVER go for that. while it might be the right thing to do technically, it would badly confuse the user: "why did my app stop working?" apple just doesn't play like that.
and are there any actual android devices available that this idea could be confirmed against? last i heard, there weren't any.
Well, I don't think Android apps just get nuked from one minute to the next - they get a chance to shut down and save state.
If anything, Objective C is going to be more efficient in terms of processor cycles and memory, so that point would go to the iPhone.
I prefer Android's approach: laissez faire, and see what works out rather than attempt to foresee everything beforehand and risk killing off good apps before they even have a chance.
Thats correct, you can save your state just before a Service is killed. The onDestroy() method is always called by the OS first. And Android will automatically try to restart your Service, when resources are sufficiently available again.
I also prefer Android approach, even if theoretical performance might be lower not being native.
did you read where the sentence you're apparently replying to said "background services?" i wasn't talking about "android apps getting nuked from one minute to the next."
almost all the arguments here are on technical merits. me, gruber, and others seem unable to convince you guys that apple quite often doesn't make decisions based on technical merits, but rather on what will make a better experience for the user.
gruber, me, others, etc, certainly aren't arguing that background apps aren't possible. the argument is whether it's advisable, given the current limitations on memory, cpu, battery, apple engineering time, and backward compatibility.
one of the main things that makes windows suck so much is microsoft's slavish devotion to backward compatibility. there are things in the win32 api that got there because the 8086 didn't have memory protection, for crying out loud. apple doesn't want to commit to a public api until they know it's a good one.
"I prefer Android's approach: laissez faire ..." spoken like a hacker, rather than like a typical user of a mobile phone. apple is always going to prefer thinking about these things from the point of view of the user.
Yes, I know they're talking about background services.
> apple doesn't want to commit to a public api until they know it's a good one.
> "I prefer Android's approach: laissez faire ..." spoken like a hacker, rather than like a typical user of a mobile phone. apple is always going to prefer thinking about these things from the point of view of the user.
Well, I am a hacker, and I'm not going to apologize for it:-) I'd rather have that freedom, and see what happens. I get your point, and think it's a sensible one, but when all is said and done, I'd rather have a more open system. I think that Apple has certainly demonstrated that their approach is a good one for certain types of users, but it's not one that I prefer.
I can't believe this is actually being discussed in technical circles seriously. The limitations around the iPhone SDK are more certainly NOT technical in nature - phones (both smart and otherwise) have had background processing and multitasking for years and has never caused any problems.
Doesn't anybody remember last year's mantra of "the web is the only SDK you need"? The same people that believed that line of BS, and now spreading this updated BS.
Apple is a control-freak company and these decisions are purely political. Jobs & co only wants you to do with the phone what they like, not what YOU want, its just that simple.
Since reading this bit by Cringely last Autumn, I can't help but think of a lot of Apple's output through the prism of "being alternately seduced and tormented"; e.g. the iPhone SDK which is only supported for use by recent customers of Apple's (Intel) personal computers.
Yeah..the ram thing is a crock IMO. Wasn't THAT long ago that 128 mb was a LOT of RAM. Sure, you have to be careful,
sure you might not be able to do everything you want with fancy bells and whistles but I don't see why it should be a valid reason to preclude background apps.
Android devices with significantly less RAM handle it fine. When a Service is scheduled, it is only allowed to run while resources (battery, CPU, memory) are sufficient to keep the critical processes (currently visible UI, current application) running. The OS has permission to kill off background Services without warning as needed to preserve the user experience.
No, the reason with Apple is simply political.