views:

301

answers:

3

While programming on Android, I end up writing a parent activity which is extended by several others. A bit like ListActivity. My parent activity extends Activity. if I intend to use a Map or a List, I can't use my parent activity as superclass - the child activity can only extend one activity obviously. As such I end up writing my parent activities with the same logic for Activity, ListActivity, MapActivity and so forth.

What am I looking for is some sort of trait functionality/design pattern which would help in this case. Any suggestions?

+1  A: 

I've ended up having a base MyAbstractActivity extends Activity that incorporates shared logic and a MyAbstractListActivity extends MyAbstractActivity that mimics ListActivity (inflates layout.R.id.list, layout.R.id.empty, etc.; not much going on there).

alex
+1  A: 

I really dislike ListActivity, MapActivity ect. Basically they are activities which simply add a single view element at the cost of some flexibility. By adding a MapView or ListView to your xml appropriately, you end up with the same thing which can extend an Activity derived superclass directly. So just don't use any of those SomethingActivity classes for the most part.

jqpubliq
It is not only adding a view. You have the map lifecycle/cursor handler and so forth depending on which activity you use. The benefits might not balance the inflexibility but some code is definitely gained by using predisposed classes.
Carl
+1  A: 

I'm using a delegate with all the shared functionality. This enables me to have all the shared functionality in one single class for all the different activities.
All my activities extend their special activity and then implement a common interface. The problem with this approach is that I need to implement all the methods defined in the interface and call the matching method in the delegate object. This code at the moment amounts to 30 duplicate lines of code and I think that is not that much of a problem.

Janusz