I deal with these situations by just keeping a public static reference
around to the currently active activity. E.g.
public MyActivity extends Activity {
public static MyActivity ACTIVE_INSTANCE = null;
protected void onCreate() {
ACTIVE_INSTANCE = this;
...
}
protected void onDestroy {
...
ACTIVE_INSTANCE = null; // clean up. important to do this.
}
...
}
And within my background threads, i just use the
MyActivity.ACTIVE_INSTANCE to access any part of MyActivity's gui
elements (getting a handler to post back a message to its gui-thread
and then during the handling of that message, i use
MyActivity.ACTIVE_INSTANCE again to update the GUI, e.g. dismissing
waiting dialogs, updating progess dialogs).
And I check for MyActivity.ACTIVE_INSTANCE being null... just in
case :-)
This assumes that there is at most one instance of an activity around
at any given time.
On Aug 30, 9:23 pm, CraigsRace <craig...@gmail.com> wrote:
> Romain: Agreed, my solution is bad.
>
> I still feel like there should be a solution. I would think a lot of
> developers would want to do UI from a thread (closing a progress
> dialog, etc). And making them track if the activity has been
> destroyed and recreated seems like something that the framework should
> be able to handle (or at least have some sort of helper class for).
>
> Also, the "Example ProgressDialog with a second thread"
> inhttp://developer.android.com/guide/topics/ui/dialogs.html#ProgressDialog
> is bad example, as it starts a new thread on every screen rotate, so,
> devs (like me) will move the creation of the thread into the button
> click, and then fall into the issue discussed here where they need to
> track Activity creation/deletion (which there is no example for).
>
> On Aug 31, 10:36 am, Romain Guy <romain...@google.com> wrote:
>
>
>
> > No, this is not a good solution. There is no guarantee on how long the
> > thread will run, which means there is no guarantee on how long the
> > Activity (and everything tied to it) will survive.
>
> > On Sun, Aug 30, 2009 at 4:00 PM, CraigsRace<craig...@gmail.com> wrote:
>
> > > The thread is holding onto the old activity, nothing else references
> > > it. When the thread dies, so does the old activity.
>
> > > I went ahead and wrote a solution myself by extending the Activity
> > > class.
>
> > > What I wanted to do was:
> > > 1. onSaveInstanceState put a reference to itself (the activity) in the
> > > Bundle.
> > > 2. onCreate retrieve the reference to the activity in the bundle (if
> > > it exists), then call the activity telling it about itself. Ie: It
> > > tell the old activity about itself (the new activity).
> > > 3. Make showDialog and dismissDialog call out to the new activity (if
> > > it exists).
>
> > > There were 2 problems with this:
> > > 1. showDialog and dismissDialog are marked as final
> > > 2. Bundle doesn't allow Objects to be added to it.
>
> > > I worked around this by:
> > > 1. Creating showDialog2 and dismissDialog2 methods.
> > > 2. Not using the Bundle, rather a static variable (this is not a good
> > > solution, as it is assumes there will only be 1 activity).
>
> > > These workarounds mean that it is not a proper solution for all devs
> > > to use.
>
> > > However, the Android framework could easily be enhanced to do this.
>
> > > Cheers.
>
> > > PS: I was going to attach my code as reference, however, I can't see
> > > anywhere that I can do this.
>
> > > On Aug 31, 1:44 am, Dianne Hackborn <hack...@android.com> wrote:
> > >> And that still means it needs to keep the old activity around so the
> > >> thread
> > >> can use it.
>
> > >> On Sat, Aug 29, 2009 at 9:47 PM, CraigsRace <craig...@gmail.com> wrote:
>
> > >> > It would only be a forward reference (from the destroyed activity to
> > >> > the new activity), not a back reference.
>
> > >> > On Aug 30, 2:34 pm, Romain Guy <romain...@google.com> wrote:
> > >> > > > However, couldn't the Android framework just forward any requests
> > >> > > > from
> > >> > > > a destroyed activity, to the newly created Activity, saving us
> > >> > > > developers the pain of handling it ourselves?
>
> > >> > > To do this, the framework would have to keep around references to all
> > >> > > previous Activities pretty much forever. Which would be a large waste
> > >> > > of resources.
>
> > >> > > --
> > >> > > Romain Guy
> > >> > > Android framework engineer
> > >> > > romain...@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, and so won't reply to such e-mails. All such
> > >> questions should be posted on public forums, where I and others can see
> > >> and
> > >> answer them.
>
> > --
> > Romain Guy
> > Android framework engineer
> > romain...@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- Hide quoted text
> > -
>
> - Show quoted text -
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
