On Thu, Mar 26, 2009 at 5:24 PM, Jean-Baptiste Queru <[email protected]> wrote: > > 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.
You have clearly misunderstood what I said. I said I'll put myself in the shoes of the user. By "I have launched myself a game." I meant, that I am the user, and want to launch a game, and so I do. That is, I am the user, I want to launch a game, and I don't give a ... what other apps are running in the background. I don't want to see what others are twitting, I don't care what e-mails I might have received, and I don't give a .... about nothing. I am in the loo for 10 minutes, and I'm launching a game, I want to play the game, and I don't care about anything. It's my 10 private minutes in the loo, and I could care less of *anything* else. I don't care how much the system is hurt, I want ot play for crying out loud, and I want to play at full speed with the best quality possible. Do you now understand what I said? > 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). You are only strengthening my opinion that you have completely misunderstood what I said. It is all for the benefit of the USER, THE USER, not the developer, not the OS, not Google. If the user wants these services to run, he won't be playing the game, and hey, you could do an *even better* job *denying* the application this restriction, and running it as usual. Or give the user the ability to turn on and off this permission to any application at any time while the app is not running!!! Are you thinking that the iPhone is a failure because it doesn't allow background processing? > >> 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. Actually I don't need to specify anything. I just proposed that. I now realize you can do it automatically. The second an app marked with the special permission binds to a service or accesses a content provider, it is more than obvious that the service, is indeed needed by the application and should be allowed to run. > > 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. I absolutely agree. This is another, different, but unarguably BETTER solution to the problem. Do it!!! :) > 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. Great! Do it!!! :) Cheers > > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
