Next alpha release of Necessitas

Wed Jul 18 10:06:42 UTC 2012

Well, this is what i consider "not proper multi-task" :)

On any architecture i have been working on (and this includes Symbian, 
MeeGo, Maemo, Linux, Windows, QNX, Bada) it's the foreground app which 
gets terminated when it start eating too many resources. Not randomly 
background apps.

Android multi-task is broken in this respect. And this is a serious 
issue for applications which must stay alive no matter what, like mine 
(a GPS tracker) where i would greatly prefer the foreground app to be 
closed rather mine, and without any notification so that maybe the user 
can restart it immediately (after proper curses to the funny 
multi-task).

Also, the "parameters" which causes the background app closure are a 
bit strange. My SGSII have a few hundreds of free RAM megabytes (some 
850 total), so why close my app (70mb) just because i am starting some 
game which requires less than 10mb? The phone do have lots of free 
resources... no need to kill my background gps tracking app... But 
Android does it anyway, also in this respect it's broken.

Android multi-task IS indeed broken. In the principles (which i do 
understand but i don't agree with), and in the implementation (with 
limits which can be edited by a power-user but are not tailored to the 
real availablwe resources).

I understand it's supposed to be a phone not a computer... but when i 
have 1GB ram and 1.2Ghz dual core cpu, well, it's a computer with a 
phone attached...

Il 18.07.2012 10:19 Alberto Panizzo ha scritto:
> Listen,
> Please, before speaking like this read the documentation of Android
> and how Android manages Threads and Processes. There is no wrong
> in killing applications which are no more important for the user
> when the device is low in memory especially since the Android's
> application model allow to manage this lifecycle path.
>
> Android is more complex than "Android DOES NOT deliver proper
> multi-task" and remember that your Qt application is hosted into a
> normal Android application.
>
> Ruben, first you should post a logcat here, obtained suddenly after
> this problem appear. (If you are able to retrieve a dmesg result it
> will be helpful as well).
>
> If you want your application to not be likely considered as 
> "killable"
> from the Android framework when it goes in background, Your Java 
> layer
> should do something even when the Activity is in Paused or Stopped
> state. This could be done with a Service which holds a Handler and
> periodically gives tasks to do to this Handler.
> But remember that this will _more likely_ keep your application 
> running
> in background. If the foreground application eats all the resources,
> your background application will be sacrificed to let the user to
> continue working with its first interest at that instant.
>
> But remember that the way Necessitas bases the execution of your app
> on an Activity, implies that you cannot be completely sure that your
> Qt background activities will be held from the execution to the 
> device
> turn off.
>
> Read out the Android's components lifecycles documentation
>
> Best regards,
> Alberto
>
>
>
> On 07/17/2012 11:12 PM, Willy Gardiol wrote:
>>
>> My experience with "background" apps on Android is that.... Android 
>> sucks.
>>
>> Basically Android will (and be sure, it will!) close any background 
>> app
>> randomly when it want. There is no clear way to predict this, it 
>> just
>> happen. This ahppen with ALL android apps, it's not a necessitas 
>> issue.
>> The only way to prevent this is to install an icon in the 
>> notification
>> area... but i have not tried this with Necessitas as i guess it 
>> would
>> require come JNI hacking.
>>
>> Anyway, i have installed a tool called Toolbox Pro which lets me 
>> tweak
>> the maximum amount of memory allowed for background apps. Increasing
>> this value clearly reduce the risks of background app closing.
>>
>> Just rememebr, Android DOES NOT deliver proper multi-task... only 
>> the
>> foreground app is guaranteed to be running at all times, any other 
>> "non
>> foregroud" is never guaranteed.
>>
>>
>>
>> Il 17.07.2012 23:03 Ruben . ha scritto:
>>> First, thanks for explaining how to test with the latest Ministro
>>> repository.
>>>
>>> Ive now tested our app for about 24 hours.
>>>
>>> The good "news": Our app has not hung on any resume as it normally 
>>> did
>>> with the standard alpha3 libs. Ive tested overnight, received and
>>> placed phone calls, started other apps etc... As long as our own 
>>> app
>>> is still showing in the task manager it has always showed up again 
>>> as
>>> it should. I noticed one time that it took some seconds before the
>>> app reacted on first touch after resume and I assume it
>>> then probably reloaded some necessary libs (as I would expect it to
>>> do).
>>>
>>> The bad "news": On two occasions so far our app was not running at
>>> all any more when I resumed the phone, gone in the task manager. I
>>> dont know if this is related directly to the resume problem (ticket
>>> #22).
>>>
>>> Is seems that the most important issue, resume a still running app, 
>>> is
>>> fixed. However, if someone else experience that the app is not 
>>> running
>>> at all when the device itself is resumed please give it a post 
>>> here.
>>> Or even better, maybe someone know how to work around/fix it :-)
>>>
>>> Ruben
>>>
>>>
>>>
>>>
>>> On Tue, Jul 17, 2012 at 10:31 PM, Ruben . <colruby2 at gmail.com [3]>
>>> wrote:
>>>
>>>> Hi,
>>>>
>>>>
>>>>
>>>> Our target release date is the end of this month, currently we
>>>> are desperately trying to put all the things together.
>>>>
>>>> Because we encounter a lot problems it may be delayed a few days
>>>> (maybe a week or two).
>>>>
>>>>
>>>>
>>>> What do you mean be "unstable version on alpha3"? There is  no
>>>> unstable version of alpha3 :)!
>>>>
>>>> If you mean Ministros unstable repository, then it means that the
>>>> problem is not solved by alpha4, because now Ministros unstable
>>>> repository contains a testing release of alpha4.
>>>>
>>>>
>>>>
>>>> To be sure you are testing it correctly make sure you are using
>>>> the last Minsitro (is not on market yet) from
>>>> here 
>>>> http://files.kde.org/necessitas/installer/MinistroActivity.apk
>>>> [1] and and then use "Ministro Configuration Tool"
>>>>
>>>> to switch to "Unstable" repository and try again the issue.
>>>>
>>>>
>>>>
>>>> Cheers,
>>>>
>>>> BogDan.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> ----- Original Message -----
>>>>
>>>>> From: Ruben
>>>>
>>>>> To: BogDan <bog_dan_ro at yahoo.com [2]>
>>>>
>>>>> Cc:
>>>>
>>>>> Sent: Monday, July 16, 2012 10:10 AM
>>>>
>>>>> Subject: RE: Next alpha release of Necessitas
>>>>
>>>>>
>>>>
>>>>> Hi BogDan.
>>>>
>>>>>
>>>>
>>>>> Any thoughts now about when the next release (alpha4) will be?
>>>>
>>>>> We are desperately waiting for a fix on ticket #22 (Problem
>>>> resuming
>>>>
>>>>> application on device)...
>>>>
>>>>>
>>>>
>>>>> Ive tried the unstable version on alpha3 but that didnt help, so 
>>>>> I
>>>>
>>>>
>>>>> assume we cant get it tested until alpha4 is released...?
>>>>
>>>>>
>>>>
>>>>>
>>>>
>>>>> Best regards, > Ruben
>>>
>>>
>>>
>>> Links:
>>> ------
>>> [1] http://files.kde.org/necessitas/installer/MinistroActivity.apk
>>> [2] mailto:bog_dan_ro at yahoo.com
>>> [3] mailto:colruby2 at gmail.com
>>

-- 
Willy Gardiol
willy at gardiol.org
www.gardiol.org
www.trackaway.org -> Track YOUR way the way you want!