Not necessarily an "upgrade", but a different set of tradeoffs. If I change
the method signature of a utility method, I only have to change it in my
base classes and not in my concrete activity classes. Of course, I always
have the option of extending those methods in the concrete classes, so I
Cory, you and I have basically done the same thing. I think an upgrade to
this approach is being suggested by TreKing and Kostya, which is, simply
using the delegation, but ditching the base classes. That way, if we need
different delegates we can pick and choose on the fly as necessary. A
l
>
> What happens when you need a MapActivity? Or ListActivity? Or
> ExpandableListActivity? Or ... ?
>
Good point. I rewrote my base classes to delegate to a utility class. I have
each base class pass itself to the constructor of the utility class in case
it needs to reference the current act
On Wed, May 11, 2011 at 1:08 PM, Cory Kaufman wrote:
> It's worked out well for me to create a base class that extends Activity
> that all of my other activities extend, so I have a central
> place to put common functionality.
>
What happens when you need a MapActivity? Or ListActivity? Or
Expand
Hi,
Has anyone started cataloging common design patterns that arise when
developing Android apps?
For example:
It's worked out well for me to create a base class that extends
Activity that all of my other activities extend, so I have a central
place to put common functionality.
When should strin
5 matches
Mail list logo
