Why Do We Have to Call Super in Android Sometimes

Why do we have to call super in Android sometimes?

Why are we forced to call super.method()?

The classes that make up the Android SDK can be incredibly complex. For instance, both activities and fragments must perform a number of operations in order to function properly (i.e. managing life cycle, optimizing memory usage, drawing the layout to the screen, etc.). Requiring the client to make a call to the base class (often at the beginning of the method) ensures that these operations are still performed, while still providing a reasonable level of abstraction for the developer.

How do we know that a function method requires super to be called?

The documentation should tell you whether or not this is required. If it doesn't I'd Google-search for some sample code (or check the API demos... or better yet, look at the source code!). It shouldn't be too difficult to figure out.

When NOT to call super() method when overriding?

By calling the super method, you're not overriding the behavior of the method, you're extending it.

A call to super will perform any logic the class you're extending has defined for that method. Take into account that it might be important the moment when you call super's implementation in your method overriding. For instance:

public class A { 
    public void save() { 
         // Perform save logic
    }
}

public class B extends A {
    private Object b;
    @Override
    public void save() { 
        super.save(); // Performs the save logic for A
        save(b); // Perform additional save logic
    }
}

A call to B.save() will perform the save() logic for both A and B, in this particular order. If you weren't calling super.save() inside B.save(), A.save() wouldn't be called. And if you called super.save() after save(b), A.save() would be effectively performed afterwards B.save().

If you want to override super's behavior (that is, fully ignore its implementation and provide it all yourself), you shouldn't be calling super.

In the SAXParser example you provide, the implementations of DefaultHandler for those methods are just empty, so that subclasses can override them and provide a behavior for those methods. In the javadoc for this method this is also pointed out.

public void startElement (String uri, String localName,
    String qName, Attributes attributes) throws SAXException {
    // no op
}

About the super() default call in code generated by IDEs, as @barsju pointed out in his comment, in each constructor there's an implicit call to super() (even if you don't write it in your code), which means, in that context, a call to super's default constructor. The IDE just writes it down for you, but it would also get called if you removed it. Also notice that when implementing constructors, super() or any of its variants with arguments (i.e. super(x,y,z)) can only be called at the very beginning of the method.

Mandatory calling superclass methods of an Android activity?

The documentation for the lifecycle methods indicate if calling super.onXXX() is required or not. For some methods this is required, for some it is not.

For the lifecycle methods which require calling through to super.onXXX(), you can call that method at any time. It can be before or after your code.

For onSaveInstanceState() and onRestoreInstanceState(), it should also make no difference whether you call super.onXXX() before or after your code. Hopefully, the stuff that you put in the saved instance Bundle does not conflict with the stuff that the Android framework is putting in the Bundle. If it conflicts, you'll have a problem no matter whether you call the super method before or after your code.

NOTE: The Android framework uses the following keys when putting View and Dialog information in the saved instance Bundle:

 static final String FRAGMENTS_TAG = "android:fragments";
 private static final String WINDOW_HIERARCHY_TAG = "android:viewHierarchyState";
 private static final String SAVED_DIALOG_IDS_KEY = "android:savedDialogIds";
 private static final String SAVED_DIALOGS_TAG = "android:savedDialogs";
 private static final String SAVED_DIALOG_KEY_PREFIX = "android:dialog_";
 private static final String SAVED_DIALOG_ARGS_KEY_PREFIX = "android:dialog_args_";

so as long as you don't use keys with the same names, you should be good.

Calling super at end

Firstly, plain super() isn't allowed in methods at all - only in constructors. I assume you actually meant super.someMethod() for an appropriate method.

Does it perform any pre-processing when we call super() at the end , because generally we call super to initialize parent constructor .

Using super in a method is somewhat different to using it in a constructor.

In a constructor, super (or this) is required to be the very first statement (if present, with an implicit super() otherwise) and it can only call a constructor.

In a method, using super.someMethod() simply calls the superclass implementation of someMethod. You can call it from any method (you don't have to be overriding someMethod at the time) and you can call it at any point in the method. It's invoked at the point you call it, it just avoids the polymorphic call to an overriding implementation.

So basically where - and whether - you call it depends on what you want the effect to be. In some cases you may want to call the superclass implementation of the same method before your own custom behavior, and in some cases you may want to call it after your own custom behaviour.

Why call super() in a constructor?

There is an implicit call to super() with no arguments for all classes that have a parent - which is every user defined class in Java - so calling it explicitly is usually not required. However, you may use the call to super() with arguments if the parent's constructor takes parameters, and you wish to specify them. Moreover, if the parent's constructor takes parameters, and it has no default parameter-less constructor, you will need to call super() with argument(s).

An example, where the explicit call to super() gives you some extra control over the title of the frame:

class MyFrame extends JFrame
{
    public MyFrame() {
        super("My Window Title");
        ...
    }
}

Should the call to the superclass method be the first statement?

Methods you override that are part of component creation (onCreate(), onStart(), onResume(), etc.), you should chain to the superclass as the first statement, to ensure that Android has its chance to do its work before you attempt to do something that relies upon that work having been done.

Methods you override that are part of component destruction (onPause(), onStop(), onDestroy(), etc.), you should do your work first and chain to the superclass as the last thing. That way, in case Android cleans up something that your work depends upon, you will have done your work first.

Methods that return something other than void (onCreateOptionsMenu(), etc.), sometimes you chain to the superclass in the return statement, assuming that you are not specifically doing something that needs to force a particular return value.

Everything else -- such as onActivityResult() -- is up to you, on the whole. I tend to chain to the superclass as the first thing, but unless you are running into problems, chaining later should be fine.

---

Related Topics