5 ms·

Its definitely not RAM. Android devices with significantly less RAM handle it fine. When a Service is scheduled, it is only allowed to run while resources (bat

Its definitely not RAM. 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.

mtts 19y ago
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).
- maximilian 19y ago
  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.
allenbrunson 19y ago
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.
- davidw 19y ago
  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.
  - allenbrunson 19y ago
    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.
    - davidw 19y ago
      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.

mtts 19y ago

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).

maximilian 19y ago
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.

allenbrunson 19y ago

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.

davidw 19y ago
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.
- allenbrunson 19y ago
  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.
  - davidw 19y ago
    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.