Unimplemented OnCreate() method does not give an error - android

package com.example.mytests;
import android.app.Activity;
public class MainActivity extends Activity {}
For the code above, even though I do not implement OnCreate() method I get no errors and program works. Should't I get an error that I should override it?

No. You will get error if you override onCreate and forget to call super.onCreate first thing.
In your case just Activity.onCreate() gets called. It can't really give an error, unless they in Google break something severily which they do not. If it gave Android wouldn't work because the same error would come from super.onCreate()

No, you don't need to override it. But if you DO override it, you MUST call super.onCreate().
The idea is that no matter what, the default implementation of onCreate() must be called, which is also the case if you do not override it at all.

onCreate is one of the Life Cycle methods of the Activity
Reason we implement the onCreate because some where we need to set the content view to the activity. For that reason we choose onCreate for setContentView() and it is the first life cycle method to be called. and if you override the onCreate dont forgot to call the super.onCreate()
why super.onCreate

You are extending class which has already defined onCreate method so overriding indicates to use your behavior.otherwise super class behavior will b used.this is same as extend thread class and not override run method.here do nothing run method will b invoked when u call start method on thread . You might be confused in implementing and extending interface or class.

Related

Overridden function working in activity but not working in fragment

Which function can be overridden in activity and which one in fragments.
As onKeyDown function overridden in fragment was not working while it was working after overriding it in the activity
Refer to the Fragment and Activity documentation. Methods that are defined as final are not overridable. If they don't have the world final then you can override them no problem.
Just make sure to also run super method, as some of them require that (you'd get exception for those that do if you don't)

which methods call before onCreate() of ContentProvider?

i want to so some changes in the application at run time . whatever the changes i want to do that must be done with in two steps. one step i performed in the attachBaseContext() method and another step i have to perform in a method that call before the onCreate() method of the ContentProvider . so
can any body tell me that which method i can override in my application class which calls before the onCreate() method of ContentProvider (other then attachBaseContext() ) .
Well, of course the constructor will be executed first.
However, if you really need a commit to android.content.Context, I recommend using attachBaseContext. Although at the moment, i have not found any documentation mentioning attachBaseContext in the lifecycle of android.app.Application. But my recent tests are that attachBaseContext is always executed before onCreate happens.
The answer is: attachBaseContext()

Would it be wrong to call System.LoadLibrary() from onCreate method of a fragment?

I am trying to use this solution inside my Fragment, however I couldn't be sure where to call System.LoadLibrary(), finally I decided to call from onCreate method of the Fragment, I want to be sure if this would not raise some another weird error on different devices.
General it won't cause weird behaviours, as onCreate is mandatory callback when your fragment created by system. This make sure your native library is prepared before you do further operation in your fragment.
Take a look at fragment life cycle, it might be better if you put your library initialize routine on the first callback onAttach, you can use the attached Activity context to initialize your native library.
It is just a static initialization. You don't even have to have it inside your onCreate() at all. You can simply initialize it as the first part of your class next to your global variables as such:
class YourClass
{
static
{
System.loadLibrary( yourLib );
}
...
}
It is only important that it is done early or you may see UnsatisfiedLinkError followed by application's crash. That way whenever a call referenced later is made, the library itself has already been loaded. A static declaration at the top will do that as soon as an instance of the class has been requested; even before onCreate().

super.onCreate(savedInstanceState);

I have created an Android Application Project and in MainActivity.java > onCreate() it is calling super.onCreate(savedInstanceState).
As a beginner, can anyone explain what is the purpose of the above line?
Every Activity you make is started through a sequence of method calls. onCreate() is the first of these calls.
Each and every one of your Activities extends android.app.Activity either directly or by subclassing another subclass of Activity.
In Java, when you inherit from a class, you can override its methods to run your own code in them. A very common example of this is the overriding of the toString() method when extending java.lang.Object.
When we override a method, we have the option of completely replacing the method in our class, or of extending the existing parent class' method. By calling super.onCreate(savedInstanceState);, you tell the Dalvik VM to run your code in addition to the existing code in the onCreate() of the parent class. If you leave out this line, then only your code is run. The existing code is ignored completely.
However, you must include this super call in your method, because if you don't then the onCreate() code in Activity is never run, and your app will run into all sorts of problem like having no Context assigned to the Activity (though you'll hit a SuperNotCalledException before you have a chance to figure out that you have no context).
In short, Android's own classes can be incredibly complex. The code in the framework classes handles stuff like UI drawing, house cleaning and maintaining the Activity and application lifecycles. super calls allow developers to run this complex code behind the scenes, while still providing a good level of abstraction for our own apps.
*Derived class onCreate(bundle) method must call superclass implementation of this method. It will throw an exception SuperNotCalledException if the "super" keyword is not used.
For inheritance in Java, to override the superclass method and also to execute the above class method, use super.methodname() in the overriding derived class method;
Android class works in the same way. By extending the Activity class which have onCreate(Bundle bundle) method in which meaningful code is written and to execute that code in the defined activity, use the super keyword with the method onCreate() like super.onCreate(bundle).
This is a code written in Activity class onCreate() method and Android Dev team might add some more meaningful code to this method later. So, in order to reflect the additions, you are supposed to call the super.onCreate() in your Activity class.
protected void onCreate(Bundle savedInstanceState) {
mVisibleFromClient = mWindow.getWindowStyle().getBoolean(
com.android.internal.R.styleable.Window_windowNoDisplay, true);
mCalled = true;
}
boolean mVisibleFromClient = true;
/**
* Controls whether this activity main window is visible. This is intended
* only for the special case of an activity that is not going to show a
* UI itself, but can't just finish prior to onResume() because it needs
* to wait for a service binding or such. Setting this to false prevents the UI from being shown during that time.
*
* <p>The default value for this is taken from the
* {#link android.R.attr#windowNoDisplay} attribute of the activity's theme.
*/
It also maintains the variable mCalled which means you have called the super.onCreate(savedBundleInstance) in your Activity.
final void performStart() {
mCalled = false;
mInstrumentation.callActivityOnStart(this);
if (!mCalled) {
throw new SuperNotCalledException(
"Activity " + mComponent.toShortString() +
" did not call through to super.onStart()");
}
}
See source code here.
http://grepcode.com/file/repository.grepcode.com/java/ext/com.google.android/android/1.5_r4/android/app/Activity.java#Activity.onCreate%28android.os.Bundle%29
Because upon super.onCreate() it will reach the Activity (parent class of any activity) class to load the savedInstanceState,and we normaly don't set any saved instance state, but
android framework made such a way that, we should be calling that.
It is information you want returned to your application, via onCreate(),
if the activity is destroyed and restarted due to some implicit reason
(e.g., not because the user pressed the back button). The most common
use of onSaveInstanceState() is to handle screen rotations, as by
default, activities are destroyed and recreated when the user slides out
the G1 keyboard.
The reason to call super.onCreate(savedInstanceState) is because your
code will not compile otherwise. ;-)

Do I need to call through super class onCreate and onDestroy methods within an IntentService?

I've derived a class from IntentService and I'm wondering if it is necessary to call through the super class onCreate and onDestroy methods when overriding these methods in my implementation as it happens when you override such methods in an Activity.. If it is necessary, do these invocation need to be the first thing we do in the overriding method? In the Activity documentation they are very clear about that, while in the ServiceĀ or IntentService docs I can't find anything specific.
I'm wondering if it is necessary to call through the super class onCreate and onDestroy methods when overriding these methods in my implementation as it happens when you override such methods in an Activity.
Absolutely. Those methods are implemented on IntentService; if you fail to call through to them, your service simply will not work.
If it is necessary, do these invocation need to be the first thing we do in the overriding method?
I would recommend calling super.onCreate() as the first thing that you do in your implementation of onCreate(), and calling super.onDestroy() as the last thing that you do in your implementation of onDestroy().

Categories

Resources