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 questio
On Sun, May 1, 2011 at 8:19 AM, William Ferguson 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 Activity#finished? What
>
On Sun, May 1, 2011 at 8:15 AM, William Ferguson 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 #onStop to
> #onCreate actua
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 vers
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 just
On Thu, Apr 28, 2011 at 9:37 PM, Indicator Veritatis wrote:
> 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 indepen
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 i
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
over-simpli
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, ev
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 wrote:
> Yes
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 acti
On Apr 28, 12:21 am, Dianne Hackborn 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 used in their p
"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.
I
On Apr 27, 9:27 pm, Dianne Hackborn wrote:
> On Wed, Apr 27, 2011 at 6:56 PM, Eric 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 (when the process is
> > _not_
On Wed, Apr 27, 2011 at 6:56 PM, Eric 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 low-memory situati
Um, yes, called. I meant called. :)
On Wed, Apr 27, 2011 at 6:53 PM, Mark Murphy wrote:
> On Wed, Apr 27, 2011 at 6:44 PM, Dianne Hackborn
> 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 k
On Apr 27, 6:44 pm, Dianne Hackborn 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 was made, it makes
On Wed, Apr 27, 2011 at 6:44 PM, Dianne Hackborn 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 clarify, shouldn't th
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 r
On Wed, Apr 27, 2011 at 5:55 PM, Eric 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 is paused,
finis
On Wed, Apr 27, 2011 at 4:55 PM, Eric 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 started another
>
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
http://developer.androi
On Wed, Apr 27, 2011 at 6:04 PM, Eric 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 finish() method),
>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 ope
On Apr 27, 4:45 pm, Mark Murphy wrote:
> On Wed, Apr 27, 2011 at 4:22 PM, Eric 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 allowed to 'clean up'
your activity r
On Wed, Apr 27, 2011 at 4:53 PM, Streets Of Boston
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 chooser) and
> your ac
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
v
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 onD
On Wed, Apr 27, 2011 at 4:22 PM, Eric 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 triggers onDes
On Wed, Apr 27, 2011 at 3:22 PM, Eric 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() will get
call
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 proce
"* 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 t
32 matches
Mail list logo
