dimitar.me

Android – Displaying Dialogs From Background Threads

Having threads to do some heavy lifting and long processing in the background is pretty standard stuff. Very often you would want to notify or prompt the user after the background task has finished by displaying a Dialog.

The displaying of the Dialog has to happen on the UI thread, so you would do that either in the Handler object for the thread or in the onPostExecute method of an AsyncTask (which is a thread as well, just an easier way of implementing it). That is a textbook way of doing this and you would think that pretty much nothing wrong could go with this.

Surprisingly I found out that something CAN actually go wrong with this. After Google updated the Android Market and started giving crash reports to the developers I received the following exception:

android.view.WindowManager$BadTokenException: Unable to add window — token android.os.BinderProxy@447a6748 is not valid; is your activity running?
at android.view.ViewRoot.setView(ViewRoot.java:468)
at android.view.WindowManagerImpl.addView(WindowManagerImpl.java:177)
at android.view.WindowManagerImpl.addView(WindowManagerImpl.java:91)
at android.view.Window$LocalWindowManager.addView(Window.java:424)
at android.app.Dialog.show(Dialog.java:239)
at android.app.Activity.showDialog(Activity.java:2488)
…
at android.os.Handler.dispatchMessage(Handler.java:99)
…

I only got a couple of these exceptions from thousands of installs, so I knew that was not anything that happens regularly or that it was easy to replicate.

Looking at the stack trace above it gives us a pretty good idea why it failed. It started in the Handler object, which naturally was called by a background thread after it finished its processing. The Handler instance tried to show a Dialog and before it could show it, it tried to set the View for it and then it failed with:

android.view.WindowManager$BadTokenException: Unable to add window — token android.os.BinderProxy@447a6748 is not valid; is your activity running?

The 447a6748 number is just a memory address of an object that no longer exists.

Note- do not get hung up on the exact number. It would be different with every execution.

Now we know why the application crashed, the only thing left is to figure out what caused it?

We know that background threads execute independently of the main UI thread. That means that the user could be interacting with the application during the time that the thread is doing its work under the covers. Well, what happens if the user hits the “Back” button on the device while the background thread is running and what happens to the Dialog that this thread is supposed to show? Well, if the timing is right the application will most likely crash with the above described error.

In other words what happens is that the Activity will be going through its destruction when the background thread finishes its work and tries to show a Dialog.

In this case it is almost certain that this should have been handled by the Virtual Machine. It should have recognized the fact that the Activity is in the process of finishing and not even attempted to show the Dialog. This is an oversight of the Google developers and it will probably be fixed some time in the future, but in the meantime the burden is on us to take care of this.

The fix to this is pretty simple. Just test if the Activity is going through its finishing phase before displaying the Dialog:

private Handler myHandler = new Handler() {
  @Override
  public void handleMessage(Message msg) {
    switch (msg.what) {
      case DISPLAY_DLG:
        if (!isFinishing()) {
        showDialog(MY_DIALOG);
        }
      break;
    }
  }
};

Change the date and time (or any other EXIF image meta-data) of pictures with Ubuntu

There is a very flexible and easy Linux tool that helps you change the EXIF meta-data of images. It allows you to change individual files or whole bunch of them with one command. You can also put different rules about what files and how you want to change them if you need to.

The program is called exiftool. So let’s install it first.

In terminal execute:

sudo apt-get install libimage-exiftool-perl

Now you are ready to start changing the meta-data of the images.

For example, if I wanted to change all the dates and times (DateTimeOriginal, CreateDate and ModifyDate) of the IMG_01.jpg file to the 8th of August 2010 at 3:35:33 PM I would do:

exiftool -AllDates='2010:08:08 15:35:33' -overwrite_original IMG_01.jpg

If I wanted to change the dates on all the files in the “images” directory, I would do:

exiftool -AllDates='2010:08:08 15:35:33' -overwrite_original images

The “-overwrite_original” option is necessary if you want to change the meta-data of the original images. If you omit that option, then exiftool will back-up the originals by making a copy of them and adding “_original” to the end of the file names.

If you want to change the dates to all the files in the “images” directory that were taken by a Cannon camera (and not touch the rest) I would do:

exiftool -AllDates='2010:08:08 15:35:33' -if '$make eq "Canon"' -overwrite_original images

As far as changing dates and times, there is another option of exiftool that lets you do time calculation.

For example, the other day I found out that my camera’s time was correct but the date was ahead by 30 days. That meant that all the photos I had taken lately had dates that were off by exactly 30 days. If I were to use the above examples I could set the dates individually (which would be a long and tedious process) or set all the images to the same date and time (which would be wrong). In this case I used the date calculating option and just executed:

exiftool -AllDates-=720:00 -overwrite_original images

That command subtracts 720 hours (30 days) off the dates of each image file in the images directory. Now every image has the exact date and time it was taken.

I have only scratched the surface of what this tool is capable of. For more information look at the man pages of the exiftool command.