On Thu, Mar 26, 2009 at 7:25 AM, Stoyan Damov <[email protected]> wrote: > > Screw the developer. I'll put myself in the shoes of the user. I have > launched myself a game. I want it to run at full speed. > I could care less that a background service, polling RSS feeds have > just found out that someone posted a new blog entry. > I'm sure you now understand there's no issue with background apps and > which is more important.
You've just put yourself deeper in a position where you see your application as the most important one. Well, in the shoes of the user, you now have an application (your game) that hurts the entire system. When your app is running, the user doesn't receive their email any more, they don't get updates from twitter, latitude doesn't work... and there will probably be lots of other cases. If we go down that path, 6 months from now we'll have requests for a permission that allows background apps to say "I don't want apps to run in the foreground that prevent background apps from running", and their request will be just as reasonable as yours: their app doesn't coexist with yours, so they want to prevent yours from running (just like you want to prevent theirs from running). > Now, I realize that this permission should not be that simple - it > should allow the apps to specify which components are OK to run > (system components will always run, of course). > For example, the RSS reader application will want to run itself, and > this or that service it depends on. I don't see how this would be a > problem. The permission should simply allow one or more components to > be listed as dependencies. It's not as simple as it seems, as you're putting a requirement on background applications to identify which components they (transitively) rely on in order to work properly. Imagine that your app relies on component A, but that (as an implementation detail) component A relies on component B: now you need component A to identify that it needs component B, so that component B can also be made immune to the "kill-by-game" behavior. I think that we've gone way too far from the original problem. The original problem as I see it isn't about GCs in other apps, it's about behaviors that cause "remote" GCs in your game. I think it'd be much simpler if your game could say "I don't want remote asynchronous GCs", and it would probably even be more effective. It might turn out to also be more acceptable design-wise, and easier to implement in the framework. Better still, since it's a same-process behavior, there's not even a need to put permissions around it, since from the point of view of the permission system an app is free to do whatever it wants in its processes. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~----------~----~----~----~------~----~------~--~---
