How often does an activity run?

by BobG » Mon, 19 Apr 2010 14:37:12 GMT


Sponsored Links
 If we run a simple little hello world program that just puts some text
in a textview, I see the the onCreate runs, and I guess it calls
ondraw once, then it sort of returns to the os, and if we have
registered a sensor changed or an onclick listener, we can read the
sensor and call invalidate and the os will call ondraw again, and it
all is usually 'fast enough'. But my question is: Does ondraw ever get
called again? Or is this now a 'zombie process' that will just sit
there taking up memory until we kill it?

--



How often does an activity run?

by ~ TreKing » Mon, 19 Apr 2010 21:09:20 GMT


 



Sure, whenever the view needs to be re-drawn ...



I don't know what you're asking. Activities don't really "run" like threads
that have a definite function that gets executed to do work. They have
functions that are invoked in response to system events (onCreate, onPause,
onConfigurationChanged, etc).

-------------------------------------------------------------------------------------------------
TreKing - Chicago transit tracking app for Android-powered devices
 http://sites.google.com/site/rezmobileapps/treking 

--


Sponsored Links


How often does an activity run?

by BobG » Mon, 19 Apr 2010 22:27:22 GMT


 

=====================================================
Here is my 'model' that compares an embedded program to an android
program:
embedded program: main gets called by os, main calls initstuff(),
falls into a while(1) loop that calls inputs(), process() and
outputs() forever. The os can kill it if it has to. In the android
program, the onCreate is the init, the os scheduler is the while(1)
loop, and the onSensorChanged events are like the input and process
functions, and the onDraw is like the output function. Sort of. Does
this model make sense to anyone else? Can it be explained more clearly
by another model?

--



How often does an activity run?

by Daniel Favela » Tue, 20 Apr 2010 14:05:32 GMT


 Well, this seems like a good exercise to test my learning and reading as a
newbie in the Android scene.

If I'm understanding BobG correctly, he means that the calls to onDraw
depend entirely on your application.  Your *Hello World!* sample renders the
text once and never has to render anything again -- the view stays put as
you left it.  It's a callback: when something happens (like user input),
then onDraw() might be called if something new has to be drawn.

A game, for example, might process game logic at each frame.  This results
in onDraw() being called for each frame, since game logic might place a game
object in a position different from that it was in during the last frame.

Hello World, as mentioned, doesn't need to be updated in that way.  That's
why onDraw() is not called anymore.

With regards to the "zombie" sentiment, onDraw() does not actually take up
any more memory than any other function might take; it is called when
needed, I suspect, much like onCreate(), onStart(), onResume, onDestroy() do
(these are methods involved in an activity's life cycle; check out the
Android Application fundamentals page
here< http://developer.android.com/guide/topics/fundamentals.html #lcycles>
to
see where I'm pulling these potentially wrong statements from).  From what
I've read, Android does things in a very, very, very modular manner;
everything is "there" and safe until it's needed.

I'm guessing that if you were to press "Home" or "Back" while *Hello
World!*was running, then you brought it back to the foreground, it
would call
onDraw() again.

If I'm wrong in anything I've said, please correct me!  I hope that helps.

-Danny






>



How often does an activity run?

by Indicator Veritatis » Wed, 21 Apr 2010 06:40:37 GMT


 It is most definitely not a "zombie process". A zombie process, by
definition, is one not even the shell command 'kill' can kill. The
process you just described is still able to receive events -- and will
the next time the OS decides to call onDraw.

It is Android that decides when to call onDraw(). However, you can
tell it to do so by calling postInvalidate() or invalidate() as
described in  http://developer.android.com/guide/topics/graphics/index.html 



>



Other Threads

1. Guru Meditation@ AudioTrack(51): *** SERIOUS WARNING *** obtainBuffer() timed out

Hello,

I am using MediaPlayer to play background music and SoundPool to play
sound effects. All Audio data is stored in .ogg file format.
Sometimes it happens that the MediaPlayer playback is interrupted for
a fraction of a second if SoundPool.play() is called. Whenever this
happens, the following two warnings are printed to logcat:

11-04 01:49:05.113: WARN/AudioTrack(51): obtainBuffer timed out (is
the CPU pegged?) 0x2b6e8 user=000cc520, server=000cb710
11-04 01:49:05.113: WARN/AudioTrack(51): *** SERIOUS WARNING ***
obtainBuffer() timed out but didn't need to be locked. We recovered,
but this shouldn't happen (user=000cc520, server=000cb710)

Do you have any ideas what could cause the warning messages and/or how
to avoid them? I.e. how to prevent SoundPool.play() from interrupting
MediaPlayer playback?

An other warning that's sometimes appearing is:
11-04 01:55:49.793: WARN/AudioFlinger(51): write blocked for 89 msecs
There seems to be no connection to the above messages, but do you have
any ideas what causes this message and/or how to avoid it?


Here's some more detailed background information, maybe they are
useful:
My OpenGL powered game is split into three threads: One for rendering,
one to take care about the game logic and the main thread to process
user input.
All Audio data is accessed through a central AudioManager class, which
is only used in the game logic thread. (So this does not seem like a
threading issue. Needless to say that synchronizing all methods has
not solved the problem).
The game runs smoothly at ~60 frames per second. According to DDMS the
game causes ~33% system load (~10% in kernel space and ~23% in user
space) on a G1. Even the idle task gets ~24% CPU time assigned while
the game is running and input happens through the touch screen! (So it
does not look like a performance problem)
The MediaPlayer playback interruption always happens if SoundPool.play
() is called in response of a touch screen input. Although touch
screen input and SoundPool.play() happen in different threads. I've
tried suspending the UI thread for various different delays between 8
and 32 msec after a MotionEvent has been processed, but again, without
success...

I've spent days optimizing the game and finding the cause of the
interrupted MediaPlayer playback, but without success. Now I've run
out of ideas. So any advice that could help solving the problem is
highly appreciated!

Thanks in advance,
Mike.

-- 

2. Max size of android application

What is the maximum size that android application can hold?
I have one database(.sqlite extension) file with 147 mb,
Is it possible to include that file in my app.?I tried to put it in my
asset folder but while running it showing message like  "No space left
on device".

-- 

3. Cannot start volume '/sdcard' (volume is not bound) error using vold

4. Dynamically grow listview

5. Scroll Event in Android

6. android and building automation

7. Qestion about Android Build System