4 ms·

It seems like disrupting the user is the exact opposite of what Apple was trying to achieve with background support. The right way to do backgrounding: - Cons

by ant5 16y ago

It seems like disrupting the user is the exact opposite of what Apple was trying to achieve with background support. The right way to do backgrounding: - Consume the least amount of CPU possible. Optimize, optimize, optimize! If you're implementing a network app and there are no events coming in over the network, your process should be doing nothing, blocked in the kernel. - Drop as much RAM as possible before you go under. There's only so much RAM on the device. Apple's frameworks try to drop as much as they can, but if you're holding onto a cache or anything that can reasonably be reconstructed, now is the time to drop it. This increases the likelihood of you surviving in the background after your process has been put to sleep, too. - Work seamlessly. If iOS terminates your app due to low resources, re-start exactly where you were before. Don't show an annoying dialog like this one when you switch to the background. Don't show a ridiculous "splash" screen that wastes user's time. Just work. If done right, you can maintain a very small footprint, and then you don't need to annoy the user by asking every time: "is this OK?".

vito 16y ago
Agreed. Don't remind the user that your app is going to use an OS feature that's meant to be pretty transparent. Especially if yours is the only app that nags them about it; it'll just confuse non-geeks and make them think you're doing something weird.
thought_alarm 16y ago
That was my initial reaction, too. But for an app like Trapster it might not be a bad idea. (I haven't used it, but I guess it's an app for tracking speed traps) Most apps do nothing in the background. Others, like music or GPS apps, it should be obvious to the user that these apps are doing stuff in the background. For an app like Trapster, however, it would be easy for the user to forget or not understand that it's working in the background. I, as a user, might appreciate this kind of warning from an app that I normally would not want running in the background. By default, I would have it not do anything in the background (which is how it obviously works on OS 3). I would have a setting that enables it to run in the background, as well as a setting that enables the warning. It sounds like that's exactly what they're doing, although I don't know what their default behavior is.
- fortybillion 16y ago
  If the app is using the background GPS process, there's already an indicator in the title bar (the little purple arrow) showing that the GPS is being used.

by ant5 16y ago

vito 16y ago

Agreed. Don't remind the user that your app is going to use an OS feature that's meant to be pretty transparent. Especially if yours is the only app that nags them about it; it'll just confuse non-geeks and make them think you're doing something weird.

thought_alarm 16y ago

That was my initial reaction, too. But for an app like Trapster it might not be a bad idea. (I haven't used it, but I guess it's an app for tracking speed traps) Most apps do nothing in the background. Others, like music or GPS apps, it should be obvious to the user that these apps are doing stuff in the background. For an app like Trapster, however, it would be easy for the user to forget or not understand that it's working in the background. I, as a user, might appreciate this kind of warning from an app that I normally would not want running in the background. By default, I would have it not do anything in the background (which is how it obviously works on OS 3). I would have a setting that enables it to run in the background, as well as a setting that enables the warning. It sounds like that's exactly what they're doing, although I don't know what their default behavior is.

fortybillion 16y ago
If the app is using the background GPS process, there's already an indicator in the title bar (the little purple arrow) showing that the GPS is being used.