views:

1394

answers:

2

I know that Android provides some useful methods to be overridden in order to define a menu:

    @Override
 public boolean onCreateOptionsMenu(Menu menu) {
  menu.add(0, AIS, 0, "Activity Inventory Sheet").setIcon(android.R.drawable.ic_menu_upload);
                // ...
  return true;
 }

 public boolean onOptionsItemSelected(MenuItem item) {
  Intent i;
     switch (item.getItemId()) {
     case AIS: i = new Intent(this, ActivityInventorySheet.class);
      startActivity(i);
               return true;
     // ...
     }
     return false;
 }

I would like to have this menu shared by each Activity and ListActivity of my Android application. This is for having a standard menu in each (List) Activity that lets the user jump to every part of the application within a click.

Right now, the easiest way to achieve this is to copy-and-paste both methods in every (List) Activity of the application. I don't like this redundancy of code written :)

Is sub-classing a reasonable choice? I've already seen that sub-classing one of my ListActivity does not work very well (threads that retrieve objects from a database are giving problems). Are there other ways to share a menu though Activities?

Thanks

+6  A: 

I see no reason this wouldn't work perfectly:

public abstract class MyListActivity extends ListActivity
{
   @Override
   public boolean onCreateOptionsMenu(Menu menu) {
      menu.add(0, AIS, 0, "Activity Inventory Sheet").setIcon(android.R.drawable.ic_menu_upload);
      // ...
      return true;
   }

   @Override
   public boolean onOptionsItemSelected(MenuItem item) {
      Intent i;
      switch (item.getItemId()) {
          case AIS: i = new Intent(this, ActivityInventorySheet.class);
          startActivity(i);
          return true;
          // ...
      }
      return false;
   }    
}

Then just have your Activities extend MyListActivity instead of ListActivity.

I've already seen that sub-classing one of my ListActivity does not work very well (threads that retrieve objects from a database are giving problems).

This sounds like a completely different problem. You might want to post a separate question regarding this. Simply extending a class in Java shouldn't create any problems like the one you are describing.

mbaird
This is working very well.I have to create two abstract classes, one for the Activities and the other one for the ListActivities (otherwise the example you provided won't work for simple Activities).Anyway, this is much less code to be written and suites my needs. Thank you!
bodom_lx
+7  A: 

I use a helper class with static methods to initialize and handle common menu options, then each Activity defines its own onCreateOptionsMenu etc. that delegates common tasks to the helper class, and may add further menu items specific to that Activity.

Something like

class SharedMenu {
    public static void onCreateOptionsMenu(Menu menu) {
        menu.add(...);
        menu.add(...);
    }
}

public class MyActivity extends Activity {

    @Override
    public boolean onCreateOptionsMenu(Menu menu) {
        super.onCreateOptionsMenu(menu);
        menu.add(...);  // specific to this activity
        SharedMenu.onCreateOptionsMenu(menu);
        return true;
    }

}

with more methods for onMenuItemSelected etc.

Edit: I'm not using a common base class because I'd need two of them to start with, one for activities and another one for list activities, and then in my case I need to add custom menu options on some activities.

Mirko Nasato
Avoiding subclassing is a good thing.
Daniel Yankowsky
This is also a good answer, especially if you need to inflate custom menu options
bodom_lx