OK, I think I figured it out. When the AlertDialog is created, I use: numFoundDisplay = (TextView)layout.findViewById(R.id.numFound);
to get a reference to that TextView in the AlertDialog. That reference (numFoundDisplay) is owned by the Activity, and as long as that Activity lives and does not null out that reference, Android will not deallocate that TextView within the AlertDialog, even after the AlertDialog has been dismissed. So the TextView, as an object in memory, will continue to exist, and it will be valid to call setText() on that reference, even after the AlertDialog has been dismissed, because the Activity still holds a strong reference to that TextView. So if I use a Handler and a Runnable to update the TextView asynchronously, there will not be a crash or anything. The setText() will just be ineffective because the TextView is no longer visible. Do I have that right? -Robert Scott Hopkins, MN On Thursday, March 24, 2016 at 8:38:03 PM UTC-6, RLScott wrote: > > What is the correct way to update a TextView after a callback in the > following scenario: > > I have an activity that extends ListActivity. At some point that > activity creates an AlertDialog to allow the user the option of filtering > the list for items that contain a certain String (because the unfiltered > list might be too long to scroll through it conveniently). My AlertDialog > has, in addition to an OK and Cancel button, an EditText so the user can > enter the String to use for filtering, and two radio buttons to select > whether we should filter for list items that start with the specified > String or merely contain the specified String. I have listeners set up for > any changes to the EditText or RadioButtons so that I can cause the list to > be reloaded based on the revised filtering criteria. All this is working > fine with no problems. I can see the list changing behind the AlertDialog > as I enter characters into the EditText. > > The problem is this. I also want to have a TextView that displays "(X > items found)" after each reloading of the list, so the user can know when > he has sufficiently narrowed the search so he can quit the AlertDialog and > then pick from the (reduced) set of items now in the list. One other > complication is that the reloading of the list involves a callback on a > worker thread. You see, the list is a list of Dropbox files, and the > asynchronous load is necessary because it might involve an Internet > access. The callback is actually from a library provided by Dropbox. > Therefore the place where the reloading (and item counting) is done is not > the UI thread, so I can't update a TextView from there. I am familiar with > Handlers and posting from threads, but there is a problem with that too. > The Handler would be owned by the Activity, not by the AlertDialog, which > could be dismissed before the asynchronous reload occurs. Will there be a > problem if a post is made to start a Runnable that updates the TextView > that was in the AlertDialog if that AlertDialog, and therefore the TextView > inside it, has been destroyed? > > What if I define a strong reference in the Activity to the TextView, and > the Runnable that is triggered by the asynchronous Dropbox operation just > calls setText on that reference? Will that do anything bad if the Runnable > is invoked after the AlertDialog is dismissed? What is the clean way of > doing this? > > -Robert Scott > Hopkins, MN > > -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to android-developers+unsubscr...@googlegroups.com. To post to this group, send email to android-developers@googlegroups.com. Visit this group at https://groups.google.com/group/android-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/android-developers/18bd6847-7e5b-4586-aadb-fa77d333810c%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
