Is there a design template to reduce code duplication in the Activities sub-class in Android?


I've got a common task that I do with some Activities - downloading data then displaying it. I've got the downloading part down pat; it is, of course, a little tricky due to the possibility of the user changing the orientation or cancelling the Activity before the download is complete, but the code is there. There is enough code handling these cases such that I don't want to have to copy/paste it to each Activity I have, so I thought to create an abstract subclass Activity itself such that it handles a single background download which then launches a method which fills the page with data.

This all works. The issue is that, due to single inheritance, I am forced to recreate the exact same class for any other type of Activity - for example, I use Activity, ListActivity and MapActivity. To use the same technique for all three requires three duplicate classes, except each extends a different Activity.

Is there a design pattern that can cut down on the code duplication? As it stands, I have saved much duplication already, but it pains me to see the exact same code in three classes just so that they each subclass a different type of Activity.

Edit: Since it seems I need to be a bit more specific...

Suppose I'm trying to solve the problem of an AsyncTask background download during orientation changes. The solution I have right now is to use callbacks; there's download manager that I have which starts these downloads, and then I have the Activity attach a callback to it. When the orientation changes the Activity is destroyed and then recreated; during this process I detach the old Activity's callback, then attach a new callback from the new Activity afterwards.

Orientation changes are a common problem, and in multiple Activities I start the Activity with a progress view while the data loads. What I am trying to solve is not having to re-implement this orientation-handling logic ten times over; my initial solution was to subclass Activity, but then I got the problem above.

Prefer composition over inheritance. Whatever is common, delegate to some class(es) that can be a member of Activity, ListActivity, and MapActivity.