Yes! Having mostly lurked over this list for the last year and half, I
see this thread come-up too frequently, and this area caused me a lot
of confusion. I don't want to change the thread, but want to emphasize
that to make intelligent suggestions, one has to understand the
process. These
Dianne, just a clarification on this thread.
In the diagram of the Activity lifecyle at
http://developer.android.com/reference/android/app/Activity.html
Should the directed edge on the left hand side from #onStop to
#onCreate actually be between #onDestroy and #onCreate?
And is that behaviour
And more specifically, under what scenarios do I get each of #onPause,
#onStop and #onDestroy called.
For Activity destruction due to rotation? IN what versions.
For Activity destruction due to an explicit Activity#finished? What
versions.
Process death due to memory restriction? And for what
On Sun, May 1, 2011 at 8:15 AM, William Ferguson william.ferguson.au@
gmail.com wrote:
Dianne, just a clarification on this thread.
In the diagram of the Activity lifecyle at
http://developer.android.com/reference/android/app/Activity.html
Should the directed edge on the left hand side from
On Sun, May 1, 2011 at 8:19 AM, William Ferguson william.ferguson.au@
gmail.com wrote:
And more specifically, under what scenarios do I get each of #onPause,
#onStop and #onDestroy called.
For Activity destruction due to rotation? IN what versions.
For Activity destruction due to an explicit
Eric is not the first to observe that the documentation on these
topics is too confusing. But where should he make this 'contribution'
you suggest? Is the documentation somewhere under the Android Open
Source project at http://source.android.com/?
On Apr 27, 10:23 pm, Dianne Hackborn
Eric is not over-thinking. Rather, he is showing a mindset towards
software quality that has become all too rare these days. That mindset
is: if the documentation says one thing, but the software does
another, then it is a bug.
Now I know that in today's FOSS atmosphere, that sounds quaint, even
All of the documentation comes from the source code. The documentation in
the Activity class comes from Activity.java in the source code.
I don't need a lecture about the importance of documentation and the history
of Java fragmentation. I am well aware of these things. You are also
Actually, I think you do need the 'lecture' because you got the facts
wrong. Multiple independent groups were developing JVMs, too. Remember
IBM? Sun, Microsoft, IBM and BEA all developed their own JVMs. Yet
their multiple independence did not have the same effect on the JVM
that you attribute to
On Thu, Apr 28, 2011 at 9:37 PM, Indicator Veritatis mej1...@yahoo.comwrote:
Actually, I think you do need the 'lecture' because you got the facts
wrong. Multiple independent groups were developing JVMs, too. Remember
IBM? Sun, Microsoft, IBM and BEA all developed their own JVMs. Yet
their
* onDestroy() is not guaranteed to be called, so if you create a
Thread in onCreate(), the thread may never be stopped. *
When the process hosting your activity is killed, the onDestroy won't be
called... makes sense.. your process just died. The process is force-killed
(I think): any thread
I would tend to disagree with the above two explanations. Let's say
you implement onStop() to stop/kill the thread you created in
onStart(). You then navigate to a new activity by starting it. Your
activity gets paused. Android can 'finish' your activity at this
point, WITHOUT killing the
On Wed, Apr 27, 2011 at 3:22 PM, Eric e...@alum.mit.edu wrote:
Let's say you implement onStop() to stop/kill the thread you created
in onStart(). You then navigate to a new activity by starting it.
Your activity gets paused.
It will also get stopped, as it's no longer visible, and onStop()
On Wed, Apr 27, 2011 at 4:22 PM, Eric e...@alum.mit.edu wrote:
You then navigate to a new activity by starting it.
Which triggers onPause() and onStop() on the original activity.
Your
activity gets paused. Android can 'finish' your activity at this
point, WITHOUT killing the process.
Which
The text and the diagram of the link you showed are indeed not saying the
same:
- The diagram only shows a direct path out of onPause or onStop only when
the process is being killed.
- The text says that the framework can just call 'finish' on the activity
(without going through
Be very careful with cleaning up some resources in onPause. A dialog being
shown could put your activity into paused-state, but not into stopped-state.
This happens when a system dialog pops up (e.g. an activity chooser) and
your activity is still visible in the background (blurred, but still
On Wed, Apr 27, 2011 at 4:53 PM, Streets Of Boston
flyingdutc...@gmail.com wrote:
Be very careful with cleaning up some resources in onPause. A dialog being
shown could put your activity into paused-state, but not into stopped-state.
This happens when a system dialog pops up (e.g. an activity
On Apr 27, 4:45 pm, Mark Murphy mmur...@commonsware.com wrote:
On Wed, Apr 27, 2011 at 4:22 PM, Eric e...@alum.mit.edu wrote:
You then navigate to a new activity by starting it.
Which triggers onPause() and onStop() on the original activity.
This is where I disagree with you. Android is
From the Activity documentation:
http://developer.android.com/guide/topics/fundamentals/activities.html
If an activity is **paused or stopped**, the system can drop it from
memory either by asking it to finish (calling its finish() method), or
simply killing its process. When the activity is
On Wed, Apr 27, 2011 at 6:04 PM, Eric e...@alum.mit.edu wrote:
From the Activity documentation:
http://developer.android.com/guide/topics/fundamentals/activities.html
If an activity is **paused or stopped**, the system can drop it from
memory either by asking it to finish (calling its
The text of the documentation says you're right. A call to 'finish()' is all
that could happen to 'destroy' the activity. No killing of the process is
necessary.
However, the image in the documentation (
http://developer.android.com/images/activity_lifecycle.png inside
On Wed, Apr 27, 2011 at 4:55 PM, Eric e...@alum.mit.edu wrote:
It means the activity can be destroyed after onPause() by the system
calling 'finish()' on it.
calling finish() will result in onStop() - onDestory() when in the paused
stated.
It seems to me, in that specific case, if you've
On Wed, Apr 27, 2011 at 5:55 PM, Eric e...@alum.mit.edu wrote:
Android is allowed to 'clean up'
your activity right after onPause(), without killing the app, if it
wants to reclaim memory.
By finishing the activity, thereby triggering the
onPause()/onStop()/onDestroy() triad. If the activity
Hopefully I can clearly confirm what is actually happening. There are only
two ways your entire activity instance can go away:
1. At some point the activity lifecycle completing and onDestroy() being
called.
2. The process being killed.
Thus you will not have a resource leak if you release the
On Wed, Apr 27, 2011 at 6:44 PM, Dianne Hackborn hack...@android.com wrote:
Also it may be worth mentioning -- there was a significant change to the
activity lifecycle in 3.0 where onStop() is now guaranteed to be killed
(prior to killing a process) like onPause() has always been.
Just to
On Apr 27, 6:44 pm, Dianne Hackborn hack...@android.com wrote:
Also it may be worth mentioning -- there was a significant change to the
activity lifecycle in 3.0 where onStop() is now guaranteed to be killed
(prior to killing a process) like onPause() has always been.
I am glad this change
Um, yes, called. I meant called. :)
On Wed, Apr 27, 2011 at 6:53 PM, Mark Murphy mmur...@commonsware.comwrote:
On Wed, Apr 27, 2011 at 6:44 PM, Dianne Hackborn hack...@android.com
wrote:
Also it may be worth mentioning -- there was a significant change to the
activity lifecycle in 3.0
On Wed, Apr 27, 2011 at 6:56 PM, Eric e...@alum.mit.edu wrote:
I am glad this change was made, it makes more logical sense to me to
do it this way. Hopefully the documentation can also be updated to
remove any doubt whatsoever that an Activity cannot possibly be
'removed' from memory in
On Apr 27, 9:27 pm, Dianne Hackborn hack...@android.com wrote:
On Wed, Apr 27, 2011 at 6:56 PM, Eric e...@alum.mit.edu wrote:
Hopefully the documentation can also be updated to
remove any doubt whatsoever that an Activity cannot possibly be
'removed' from memory in low-memory situations
Asking it to finish means finishing the activity, which means destroying
it. Politely asking it to finish isn't going to cause it to just not
cleanly exit. It would be fundamentally broken if activities every just
stop being used in their process without actually going through the
lifecycle.
In
On Apr 28, 12:21 am, Dianne Hackborn hack...@android.com wrote:
Asking it to finish means finishing the activity, which means destroying
it. Politely asking it to finish isn't going to cause it to just not
cleanly exit. It would be fundamentally broken if activities every just
stop being
Yes if you call finish() you are saying you want to completely remove the
activity from the stack. The system can have the activity destroyed in the
same way, but just not remove it from the stack it maintains.
At the end of the day, it would be fundamentally broken if there was a way
for an
32 matches
Mail list logo
