Delegation is more powerful than inheritance, even multiple
inheritance. (But multiple inheritance can often express the same
ideas more concisely, declaratively, and consistently).
The simplest thing to do is to delegate to methods your Application
object for creating and preparing the menus. This works for context
menus, too.
Each Activity's onCreate...Menu methods pass the menu on to the
delegate, e.g. the Application, to be filled in with the common
pieces, while filling in the items specific to this activity.
Each Activity's onPrepareOptionsMenu method sets the enable &
visibility flags for its menu items that change, while passing the
menu on to the delegate for processing the common pieces (together
with any state that might be needed).
Each Activity's on...ItemSelected(Menu) method does the usual ||
thing, but with an extra step:
@Override
public boolean onOptionsItemSelected(MenuItem item) {
boolean val = handleCommandMenuItemSelected(item)
|| m_app.handleMenuItemSelected(this, item)
|| super.onOptionsItemSelected(item);
updateDisplay();
return val;
}
Note that it's generally necessary to pass along the Activity to the
methods on the delegate. It may also be necessary to pass on other
state. For example, if your Activity's are launched by some of those
common views, you probably don't want the menu item that launched your
Activity to appear on the menu while in that Activity (or at least, to
be disabled). So you'll need to pass along the relevant menu ID.
Remember that the super.onCreate...() will pick up menu items from
further up the view hierarchy -- itself a form of delegation -- as
well as further up the class hierarchy. You do want to think about
what you're doing, or you will end up with multiple entries. In
complex cases, you may want to pass along a Set to track what's been
added -- but generally a better strategy is to have things added in
one place only.
In a more complex application, you may have more delegates. The
delegates are likely to involve your model, and not just your
activity.
Inheritance works best for hooking in delegation -- for intercepting
existing behaviors, and redirecting them. A class that does a lot of
specific stuff in method overrides will not be nearly as reusable as
one that does a minimal amount of overriding, and delegates to a well-
chosen set of delegate objects. The class hierarchy then becomes your
mode of connecting to the framework, while your collaborating
delegation objects become the structure of your application, which is
freed to align itself with your task.
On Feb 16, 10:28 am, Mark Murphy <[email protected]> wrote:
> Frank Weiss wrote:
> > Although Mark's idea is workable, it may be bad OOD. It would work if
> > all your apps are direct subclasses of Activity, but what if some are
> > MapActivity, etc?
>
> Yup.
>
> :: wishes Java had Ruby's mixin capability for things like this ::
>
> --
> Mark Murphy (a Commons
> Guy)http://commonsware.com|http://twitter.com/commonsguy
>
> Android App Developer Books:http://commonsware.com/books
--
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
