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
23 matches
Mail list logo
