Hacker News Reader

Comment by mortenjorck | Hacker News Reader

I'm a happy Pastebot customer and use it all the time, but I don't think I'll be using this feature. It's ingenious, but it just feels like the kind of hack I associate with less UX-focused platforms.

I'm actually kind of glad the silent version wasn't approved, though. As logically strange as having to play music while using clipboard sync is, having another music app interrupt that sync is almost worse.

I'd rather Tapbots had gone the Task Completion API route, where they can run whatever they want in the background for ten minutes (what the Colloquy IRC client uses). That kind of functionality has an intuitive, physical analog in timed light switches; one can't say as much for a light switch that requires the stereo to be playing.

Apple really needs to increase that time limit, though.

View on HN

They've said (in the comments section of their post) that this will not get interrupted by other music apps. They tested with iTunes and Pandora running.

Task completion is unreliable for background processes. It's meant for finishing something quickly before an app goes into an inactive state. The OS is likely to kill the app at any time if it's taking too long or other apps need the resources.

Unfortunately there just isn't a nice way for Pastebot to do what they want to do. It's one of those edge cases where none of the available options for multitasking are useful. They're doing the best they can, but this is still a really hacky solution and I wouldn't depend on it staying in the App Store.

I think Apple doesn’t have to be quite as restrictive. They could allow developers to do some general purpose multitasking and take steps limit its use.

They might only allow general purpose multitasking if it’s off by default and the user has to explicitly opt-in. They might add something in their settings app where you can turn turn general purpose multitasking on and off for each individual app which uses it. They might reject all apps which use general purpose multitasking when the dedicated methods would do, too. They might reject all apps which use general purpose multitasking without providing any functionality to the user. They might require all apps which use this general purpose multitasking to have some gracious failure mode if memory really gets low and the app has to be quit. (I’m not so sure about this last one. You would have to notify the user because otherwise the experience would be terrible, i.e. suddenly and without any apparent reason or warning Pastebot would stop to work. But adding a modal dialog would also lead to a terrible experience, they would have to make it more subtle which in turn can be easily overlooked. How does Android handle this?)

There's a lot of ways they could go, definitely. But they're trying to keep it as simple as they can, from the user's perspective anyway. The best feature of the three multitasking styles they allow is that I don't have to think about it, which can't be said about the Pastebot solution, nor really any of your options either.

"From the user perspective"

You don't really believe that do you? You can't honestly tell me that it's easier to explain to a user that they have to play a silent audio clip to have an application keep working when it's not visible. And you can't tell me that for <any multitasking app>, it's easier for the user to use because it can only work in the background if its a short potentially volatile task, a location or audio service. How is that 'easier' for the user?

Reply on news.ycombinator.com