0

I need to extend ActionBarImpl, which is part of com.android.internal.app. But it is not recomended to do so, since it is bound to change anytime in new android releases.
Since I do not intend to re-implement ActionBarImpl I thought I will "cheat" by creating a class in this way:

public class MyActionBar extends ActionBar {
    private ActionBar ab;

    public MyActionBar(Activity activity) {
        ab = activity.getActionBar();
    }

    @Override
    public void setCustomView(View view) {
        ab.setCustomView(view);

    }

    ... (so on with all ActionBar abstract methods)

In words: I extend ActionBar + have a private member where I get the actual activity´s ActionBar and delegate all method calls to it.

Is there any drawback in doing it this way? I am not breaking compatibility,am I?

ilomambo
  • 8,290
  • 12
  • 57
  • 106

1 Answers1

0

What you are going to do is to apply Decorator pattern. But it seems not to work as you want, because your activity will still use the original instance of the ActionBar, not the decorated one.

antonv
  • 1,227
  • 13
  • 21
  • But I will be able to tweak any ActionBar method, adding code before/after the ActionBarImpl call. In my app I will replace the `ActionBar actionBar = getActionBar()` code with `ActionBar actionBar = new MyActionBar(this)` and keep using it as normal. – ilomambo Jul 24 '13 at 17:58
  • If you decorate original ActionBar methods, then you will be to wrap original logic with your own. But you may consider, that system and activity itself will still use original instance. Let's pretend that ActionBar has redraw() method to draw himself on the screen: whether you wrap this method or not the system will still use the original one - so your changes won't affect on how ActionBar will be drawn. – antonv Jul 25 '13 at 13:06