Raffaele,
What information do you have, on the NPE? Is it just user reports?
Something in them makes you certain that the problem is in the
listener?
G. Blake Meike
Marakana
The second edition of Programming Android is now on-line:
http://shop.oreilly.com/product/0636920023005.do
--
You re
Veritatis,
yes, it is working fine :-)
in fact, the only thing i changed was to include (override) the
onBackPressed() method as it was posted.
goBack() also remains as it was posted, calling finish() at the end,
after calling setResult(RESULT_OK, rit).
methods onPause, onStop, on destroy are n
Test thoroughly before you say "it works". I have to say this because
1) the solution you describe still has a bad feel to it and 2) you
TALK about "calling finish()", but you don't show it in this latest
post. Are you calling it from goBack()? As the last thing it does?
On Aug 13, 8:21 pm, "hecto
thank you guys,
finally it works by overriding the back button, calling goBack() and
also calling finish().
@Override
public void onBackPressed() {
goBack();
//return;
}//onBackPressed
hector
On Aug 13, 12:00 pm, TreKing wrote:
> On Sat,
On Sat, Aug 13, 2011 at 11:22 AM, hectordu...@yahoo.com <
hectordu...@yahoo.com> wrote:
> i am trying to also do it form onPause(), onStop() , onDestroy . :-
Well there's your problem.
I don't know what will actually happen with you doing this, but that seems
wrong. Those methods are alread
i callled goBack() with sucess from a button:
mButton_thisSpinValue.setOnLongClickListener(new
View.OnLongClickListener() {
public boolean onLongClick(View v) {
Toast.makeText(HDART10Activity.this, "GO BACK
...",
Toast.LENGTH_SHORT).show();
On Fri, Aug 12, 2011 at 5:36 PM, hectordu...@yahoo.com <
hectordu...@yahoo.com> wrote:
> i wonder if somebody has an idea to deal with this issue; i tried to catch
> the RESULT_CANCELED but nothing happens, the activity 1 is as follows:
>
How and where are you calling your "goBack()" method?
---
1- i saw an example using super.onActivityResult()
using it after the "if" didnt make any difference!
2-the process code is for RESULT_OK:
yellowRoullete = (Roullete)
rit.getParcelableExtra("updatedYellowRoullete");
blueRoullete = (Roullete)
rit.getParcelableExtra("updatedBlu
Two questions: 1) why do you call super.onActivityResult()? The
ApiDemo examples do not. If you must call it, you should call if after
your own processing, since you want to catch the CANCELED first 2)
what code DO you have for handling other result codes? You should have
a default case at least so
thank you guys for comments,
i wonder if somebody has an idea to deal with this issue; i tried to
catch the RESULT_CANCELED but nothing happens,
the activity 1 is as follows:
public void onActivityResult(int requestCode, int resultCode, Intent
rit) {
super.onActivityResult(requestCode, re
On Fri, Aug 12, 2011 at 3:17 PM, Kostya Vasilyev wrote:
> Try calling setResult from onPause - I believe onStop is too late, due
> to how Start/Stop/Pause/Resume are intermingled.
Last I checked, even onPause() is too late.
Hector:
The idea is that you call setResult() when the user makes a cho
On Fri, Aug 12, 2011 at 2:12 PM, hectordu...@yahoo.com <
hectordu...@yahoo.com> wrote:
> so, if the user press back, the method setResult(RESULT_OK, rit), called
> from onStop() ... does not work?
>
Yes it does. More than likely you are handling onActivityResult incorrectly.
Are you specifically
Try calling setResult from onPause - I believe onStop is too late, due
to how Start/Stop/Pause/Resume are intermingled.
2011/8/12 hectordu...@yahoo.com :
> :-(
>
> so, if the user press back, the method setResult(RESULT_OK, rit),
> called from onStop() ... does not work?
>
> On Aug 12, 12:35 pm, M
:-(
so, if the user press back, the method setResult(RESULT_OK, rit),
called from onStop() ... does not work?
On Aug 12, 12:35 pm, Mark Murphy wrote:
> On Fri, Aug 12, 2011 at 1:16 PM, hectordu...@yahoo.com
>
> wrote:
> > "have Activity 1 use
> > startActivityForResult() to start up Activity 2,
On Fri, Aug 12, 2011 at 1:16 PM, hectordu...@yahoo.com
wrote:
> "have Activity 1 use
> startActivityForResult() to start up Activity 2, with Activity 2
> sending the result back via setResult(), followed by finish(). "
>
> ok, thats exactly what the activities do; but the result back doesnt
> work
"have Activity 1 use
startActivityForResult() to start up Activity 2, with Activity 2
sending the result back via setResult(), followed by finish(). "
ok, thats exactly what the activities do; but the result back doesnt
work when the hardware keyboarb (back) is used.
What actvity 2 does is:
If you've noticed, cleaning stuff up let's say clearing a bitmap or
nulling an image before you call another activity will result in a
temporary blanking out. So onDestroy has to happen after the next
activity is fully drawn. If you use 14mb in Activity A and 14mb in
Activity B on a 16mb heap devic
If I remember correctly you can use onPause() on activity B that will block
before any callback occurs on activity A.
Beware though, not to do any long running operation in onPause() as it would
stall the app.
--
You received this message because you are subscribed to the Google
Groups "Androi
This seems to be the order.
B.onPause() -> A.onStart() -> A.onResume() ->B.onStop() -
>B.onDestroy().
which makes sense!
On May 12, 10:43 am, Vikram wrote:
> I have two activities A and B. A is in the stopped mode and B is
> running. When I invoke finish() on B, A.onStart() and A.onResume() are
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
On Apr 4, 10:29 am, Gino wrote:
> In my tests, it looks like onSavedInstanceState() does not get called
> when switching from portrait to landscape mode, or vice versa.
There is no 'onSavedInstanceState' method in Activity.
Is that a typo in your question, or a typo in your code?
Did you mean 'o
On Mon, Apr 4, 2011 at 9:29 AM, Gino wrote:
> In my tests, it looks like onSavedInstanceState() does not get called when
> switching from portrait to landscape mode, or vice versa.
>
Do you have any flags set to lock the orientation? Rotating the device
always causes a destroy -> recreate under
In my tests, it looks like onSavedInstanceState() does not get called
when switching from portrait to landscape mode, or vice versa.
It does get called if you press the Home button.
This is on an Android 2.1 device, but it most likely applies to 1.6
and afterwards as well.
Does anyone know an ea
On Sat, Apr 2, 2011 at 12:28 PM, b_t wrote:
> And is there any way to force stop activity A to test if
> my onRestoreInstanceState and onSavedInstanceState implementation
> works
> when returning from B?
Sure. Rotate the screen. By default, that will destroy and recreate
the activity.
> In my de
And is there any way to force stop activity A to test if
my onRestoreInstanceState and onSavedInstanceState implementation
works
when returning from B?
In my device A is never destroyed.
--
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To p
The best way I have found to handle this is: be ready to be killed
_in_any_moment_. This may seem unlike to happed, but still you must be
ready. How? By saving your state when your onSavedInstanceState() is
called, gracefully releasing resources when onDestroy() is called, and
restoring the state w
The only 'correction' needed, Roger, is that "backing out" is the
wrong term. When Activity A 'calls' Activity B (really, sending an
Intent), no "backing out" takes place. "Backing out" is a much more
appropriate term for what happens when the user presses the Back key,
which causes finish() to be
On Mon, Mar 14, 2011 at 3:25 PM, Indicator Veritatis wrote:
> But (and you knew there was a 'but' coming), even this leaves
> important questions unanswered. In particular, what does it mean to
> "have input focus over any other activities"? You imply elsewhere that
> it does NOT mean unconditiona
On Mon, Mar 21, 2011 at 10:59 PM, DulcetTone wrote:
> My app responds to speech commands.
>
> I want the behavior to be that
>
> 1. if back is hit on my initial activity, it exits.
That is normal behavior.
> 2. My app has a few sub-activities it may launch on user speech- or
> GUI input
> 3.
yes all things you specified could be done
write overwrite back button code for 1
2 not clear
3 ok write overwrite onstop ,onpause,on resume
On Mar 22, 7:59 am, DulcetTone wrote:
> My app responds to speech commands.
>
> I want the behavior to be that
>
> 1. if back is hit on my initial activity
My app responds to speech commands.
I want the behavior to be that
1. if back is hit on my initial activity, it exits.
2. My app has a few sub-activities it may launch on user speech- or
GUI input
3. if home is hit on ANY of my activities, I want all of them to
finish.
That's basically it.
Wh
No because I don't believe onDestroy would necessarily get called
backing out of the activity. Only onPause would be guaranteed to be
called. That activity's onDestrw would only get called at some random
point in the future when the OS wants more memory.
OnPause is the primary. At least that is my
If one activity calls another, and when you then press "Back" from that
activity, wouldn't the calling of onDestroy() assure you that the called
activity is truly gone and the memory is freed? (Or conversely, if it isn't
called, the activity may live on due to dangling references?)
--
You rece
that's beautiful, Diane! The matched-pair thing exactly what I was
wanting to confirm - logcat messages are making a little more sense.
Here's a summary as I understand it pulled from your interleaved
response - let me know if I'm missing something.
Matching pairs of events for an activity
Any r
Thanks, Dianne, for this very valuable supplement to the mysterious
documentation on the Activity lifecycle!
But (and you knew there was a 'but' coming), even this leaves
important questions unanswered. In particular, what does it mean to
"have input focus over any other activities"? You imply els
13.03.2011 10:29, Indicator Veritatis пишет:
> > I want to perform certain actions when the BACK or HOME keys are
> > pressed, and ignore cases where a third-party activity simply pops up
> > on part of the screen and then goes away.
>
> If you find yourself needing this, perhaps you need
2011/3/12 Indicator Veritatis
> Actually, comparing with the text, I don't think it means "just what
> is says". There is an asymmetry in the states, an asymmetry I believe
> is deliberate, if poorly explained: that between onPause and onResume:
> when you enter onPause, you may still be partiall
As you say, onPause() and onResume() are by far the most commonly called.
But if you run your app on a G1, and run it with other apps, you will see
onStop() and onDestroy() called. You should also see onDestroy() called
whenever the user presses the Back button, which calls finish(); but when
f
Interesting summary, but I don't think it addresses ALL the OP's
legitimate concerns, hence my own questions/comments below:
On Mar 12, 1:49 pm, Kostya Vasilyev wrote:
> See below:
>
> 12.03.2011 23:55, DulcetTone пишет:
>
> > 1. The phrasing on the legs into and out of onPause() are vague.
> >
I recently wrote my first android app, and I too did not grasp the
life cycle functions and they just didn't seem to work correctly, or
the way I thought they should based on the graph. Here's my learned
knowledge from writing my app.
OnPause and onResume turned out to be by far and above the only
On Jun 18, 1:18 pm, Jay wrote:
> In the emulator, the
> calling activity is paused, and right after the new activity is
> resumed, the calling activity is destroyed.
More than likely the emulator is simply running out of memory, so it's
destroying the first activity to make room. There's probably
So I have modified my thread to be a singleton and mimplemented it
like this. Hope it helps someone else who might be facing the same
issue.
public class SingletonThread extends Thread{
private static SingletonThread _instance;
public static boolean IS_RUNNING = false;
priv
Note again that though this bug makes this issue happen much more
frequently, it CAN happen in normal situations. I am sorry for the trouble
this has caused, however as a rule it is correct to design your code without
the assumption that onDestroy() will happen before onCreate().
On Thu, Mar 11,
This issue has been causing serious problems for users of my audiobook
player application on 2.1 phones. The problems with the activity life
cycle cause corresponding problems with the service life cycle.
A service allows onStart to be called multiple times for the same
service instance. This is
On Thu, Mar 11, 2010 at 1:59 PM, Achanta wrote:
> Yes I considered using singleton pattern but again I still face with
> the issue where onDestroy will be called after onCreate when it should
> not happen and I need to keep track of that case also. So I would just
> go with AsynkTask but take car
Hey Dianne,
Thank you for the tip on battery life. Will definitely try to make it
as good as possible for the battery life.
Yes I considered using singleton pattern but again I still face with
the issue where onDestroy will be called after onCreate when it should
not happen and I need to keep tra
On Thu, Mar 11, 2010 at 1:40 PM, Achanta wrote:
> Yes I am trying to redesign it to use AsyncTask. One reason why I did
> not take this approach is that I just wanted a plain thread that sits
> and logs user events that are occurring throughout my app and it made
> more sense to just start that t
On Thu, Mar 11, 2010 at 1:13 PM, Achanta wrote:
> Its not even passing onStop and onDestroy at some point in the future.
> It is only doing it in some point in the future when more activities
> are started. I tested it 4-5 times and let it run for atleast 5
> minutes. So I don't know how long I h
Thank you Mark,
Yes I am trying to redesign it to use AsyncTask. One reason why I did
not take this approach is that I just wanted a plain thread that sits
and logs user events that are occurring throughout my app and it made
more sense to just start that thread when the app starts and shut it
dow
Achanta wrote:
> Can anyone suggest a work around for this issue.
> I have a background thread which starts in the onCreate methos and
> which I close in the onDestroy method. But because of this bug in the
> sdk 2.1 my thread never stops. But when the user closes the
> app[onDestroy hasn't been ca
Thank you Dianne,
Its not even passing onStop and onDestroy at some point in the future.
It is only doing it in some point in the future when more activities
are started. I tested it 4-5 times and let it run for atleast 5
minutes. So I don't know how long I have to wait for the thread to
close.
C
Hi, there is an issue in 2.1 with the new launcher that causes the
onStop()/onDestroy() to be delayed longer than typical when going back to
home. Note these are not delayed -forever-, but just until later in the
future (when the next activity switch happens). These methods are defined
to happen
I too have the same issue and Mark, we discussed it earlier in another
thread. I was trying to use the onStop and onDestroy to stop Location
updates and other background threads that I start from onCreate
method.
Here is what I observed.
Here is what I have seen. I am using Nexus one [2.1].
Press
I'm having a similar lifecycle issue on the Nexus One.
Start the app ->OnCreate
Hit back -> no OnDestroy is called
Run app again ->OnCreate, followed by OnDestroy
The wierd thing is that it doesn't actually kill our application, so
it is left in a broken state since we are tearing things down in
Very few of my activities used onStart and onStop until recently when
I instrumented my application with Flurry Analytics. If you follow
the Flurry instrumentation instructions then you add calls to notify
Flurry about your application activity in the onStart and onStop
methods for every one of yo
I think a lot of apps don't use the onStop or onStart.
I never found a use for them (so far...).
onCreate, onResume, onPause and onDestroy are the most important ones.
The NonConfigurationInstance() methods for configuration changes.
On Mar 5, 9:26 am, Zuli wrote:
> I agree with Mark Murphy
I agree with Mark Murphy, it seems a problem only when the home screen
is displayed after the activity, if I open another activity on top of
that (long press on HOME) or if I receive a call the onStop is
correctly called...
seems to me quite a big issue, think about all the activities that use
the
mm... my app makes use of saving and restoring instance state a
lot and it works as well on the Nexus One as on the Droid or G1. But i
don't use the onStop callback at all. And I don't use the
onRestoreInstanceState either. Instead, i use the
onRetainNonConfigurationInstance() and
getLastNonCon
I think there are some issues with the background activity life cycle
management on the Nexus One.
In my app, I have a background and foreground activity. When I tilt
the phone so it switches orientation, the first time around the state
is properly saved and restored for the background acrivity.
Mark Murphy wrote:
> schwiz wrote:
>> It should be called when you press back but not home, but I have
>> noticed this problem using openeclair on my G1. Perhaps its a new
>> feature/bug in 2.1?
>
> No, onStop() should be called when you press either BACK or HOME. For
> some reason, it is not doi
schwiz wrote:
> It should be called when you press back but not home, but I have
> noticed this problem using openeclair on my G1. Perhaps its a new
> feature/bug in 2.1?
No, onStop() should be called when you press either BACK or HOME. For
some reason, it is not doing that in the Nexus One. My b
It should be called when you press back but not home, but I have
noticed this problem using openeclair on my G1. Perhaps its a new
feature/bug in 2.1?
On Mar 4, 1:54 pm, Zuli wrote:
> Hi Matias,
> thanks for your reply, but that's not the point. Because onStop() is
> called when the activity is
Hi Matias,
thanks for your reply, but that's not the point. Because onStop() is
called when the activity is no longer visibile, it should be called
when the user presses the HOME or BACK button, and that is not
happening on the Nexus One... well not on mine at least :)
Zuli
On Mar 4, 8:23 pm, Ma
Zuli, onStop() is called when your Activity is no longer visible, this
may happen if a new activity is created (full screen mode) and is
positioned in front of yours, also it may be caused because another
Activity is resumed and brought to front (also full screen) and in the
last case onStop() is c
The activity is destroyed. This doesn't mean the process is killed.
There could be other components in the same application using that
process. Also the platform may keep the process around for a variety
of reasons, including the fact that starting processes is expensive.
On Dec 5, 11:41 am, dan
I experienced similar problems. Depending on how you navigate back to
your Activity, Android does not know that it should reuse the existing
instance and creates a new one. You can fix this easily with the
activities launch mode, which you set in the AndroidManifest.xml.
Setting it to singleInstan
Tested on both 1.5-R2 and R3, same result.
On Aug 6, 10:22 pm, efan wrote:
> http://developer.android.com/reference/android/app/Activity.html
>
> The Activity Lifecycle could have implementation and or design bug:
> One case is to initialize a big image in onCreate(), try to reuse the
> image du
That affirms a lot for me. Thanks!
Richard Schilling
Root Wireless
On Jul 14, 4:35 pm, Dianne Hackborn wrote:
> No, it will never be true.
>
> The VM doesn't manage processes at all. The system starts a process and
> runs a VM inside of it when it needs to run any components of an
> applicat
No, it will never be true.
The VM doesn't manage processes at all. The system starts a process and
runs a VM inside of it when it needs to run any components of an
application. Unless you specify otherwise, all of your components run in
the same VM, in the same process, sharing all of the same s
1 - 100 of 115 matches
Mail list logo
