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;
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.
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
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
On Thu, Mar 11, 2010 at 1:13 PM, Achanta krishna.acha...@gmail.com 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
On Thu, Mar 11, 2010 at 1:40 PM, Achanta krishna.acha...@gmail.com 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
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
On Thu, Mar 11, 2010 at 1:59 PM, Achanta krishna.acha...@gmail.com 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
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
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,
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
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].
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
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
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
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 paolo.zuli...@gmail.com wrote:
I
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
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,
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 paolo.zuli...@gmail.com wrote:
Hi Matias,
thanks for your reply, but that's not the point. Because onStop() is
called
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
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 doing that
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
22 matches
Mail list logo
