The problem with your reasoning is that it's far from obvious that your hypothetical user will clearly understand that launching your game will prevent their other apps from running (there's plenty of evidence that users don't understand the consequences of their actions as well as developers do). Of course, you'd like them to only care about your game, but you can't assume that this will be the case for everyone (and the situation gets worse if your game is really good and they spend a long time playing it).
Please file a feature request for the no-GC feature so that we don't forget about it. >how is it possible for other apps to trigger GC in my process? The system asks every relevant process to GC at different points in time, especially when it's running low on memory. That's not its only tool - it can also flush caches or kill processes when that's appropriate. >Is Android so aggressive about launching as few processes as >possible, that it won't run my app in a new process, even if the # of >running proceses is low? As a developer, you have control over the way the components in your apps get spread into processes. If I remember correctly, you can split an app over multiple processes, and you can have components from different apps running in the same process. Even without caring about that level of control, you can still be sure that your apps' components won't run in the same process as app components from other developers, since that'd break the entire security model. Android currently does keep processes around when it has enough memory for it - there's a cost/benefit tradeoff, since an empty process takes space, but having it around saves a lot of time if it can be re-used to re-launch an application in it. JBQ On Thu, Mar 26, 2009 at 8:40 AM, Stoyan Damov <[email protected]> wrote: > > 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 > >> >> > >> > > > > -- Jean-Baptiste M. "JBQ" Queru Android Engineer, Google. Questions sent directly to me that have no reason for being private will likely get ignored or forwarded to a public forum with no further warning. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
