3 ms·

i don't think an android comparison is appropriate. different implementation languages, different philosophies, different hardware expectations, etc. for exam

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

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