Super constructor call in Blackberry Screen classes.

Question

Why is the super() constructor recommended to be called when extending any of the RIM Screen classes? It was my understanding that the no-arg constructor of any super class was implicitly called from any class that extends it, am I wrong?

Answer 1

No, you're absolutely right. Some people like putting it in explicitly for clarity - I'm not a fan, personally.

Can you link to such a recommendation, so we can check there's nothing more subtle going on?

Answer 2

RIM has implemented their own Java VM and compiler. It may or may not implement sub-classing exactly like the standard Java VM and compiler. If RIM recommends doing it a certain way, I would simply follow it.

If you really want to omit the call to super() I would test it out rather than make assumptions.

However, I can't find any reference to official docs saying you need to do this. Field, Manager and Screen class javadocs don't mention it.

Answer 3

You are right about the no-arg constructor being implicitly called. And I'm pretty damn sure that also the RIM JRE does it this way.

I guess what you stumbled upon is just the notorious "super basic beginner hello world example" which even calls super() explicitly so that every java noob understands that the constructor of MainScreen is called too.

I looked through most of the samples on the page you linked to and it looks like a copy-paste thing. If you for example checkout the Using PIM functions sample you will notice that here the call to super() is missing from the no-arg child constructor.

Answer 4

super() will be called by default constructor no matter if you implement it or not.

It's easy to test. Just a couple classes:

class ClassA {
    public ClassA() {
     UiApplication.getUiApplication().invokeLater(new Runnable() {
      public void run() {
       Dialog.inform("ClassA()");
      }
     });
    }
}

class ClassB extends ClassA {
    public ClassB() {
     super();
     UiApplication.getUiApplication().invokeLater(new Runnable() {
      public void run() {
       Dialog.inform("ClassB()");
      }
     });
    }
}

class ClassC extends ClassA {

}

class ClassD extends ClassA {
    public ClassD() {
     UiApplication.getUiApplication().invokeLater(new Runnable() {
      public void run() {
       Dialog.inform("ClassD()");
      }
     });
    }
}

And test app:

class Scr extends MainScreen {

    protected void makeMenu(Menu menu, int instance) {
     super.makeMenu(menu, instance);

     menu.add(new MenuItem("class A", 0, 0) {
      public void run() {
       ClassA a = new ClassA();
      }
     });
     menu.add(new MenuItem("class B", 0, 0) {
      public void run() {
       ClassB b = new ClassB();
      }
     });
     menu.add(new MenuItem("class C", 0, 0) {
      public void run() {
       ClassC c = new ClassC();
      }
     });
     menu.add(new MenuItem("class D", 0, 0) {
      public void run() {
       ClassD d = new ClassD();
      }
     });
    }
}

So you see, there is no difference between dialog calls in ClassA() and ClassC(), also no diffs between ClassB() and ClassD().