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 at http://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 at http://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
-~----------~----~----~----~------~----~------~--~---

Reply via email to