Only if you have a rooted G1.
On Mar 9, 8:30 am, Muthu Ramadoss <[email protected]> wrote: > In the short time i've been using G1, there were some instances where a task > manager could have come handy. Is there a Task Manager on the Android > Market? > > take care, > Muthu Ramadoss. > > http://linkedin.com/in/tellibitz+91-9840348914http://androidrocks.in- Android > Consulting. > > On Mon, Mar 9, 2009 at 5:29 PM, Al Sutton <[email protected]> wrote: > > > Lack of protection from badly written apps is a part of life on Android > > or any open platform (look at the fun Locale caused a while ago). > > > I'm sure that the "Force close" dialogue could be popped up if onPause > > doesn't return after a few seconds or returns with threads left active > > in the process (apart from the UI one). > > > That should name and shame bad apps and give us a way of making things > > work. > > > Al. > > > Stoyan Damov wrote: > > > The only issue with this is the following: > > > > The OS can't just pause all threads the app has spawned because some > > > might be holding locks, others might be scrolling a database cursor, > > > writing to files, buying/selling stuff on the net, etc., etc. > > > So the OS can pause an app only after the app's onPause has returned. > > > This has 2 issues: > > > 1) malicious or buggy apps can refuse/fail to return from onPause, so > > > the OS should have some kind of a timeout and kill such apps (it > > > already has the dreaded force close/wait dialog) > > > 2) even if they return, this doesn't mean that they don't have threads > > > running in the background doing something potentially risky to kill > > > My experience is that only like 1% of all devs I know, who use threads > > > in their apps (in C++, C# and Java, i.e. language doesn't matter), > > > know how to write properly multithreaded apps, and can't implement the > > > simpliest of all operations like ensuring a thread has started or > > > stopping a thread gracefully. > > > > Surely Google can think about this and come up with something very > > > intriguing and innovative because I have this 1 little head, we on the > > > thread have these ~10 heads, and they have thousands of big ones ;) > > > > Cheers > > > > On Mon, Mar 9, 2009 at 1:33 PM, Al Sutton <[email protected]> wrote: > > > >> I would suggest the user pressing the Home button pauses the app until > > >> the user tries to access it again. Then the existing task management > > >> infrastructure could kill it off if necessary. > > > >> I can see the main benefit of this permission being for highly > > >> interactive apps that probably don't want to keep thrashing away if the > > >> user isn't looking at their output. > > > >> Al. > > > >> Jondice wrote: > > > >>> Perhaps creating a new permission for running apps at a "high > > >>> priority" (possibly a linux real-time priority level?) would be > > >>> useful, especially for games. > > > >>> I also agree, users should be able to kill an app if they so desire; > > >>> the alternative which many, including myself use, is to restart the > > >>> phone, which is just ridiculous. Admittedly, it seems as though I > > >>> haven't had to do this as much lately; I guess more developers are > > >>> getting better at implementing proper lifetime procedures in their > > >>> apps. > > > >>> On Mar 9, 7:20 am, Al Sutton <[email protected]> wrote: > > > >>>> That's why it would be a permission the user has to agree to on > > install. > > > >>>> To me it seems like a good idea for any platform that wants to high > > >>>> quality games to allow those games to use all the resources whilst > > >>>> they're in-play. After all, it's the norm on games consoles, and with > > >>>> the limited hardware in the G1 (as compared with a PS3 :)) it would > > make > > >>>> a lot of sense. > > > >>>> Al. > > > >>>> Incognito wrote: > > > >>>>> So the other one never starts? Won't this leave to unexpected > > behavior? I.e One app will block all others and not let them do their job > > without the user noticing. I.e he may not realize that he is no longer > > getting twitter messages because one app is blocking. > > > >>>>> On Mar 9, 2009, at 7:08 AM, Stoyan Damov <[email protected]> > > wrote: > > > >>>>> It is apparent which app is on top (in the foreground) - the last > > >>>>> launched one, isn't it? > > > >>>>> On Mon, Mar 9, 2009 at 1:02 PM, Incognito <[email protected]> > > wrote: > > > >>>>> What happens if two apps are asking for the same permision? > > > >>>>> On Mar 9, 2009, at 6:53 AM, Stoyan Damov <[email protected]> > > wrote: > > > >>>>> One can have the best of both worlds provided that the OS maker is > > >>>>> interested in providing this - for example, an app can request a > > >>>>> RUN_ALONE permission (or whatever) and the OS can do the rest - that > > >>>>> is, providing a single tasking experience on a multitasking OS should > > >>>>> not be that hard. > > > >>>>> On Mon, Mar 9, 2009 at 12:42 PM, Tote <[email protected]> wrote: > > > >>>>> On the other hand, it severely limits your opportunities on what you > > >>>>> can do on a platform, too. > > > >>>>> On Mar 9, 1:18 am, Stoyan Damov <[email protected]> wrote: > > >>>>> On Sat, Mar 7, 2009 at 3:19 PM, Mark Murphy <[email protected]> > > wrote: > > > >>>>> Background processing, in all its forms, is a double-edged sword. A > > >>>>> frequent complaint lodged against iPhone is that it does not allow > > >>>>> background processing. > > > >>>>> I consider this particular iPhone's feature one of the best features > > >>>>> on any smartphone - Apple have a very good reason to not allow 2 apps > > >>>>> to run in parallel - 1 app can and will hinder the performance of the > > >>>>> other app, and as is the case with games on Android, it's quite an > > >>>>> unpleasant surprise to bust your ass to get your game drawing @ ~60 > > >>>>> fps when virtual nothing else is running, and then have it draw at a > > >>>>> randomly lower rate just because another app/s is/are running as > > well. > > > >>>>> Cheers > > > >>>> -- > > > >>>> * Written an Android App? - List it athttp://andappstore.com/* > > > >>>> ====== > > >>>> Funky Android Limited is registered in England & Wales with the > > >>>> company number 6741909. The registered head office is Kemp House, > > >>>> 152-160 City Road, London, EC1V 2NX, UK. > > > >>>> The views expressed in this email are those of the author and not > > >>>> necessarily those of Funky Android Limited, it's associates, or it's > > >>>> subsidiaries. > > > >> -- > > > >> * Written an Android App? - List it athttp://andappstore.com/* > > > >> ====== > > >> Funky Android Limited is registered in England & Wales with the > > >> company number 6741909. The registered head office is Kemp House, > > >> 152-160 City Road, London, EC1V 2NX, UK. > > > >> The views expressed in this email are those of the author and not > > >> necessarily those of Funky Android Limited, it's associates, or it's > > >> subsidiaries. > > > -- > > > * Written an Android App? - List it athttp://andappstore.com/* > > > ====== > > Funky Android Limited is registered in England & Wales with the > > company number 6741909. The registered head office is Kemp House, > > 152-160 City Road, London, EC1V 2NX, UK. > > > The views expressed in this email are those of the author and not > > necessarily those of Funky Android Limited, it's associates, or it's > > subsidiaries. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Android Discuss" 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-discuss?hl=en -~----------~----~----~----~------~----~------~--~---
