I see her point, it isn't scalable. What do you do when two apps both want this, and you want both apps?
No, I agree, this needs addressing but not this way. On Mar 26, 1:55 pm, Stoyan Damov <[email protected]> wrote: > I could understand if you were saying that you can't provide > multi-tasking experience on a single-tasking OS, such as Windows 3.1, > which required cooperative multitasking. > But I find it hard to understand what are the practical and technical > reasons behind your resistance to provide a single-tasking experience > on a multi-tasking OS. > > Cheers > > > > On Thu, Mar 26, 2009 at 9:50 PM, Stoyan Damov <[email protected]> wrote: > > On Thu, Mar 26, 2009 at 8:26 PM, Dianne Hackborn <[email protected]> > > wrote: > >> On Thu, Mar 26, 2009 at 10:19 AM, Stoyan Damov <[email protected]> > >> wrote: > > >>> So, ok, I *admit* other apps can't cause DIRECTLY a GC in my app, but > >>> it doesn't matter to me because other apps can cause the system to > >>> lack memory and perform GC and it would ask my app's process to do GC, > >>> which is how I understand JBQ's explanation of "remote GC". > > >>> So back to my point. I don't care what causes GC in *my* process. If > >>> it's not me I DON'T want my process to be bothered at all. > > >> There is no way at all for other processes to cause your process to GC. > >> What other processes -can- do is run some work -- any kind of work -- on a > >> thread running at the same or higher priority as yours, causing you to have > >> to share the CPU with them. GCs are irrelevant to the problem here. (But > >> they -are- relevant to writing your own code so that you don't cause GCs to > >> happen in your own process.) > > > Dianne, I haven't taken any time to dig in Android, so I don't know > > what and how works. > > All I know is that when *ANOTHER* process kicks GC, it affects MY > > process, and my game stutters at this EXACT moment. > > My game, like I said many times, *only* allocates memory on startup, > > and then uses object pools. > > I know that, when for example, the myFaves service is not trying to > > send the damn MMS my games works PERFECTLY smoothly. > > When it stutters, I see that GC has kicked in in process with PID "X", > > and that X is not my game's process' PID. > > > I hope you get it know. > > >> Currently our approach for scheduling is that apps doing background work on > >> a thread should lower that thread's priority -- the standard applications > >> on > >> Android do this. This has holes however, and allows people to mistakenly > >> do > >> background work at a higher priority, so we should more strongly enforce > >> the > >> scheduling of processes that are not running the foreground UI. > > > No, what you should do, and I mean Google behind Android, not you in > > particular, is create an user experience SIMILAR to that on the > > iPhone. > > You can have the best of BOTH worlds and provide background processing > > (i.e. as it works right now) AND on top of that implement "single > > tasking" *experience*. > > The implementation details are IRRELEVANT to all of us, users, and > > developers. > > If you don't do it, I can bet my ass that Android, as a mobile device > > OS, and especially as a smartphone OS will not last as long as people > > "predicted". > > > Cheers- Hide quoted text - > > - Show quoted text - --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
