I meant that the static variable would -hold- the current activity.
Everything in your .apk runs in one process. When you declare a static
variable, that is creating a global to all code in that process. You can
make a static variable pointing to an Activity:
static Activity mCurActivity = null;
In your activity's onCreate() set it to 'this'. In onDestroy() set it to
null.
Now someone else -- a thread or whatever -- can come in, and retrieve the
value of mCurActivity to find out the current activity that has been set.
On Sun, Jan 25, 2009 at 4:47 PM, Brad Gies <rbg...@gmail.com> wrote:
> Dianne,
>
>
>
> I can't quite figure out what you mean by "setting a static variable in the
> current activity", and how it would work. If I set a static variable in my
> activity and then pass that static variable to my thread, then the activity
> is destroyed, and a new one is created…. Then what happens? The new activity
> will create another static variable, but the thread won't know about it, so
> how would it help? And the new activity doesn't know about the thread, so I
> don't think it would have the information it needed to alert the thread that
> it can now accept the information.
>
>
>
> What am I missing?
>
>
>
> What I currently do is set a static variable in my thread which is the
> handler to my activity, and then if the activity is destroyed before the
> thread completes, it sets the handler variable in the thread to null before
> it completes. The thread then checks the Handler variable before it tries to
> send the information, and just cleans up after itself if it cannot send the
> information.
>
>
>
> Then, when the new activity is created it checks to see if it still needs
> the information and creates a new thread if needed.
>
>
>
> BUT…. if there is a way for the new activity to get the Handle of the
> Thread created by the old activity, then I could easily change the thread to
> wait for a few seconds waiting for a new Handler to be assigned, and that
> would be much more efficient.
>
>
>
> Do you have an example you can point me to?
>
>
>
>
>
> Sincerely,
>
>
>
> Brad Gies
>
>
>
>
>
> -----------------------------------------------------------------
>
> Brad Gies
>
> 27415 Greenfield Rd, # 2,
>
> Southfield, MI, USA
>
> 48076
>
> www.bgies.com www.truckerphone.com
>
> www.EDI-Easy.com www.pricebunny.com
>
> -----------------------------------------------------------------
>
>
>
> Moderation in everything, including abstinence
> ------------------------------
>
> *From:* android-developers@googlegroups.com [mailto:
> android-develop...@googlegroups.com] *On Behalf Of *Dianne Hackborn
> *Sent:* Friday, January 23, 2009 3:07 PM
> *To:* android-developers@googlegroups.com
> *Subject:* [android-developers] Re: Activity Issue on G1 phone
>
>
>
> There are two reasons for this:
>
> 1. Both screen rotation and keyboard shown/hidden are configuration
> changes, which means that after the state changes the application's
> resources can have any arbitrary new values -- anything from specific
> strings (for ex in a particular language you may need a abbreviation when in
> portrait mode) to layout resources and anything else. Trying to keep track
> of, and update, any of these values that could have changed would require a
> lot of work in the system, and a fair amount of effort from the developer to
> help the system, so it is far easier to just restart the entire activity
> with the new configuration.
>
> 2. To be a correct application, you already need to deal with saving and
> restoring state so you will always be returned to the user in your previous
> state after being in the background. By relying on this same mechanism for
> configuration changes, we get to take advantage of the work the developer
> has already done, and also further encourage them to actually do that work
> which otherwise often only causes problems in the application in obscure
> cases, so can often be missed.
>
> For the case of a thread running in the background that wants to
> communicate back with the current activity, an easy way to deal with this is
> to have a static variable that is the "current" activity, which you set in
> your onCreate() and clear in onDestroy(). Then instead of pointing to the
> activity that originally started it, the thread can just retrieve the
> current value in that variable when it needs it. (And of course it will
> need to deal with the race where it can temporarily be null between the old
> activity being destroyed and the new one created... but if you are doing
> multithreaded programming, this should be familiar territory!)
>
> On Fri, Jan 23, 2009 at 9:52 AM, Stanley.lei <xiaofeng.lei...@gmail.com>
> wrote:
>
>
> I rather agree with you!
>
> In fact, I could not understand why Google designs like this. The
> keyboard action could impact the rotation, but why changing rotation
> impacts the activity? In my case, the thread is destroyed, which will
> destroy all tasks in the thread. In worst case, the user will have to
> re-create their data from scratch.
>
> stanley
>
>
> On Jan 24, 1:47 am, cindy <ypu01...@yahoo.com> wrote:
> > Then android's implementation has problem.
> >
> > For example, if my application needs to create account, of cause, the
> > key board will open first. After user typed in user name and password,
> > then he clickes the "create" button.Request sends to server in a
> > thread. After that, he closes the keyboard, the activity will be
> > destroyed. So the callback function in thread to update UI will
> > crashed.
> >
> > It happens exactly in my application.
> >
> > On Jan 23, 7:20 am, "James Patillo" <ja...@patillo.org> wrote:
> >
> > > I think what happens is that the activity's state is saved, the
> activity is
> > > destroyed, and then it is recreated with its saved state. This is the
> same
> > > thing that happens when the home button is pressed and the app is
> reopened.
> >
> > > This just what I have come to understand, and may be wrong.
> >
> > > -----Original Message-----
> > > From: Stanley.lei [mailto:xiaofeng.lei...@gmail.com]
> > > Sent: Friday, January 23, 2009 9:04 AM
> > > To: Android Developers
> >
> > > Cc: jinnan....@gmail.com
> > > Subject: [android-developers] Activity Issue on G1 phone
> >
> > > Hi all,
> >
> > > I met a very strange issue when I tested my application on G1 phone.
> >
> > > As usual method, I started a thread in an activity, and stopped the
> > > thread in the onDestroy method. But to my surprise, when I tried to
> > > slide down the keypad, the onDestroy method was called and the thread
> > > was stopped, and more surprising thing was that the activity was still
> > > alive and visible.
> >
> > > From the activity's life cycle diagram,
> http://code.google.com/android/reference/android/app/Activity.html, we
> > > can see that onDestroy is called only before the activity is shut
> > > down. But my activity is still active and visible!!!
> >
> > > Who could tell me what the hidden story is?
> >
> > > Any reply will be appreciated.
> >
> > > Thanks,
> >
> > > Stanley
> >
> >
>
>
>
>
> --
> Dianne Hackborn
> Android framework engineer
> hack...@android.com
>
> Note: please don't send private questions to me, as I don't have time to
> provide private support. All such questions should be posted on public
> forums, where I and others can see and answer them.
>
>
>
> >
>
--
Dianne Hackborn
Android framework engineer
hack...@android.com
Note: please don't send private questions to me, as I don't have time to
provide private support. All such questions should be posted on public
forums, where I and others can see and answer them.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers-unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
-~----------~----~----~----~------~----~------~--~---
