On Thursday, May 10, 2012 1:30:02 AM UTC+2, Dianne Hackborn wrote:
Yes well there is this meme spread by certain perhaps not unbiased
entities that having multitasking at all, I mean doing multitasking like
Android, is bad because it is intrinsically battery consuming. This is of
course
10.05.2012 12:25, Johan Appelgren написал:
Perhaps the Processes and Threads section in the Dev Guide could make
it more clear that it is up to each app to stop its background threads
Just to add some perspective:
Every Android application has a bunch of Binder threads that are created
by
On Thu, May 10, 2012 at 1:25 AM, Johan Appelgren
johan.appelg...@gmail.comwrote:
Perhaps the Processes and Threads section in the Dev Guide could make it
more clear that it is up to each app to stop its background threads and
otherwise ensure they don't do anything when they're not in the
I have a simple Android Activity with one button to start and stop a long
running Android Service (which does some simple logging). As soon as I
start the service, I close the app (Activity) and the service should then
run in the background indefinitely.
But it doesn't. At random times, the
The process gets killed and then gets recreated (typically 5 seconds later)
because of START_STICKY.
onDestroy does not get called, along with any other callbacks, the process
just goes away.
There is no duplicate instance of Service object.
This might help:
That is the expected behavior. The longer your service runs, the more
likely it is to be killed (and then restarted if you asked for it to be
sticky).
On Wed, May 9, 2012 at 3:13 AM, William Kelley williamtkel...@gmail.comwrote:
I have a simple Android Activity with one button to start and
So, if I want a long running process (logging GPS points over several
hours), I would need to use START_STICKY and then maintain some knowledge
of state between service restarts. That is, save state to disk (filename
that I am writing to, specifically). And since onDestroy is not called and
Right.
And in general everlasting services are an antipattern...
kris
On Wed, May 9, 2012 at 3:17 PM, William Kelley williamtkel...@gmail.com wrote:
So, if I want a long running process (logging GPS points over several
hours), I would need to use START_STICKY and then maintain some knowledge
Thanks.
I'm not sure why long running services are frowned upon. As long as they
don't overly consume resources and are done with the user's knowledge, and
indeed the user *wants* the features of a long running service, then what
is the harm? If a user wants to log something for a long time,
Because Android doesn't have many programs that should constantly be
consuming background memory and charging through the CPU. The use
case is things like phones, where you put it in your pocket, and you
just want it to go away. Remember that you can't do computation
continually if you don't
09.05.2012 23:17, William Kelley написал:
So, if I want a long running process (logging GPS points over several
hours), I would need to use START_STICKY and then maintain some
knowledge of state between service restarts.
If you wanted it to be invisible to, I don't know, 80% of the users
10.05.2012 0:24, Kristopher Micinski написал:
consuming background memory and charging through the CPU
Not quite the same things, are they? :)
--
Kostya Vasilyev
--
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group,
On Wed, May 9, 2012 at 6:17 PM, Kostya Vasilyev kmans...@gmail.com wrote:
10.05.2012 0:24, Kristopher Micinski написал:
consuming background memory and charging through the CPU
Not quite the same things, are they? :)
I didn't mean charging as in charging the phone, I meant charging as
in
Though I agree it's perhaps contrived, I think there are many times
when people keep persistent structures around, do processing in a
light way, etc... when their apps should just die for a while. The
typical perceived use case is when people have things that are polling
some service at regular
2012/5/10 Kristopher Micinski krismicin...@gmail.com
On Wed, May 9, 2012 at 6:17 PM, Kostya Vasilyev kmans...@gmail.com
wrote:
10.05.2012 0:24, Kristopher Micinski написал:
consuming background memory and charging through the CPU
Not quite the same things, are they? :)
I
On Wed, May 9, 2012 at 2:48 PM, Kostya Vasilyev kmans...@gmail.com wrote:
Regarding this being an anti-pattern, I'm not sure I fully agree with the
widespread opinion on higher battery consumption.
The bigger issue is RAM use. There just isn't a lot of RAM available on
many of these devices,
2012/5/10 Dianne Hackborn hack...@android.com
On Wed, May 9, 2012 at 2:48 PM, Kostya Vasilyev kmans...@gmail.comwrote:
Regarding this being an anti-pattern, I'm not sure I fully agree with the
widespread opinion on higher battery consumption.
The bigger issue is RAM use. There just isn't
if you keep a wake lock
and burn CPU time your users are going to basically hate your app.
For a change they could hate:
- battery manufacturers for not making advance in battery technology.
- WiFi chipset manufacturers for WiFi using so much battery when active (vs
mobile which uses
On Wed, May 9, 2012 at 4:02 PM, Kostya Vasilyev kmans...@gmail.com wrote:
I see your point about long running processes possibly fighting for RAM,
but restarting the process burns up the battery too (you'd previously given
a number of about 1 second to launch from Zygote to a running
19 matches
Mail list logo
