3 ms·
That's simply not the case. My analogy is exactly how I wanted it. What things do you want to do with a service? Run a background thread to completion? You
by loewenskind 16y ago
That's simply not the case. My analogy is exactly how I wanted it. What things do you want to do with a service? Run a background thread to completion? You can do that. You want to play music when your app is in the foreground? Covered. Want to receive notifications from the network? Check. What to do certain tasks at scheduled times? Affirmative.
Further, if I'm reading your code I don't have to go "Oh God, they started a thread. What do they think they need it for...", I can just look at what API you used and I know exactly what the goal was. Exactly the same advantage that map/filter/reduce/etc. have over a for loop.
- vetinari 16y agoSorry, but your argument just supports mine. It is basically: what do you want? This or that supplied function covers your need, you can pass it. Sorry, you can't make yours, what would you possibly want? Honestly? I don't know right now. Maybe I will have earth-shattering idea next week or month, but I don't know right now. The point is, the original authors of map didn't try to envision what you are going to use map for, and provide enum for choosing an appropriate action. They allowed you to pass any function you want, doing whatever you want. For example, when speaking about Android, the framework contains class that handles things like managing threads for you. You just plug-in the required functionality, just like you pass your function to built-in map. The boilerplate that you are arguing against is simply not there. Just like with map you know, that "this function will be applied for every item in set" or with filter you know "you will get new set containing items from original set for which the supplied predicate is true", you know that "this functionality will run in background". The accidental complexity of managing it is hidden; the functionality allowed is not fixed.
- loewenskind 16y agoNo, I don't think you understand my argument. >This or that supplied function covers your need, you can pass it. Sorry, you can't make yours, what would you possibly want? We've had concurrency and services for decades, we already know every general action you can possibly do with a service. No one is going to come up with some totally new novel use for a background service anymore than anyone will come up with a new general action to apply to lists. Everything you would ever want to do with a background service can be divided into about 5 kinds of tasks and those are covered. Full stop. If you disagree then please describe some act with a service and I'll explain to you how that already fits in one of the 4 or 5 kinds of things people do with services. Proposing that some day, some where someone may come up with something that doesn't fit this mold is just hand waving.
- orangecat 16y agoEverything you would ever want to do with a background service can be divided into about 5 kinds of tasks and those are covered. AFAIK it's not possible to simply keep an SSH or IM connection open when you switch to another app.
- loewenskind 16y agoYou can have your app continue to run for up to 10 minutes after it's been closed, so it should be possible to use that time to keep your connection open. If no one has contacted you in 10 minutes then chances are they wont in the next 10 either so it would be better to switch to push notification and let the phone manage notifications. Keeping SSH or IM connections open is an action of a well known use for servers; listening for updates. And that's covered in the API.