I have built progress bars where I had a background thread that updated my
Activity via callbacks (to do GUI updates in the UI thread).
I ended up using a WeakReference object to hold the callback pointer to my
Activity. I have made the assumption (right or wrong) that my UI thread may
be gone while my background thread still exists. I was experiencing some
funky exceptions while testing my app -- I was rudely interrupting my
application by pressing the back or home button in the middle of my
background thread doing some non-GUI work.
So when it is time for my background thread to report to my UI thread, if my
WeakReference returns null, then I just silently exit my thread in the
background, knowing my UI thread is gone.
Below is a canonical example demonstrating what I am doing. There may be
more suitable solutions that I have not learned yet.
-broc
package foo.example;
import java.lang.ref.WeakReference;
public class BackgroundThreadExample extends Thread {
public interface Callback {
public void onSomeBadEventUpdateGuiThread(Object stuff);
public void onSomeGoodEventUpdateGuiThread(Object things);
}
private WeakReference<Callback> weakCallback;
private Object stuffYouCareAbout;
public BackgroundThreadExample(Callback callback, Object stuffYouCareAbout)
{
super("myThreadName");
this.weakCallback = new WeakReference<Callback>(callback);
this.stuffYouCareAbout = stuffYouCareAbout;
}
@Override
public void run() {
// do background stuff
boolean isGood = doStuff(this.stuffYouCareAbout);
try {
// inform our UI via callback.
if ( isGood ) {
getCallback().onSomeGoodEventUpdateGuiThread("was good");
} else {
getCallback().onSomeBadEventUpdateGuiThread("was bad");
}
}
catch (MyWeakRefException e) {
// our UI thread object is gone. bummer.
// silently fall thru to exit this thread.
}
}
private boolean doStuff(Object stuffYouCareAbout) {
// some useful stuff might go here.
return true;
}
private Callback getCallback() throws MyWeakRefException {
Callback callback = weakCallback.get();
if ( callback == null ) {
throw new MyWeakRefException();
} else {
return callback;
}
}
}
On Sat, Sep 26, 2009 at 8:17 PM, Kacper86 <[email protected]> wrote:
>
> Thank you for your response! It works great - now I can change the
> orientation and the ProgressDialog works. And do have any ideas how to
> solve the problem with user hitting "back" or "home" button? I found
> that you may set your Dialog with Dialog#setCancelable(false). Then,
> the user can only hit "home" button, and when he launches the app
> again, ProgressDialog is still there!
>
> However, what should be done if I want Dialog that can be cancelable?
> So that the user can cancel ProgressDialog, set something in the app
> settings, hit "home" button, run sth else, and then relaunch my app to
> check the progress?
>
> On Sep 26, 11:36 am, manoj <[email protected]> wrote:
> > You need to implement the method
> > public void onConfigurationChanged(Configuration arg0)
> > {
> > super.onConfigurationChanged(arg0);
> > }
> >
> > in your activity. and in manifest file, you have to the statement
> > android:configChanges="keyboardHidden|orientation" for that activity.
> >
> > so when your screen orientation is changed, it wont call the onCreate
> > () method again.
> >
> > On Sep 26, 1:21 pm, Kacper86 <[email protected]> wrote:
> >
> > > Hi!
> >
> > > I've created ProgressDialog with a second thread according to the
> > > DevGuide:
> > >
> http://developer.android.com/guide/topics/ui/dialogs.html#ProgressDialog
> > > It works great till user:
> >
> > > 1) changes screen orientation or
> > > 2) hits the back button twice (first to hide the dialog, second to
> > > hide the app) to hide the application and run the app again after a
> > > while.
> >
> > > Then, onCreate() is called (for the second time), and progress bar
> > > stops responding properly. My thread may work for a few minutes and I
> > > want to give the user possibility to hide it and do sth else. After a
> > > while he might want to run the app again in order to check the
> > > progress.
> >
> > > I found a few articles concerning this topic, but I couldn't find the
> > > exact solution I should chose for this problem. So, could you tell mi
> > > what is the proper way to handle this? Should i save the handler and
> > > dialog state with "onRetainNonConfigurationInstance()"? If so, how to
> > > do it properly and is it safe?
> >
> > > Or maybe my solution is wrong and I should create service, which
> > > spawns the thread and communicates with activity (progress bar) with
> > > AIDL? But this will mean that the article in DevGuide is wrong, cause
> > > it doesn't give a long term solution for creating a progress bar...
> >
> > > I'm stuck, and I'd appreciate all the response!
> >
> >
> >
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
-~----------~----~----~----~------~----~------~--~---
