Interesting, will take a look into the injection approach to see if it has
merits for my particular uses. Looking at the other thread, TreKing, your
proxy approach looks to be what I would consider delegation, I suppose proxy
means the same thing, since you're delegating to a proxy :) Perhaps just
keeping the delegation approach and removing the subclassing (delegation
present in base classes) as discussed here may prove to be a bit more
flexible, since different areas could then be delegated differently to
different delegate or proxy classes when needed. It will remove the extra
classes and dependencies on base class implementation of calls to the
delegate.
On Thursday, May 12, 2011 3:33:10 PM UTC-4, Kostya Vasilyev wrote:
>
> It seems like we're discussing this in the abstract, as common
> functionality can mean a lot of different things.
>
> Given that Java doesn't have multiple inheritance (which in my opinion
> is a good thing), the basic options I can think of are:
>
> - A common base class;
> - Delegation.
>
> Having a common base class gets in the way of using Android-defined
> Activity subclasses, however.... I can see MapActivity and
> PreferenceActivity being useful, but not being able to use e.g.
> {Expandable}ListActivity doesn't seem like a big loss.
>
> Still, I prefer delegation in most cases. This lets you use multiple
> helper objects if needed, whereas a common base class can provide only
> one customization. Delegating a handful of most important lifecycle
> methods isn't hard either.
>
> Taking the base class approach with more than one base class
> (MyActivity, MyMapActivity, MyPrefrenceActivity) raises the question of
> how these classes would implement their common functionality and avoid
> code duplication. The answer is most likely delegation, again.
>
> A third option is code injection.
>
> There are libraries for Android that use the common base class approach
> (GreenDroid, IIRC), and code injection (can't remember the name right now).
>
> -- Kostya
>
> 12.05.2011 23:03, Adam Ratana пишет:
> > It's not really pretty though and I'm curious what other approaches
> > have been used in the wild, to share some common functionality across
> > different Activity classes of different types; I feel this design can
> > be re-factored into something better and more scalable/maintainable.
> > For my purposes right now, it's fine, and I'm sure I will re-factor it
> > soon enough, when time and priorities allow. But curious what other
> > developers have done to share common code across different Activities
> > which are all derived from different parent classes. I'm making an
> > assumption that we're talking about common code that we want to
> > execute during activity lifecycle methods and activity related
> > methods?
>
>
> --
> Kostya Vasilyev -- http://kmansoft.wordpress.com
>
>
--
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
