Adding more responsibilities to Activities in a flexible way

Question

I am considering how I can add tasks to Android Activities in a flexible way. I can only use implementation inheritance for one thing in Java and I would like to use it, if I use it at all, for something else.

I think I need to draw the domain first a bit:

Activities are UI windows basically, with intrinsic lifecycle responsibilities enforced by the API. The tasks I speak of are UI-visible popovers that do some offline stuff and then disappear. They stem from AsyncTasks. The code of all of this is not a problem, I have this already, even pretty generalized with interfaces. I'm looking at further design improvements I can make.

There are many type of activities and they could all work with some types of tasks. For instance a search window would have a task that adds one of the search results, let's say it's a book, to the collection of books in the main application. It allows you to add multiple, hence the popover. A window that displays the collection has a task that lets you export a book to an external file format. It won't stop you from browsing through your collection, yet it needs to display a progress bar as it may take a while to export.

A specific Task exists as a nested class in a specific Activity. It needs to be saved away and restored along with lifecycle events: there's a onSaveInstanceState(Bundle) and onRestoreInstanceState(Bundle) for that, among others. The Activity has a list of active tasks (or just a member for one task). Some UI event will create a new task and add it to the list, a la onClick(): ATask task = new ATask(); task.execute(something);.

Here's what I have considered so far:

• Implementation inheritance

  Just move this task business to an abstract super class of all specific activities.

• Decorator pattern

  Create a TaskedActivityDecorator that would add this responsibility on any activity. The decorator would have to mimic the entire Activity interface as provided by the API, mostly passthroughs though. So this may already be a bit too heavyweight. It would also need to add the UI events/buttons that launch the task, which may not always be possible if the action is more consequential.

  But the biggest problem I could come up with here is that Android uses a manifest to loosely couple all activities together. Therein you need to declare every specific activity or it can not be used. This is a problem because the decorator would work at runtime, with composition. I can't declare the decorator and add in the information that it needs to wrap a specific activity.

  With Android I seem to end up with implementation inheritance a lot more than I'd like to. Hence I have too much coupling or code duplication. The activities always easily grow out to big fat classes. Am I correct to say that that is partly because of existing design choices in the Android framework, such as the manifest taking away composition solutions, or the Context object? Am I correct to say that from the get-go it cuts away a significant amount of established design patterns in key areas, including the MVC pattern.

• Decorator with wrappers:

  That I can't specify the decorator and the specific activity it applies to together in the manifest, doesn't mean I can't create classes that represent and arrange this composition. I could of course create many SpecificDecoratorActivity classes, that also implement the Activity interface and act like the decorator, and then wrap in the real specific activity. I'm not sure if it solves my problem though. It seems like a lot of work, a lot of rubbish classes, and takes me far from my original goal.

• Strategy pattern:

  If I can't skin the activity, then I'd better outsource part of its guts. This will give me yet more connections though as the activities will need to know about the Strategy. The Strategy itself however will be more lightweight as a Decorator. Yet it feels not so much like Strategy where there is a choice of which one, but rather just moving part of the class to another class. I would call it TaskManager. And would I still pull up the strategies knowledge into an activity super class?

• Any other pattern?:

Which pattern is the best choice? Don't shun your opinion on the specific Android case. No need to talk about tasks specifically.

Answer 1

First, I don't know anything about Android development, so I was waiting for someone else to answer you, but since you haven't gotten a lot of responses:

What about the Bridge pattern? This isn't the canonical case described in Design Patterns, but it sounds like it might fit, since what you want is to have separate hierarchies with implementation inheritance (one for tasks and one for activities).

This is similar to what you discussed as a strategy pattern, and yes, it is moving part of the class to another class, but to a new class that doesn't have the limitations (i.e., the manifest) of the old. I'm not sure this gives you more connections - a reference seems a weaker connection than a nested class.

As far as putting the strategies knowledge into an activity super class, you could, but you did state that you would rather use implementation inheritance for something else. If so you could put into an interface instead.

Answer 2

I think I don't fully understand what you're trying to accomplish, it was a lot to read, but I think I can say a couple things. You mentioned that Android doesn't have design patterns like MVC, I can say that this isn't correct. Android native classes play pretty nicely with POJOs, I think you can structure a lot of things however it makes the most since to.