Develop Reference

onDestroy method is not calling in android o version

I want to call method in ondestroy override method but that override method is not calling android o only. Why it is not calling is there any alternative for that please any one help me to resolve my issue.Thanks in advance.

Given your comment that you are overriding onDestroy() in the activity and killing your app manually:
Please be aware that there it's not guaranteed that the onDestroy() will be called properly. Because of that, you should not perform critical actions there.
See an excerpt from the Documentation:
Note: do not count on this method being called as a place for saving data! For example, if an activity is editing data in a content provider, those edits should be committed in either onPause() or onSaveInstanceState(Bundle), not here. This method is usually implemented to free resources like threads that are associated with an activity, so that a destroyed activity does not leave such things around while the rest of its application is still running. There are situations where the system will simply kill the activity's hosting process without calling this method (or any others) in it, so it should not be used to do things that are intended to remain around after the process goes away.

Need to work in android o, Could you send your codes?
public void onDestroy() {
...
// Must always call the super method at the end.
super.onDestroy();
}

Android application: modifying firebase database before app destroyed

I am trying to modify my firebase database when my app is destroyed, that means when I remove the app from the list of recent running app or when I click on Home button ,but I don't know how to do this, I tried to do that in onDestroy() method of every activity but it doesn't work.
This is my onDestroy() method :
#Override
protected void onDestroy() {
super.onDestroy();
FirebaseDatabase.getInstance().getReference().child("users").child(encodeEmail(mAuth.getCurrentUser().getEmail())).child("status")
.setValue("destroyed") ;
/*Toast.makeText(ContactsActivity.this,"closing app",Toast.LENGTH_LONG).show();
MyApp app = (MyApp)getApplication() ;
app.setUpBeforeClosing();*/
}

On Destroy Documentation
Do not count on this method being called as a place for saving data! For example, if an activity is editing data in a content provider, those edits should be committed in either onPause() or onSaveInstanceState(Bundle), not here. This method is usually implemented to free resources like threads that are associated with an activity, so that a destroyed activity does not leave such things around while the rest of its application is still running. There are situations where the system will simply kill the activity's hosting process without calling this method (or any others) in it, so it should not be used to do things that are intended to remain around after the process goes away.
Either use OnPause or Use a service to write data.
Add this in manifest
<service
android:name="com.myapp.MyService"
android:stopWithTask="false" />
Now in your MyService service, override method onTaskRemoved. (This will be fired only if stopWithTask is set to false).
public void onTaskRemoved(Intent rootIntent) {
//save data to firebase
//stop service
stopSelf();
}
reference

Do you have BaseActivity or not ?
I think you just forgot to add this line in the right activity.
I suggest you to create BaseAvtivity.java class and extend all your activities from it, and the BaseActivity would extends AppCompatActivity and then override tbe lifecycle methods in BaseActivity and set new value in onDestroy method.

Activity life cycle methods : onPostResume significance

Official documentation about Activity lists out 7 life cycle methods.
onPostResume() was not quoted as life cycle method.
But I feel that this method is important method.
During the life cycle, when an activity is visible from hidden to show state,
onRestart()
onStart()
onResume()
onPostResume()
have been invoked in order.
My code snippet:
package ravindra.projects.my_app_1;
import android.content.Intent;
import android.content.IntentFilter;
import android.os.PersistableBundle;
import android.support.v7.app.AppCompatActivity;
import android.os.Bundle;
import android.util.Log;
import android.view.View;
import android.widget.Button;
import android.widget.EditText;
import android.widget.TextView;
public class MainActivity extends AppCompatActivity implements View.OnClickListener{
private EditText txtUserName;
private EditText txtPassword;
Button loginButton;
#Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
Log.d("Ravi","Main OnCreate");
txtUserName=(EditText) findViewById(R.id.username);
txtPassword=(EditText) findViewById(R.id.password);
loginButton = (Button) findViewById(R.id.login);
loginButton.setOnClickListener(this);
}
#Override
public void onClick(View view) {
Log.d("Ravi", "Login processing initiated");
Intent intent = new Intent(this,LoginActivity.class);
Bundle bundle = new Bundle();
bundle.putString("userName",txtUserName.getText().toString());
bundle.putString("password",txtPassword.getText().toString());
intent.putExtras(bundle);
startActivityForResult(intent,1);
// IntentFilter
}
public void onActivityResult(int requestCode, int resultCode, Intent resIntent){
Log.d("Ravi back result:", "start");
String result = resIntent.getStringExtra("result");
Log.d("Ravi back result:", result);
TextView txtView = (TextView)findViewById(R.id.txtView);
txtView.setText(result);
}
#Override
protected void onStart() {
super.onStart();
Log.d("Ravi","Main Start");
}
#Override
protected void onRestart() {
super.onRestart();
Log.d("Ravi","Main ReStart");
}
#Override
protected void onPause() {
super.onPause();
Log.d("Ravi","Main Pause");
}
#Override
protected void onResume() {
super.onResume();
Log.d("Ravi","Main Resume");
}
#Override
protected void onStop() {
super.onStop();
Log.d("Ravi","Main Stop");
}
#Override
protected void onDestroy() {
super.onDestroy();
Log.d("Ravi","Main OnDestroy");
}
#Override
protected void onPostResume() {
super.onPostResume();
Log.d("Ravi","Main PostResume");
}
#Override
public void onSaveInstanceState(Bundle outState, PersistableBundle outPersistentState) {
super.onSaveInstanceState(outState, outPersistentState);
}
#Override
protected void onRestoreInstanceState(Bundle savedInstanceState) {
super.onRestoreInstanceState(savedInstanceState);
}
}
Implementing onPostResume() by skipping below methods doesn't serve the purpose?
onRestart(), onStart(), onResume()
What are the advantages of implementing these three methods if I implement onPostResume() ?
onRestart(), onStart(), onResume()

onPostResume :
Called when activity resume is complete (after activity's {#link #onResume} has
been called). Applications will generally not implement this method;
it is intended for system classes to do final setup after application
resume code has run.
It will do following things
It will ensure that screen is visible to user and will do the final
set up for activity.
Remove any pending posts of messages with code 'what' that are in
the
message queue.
Check all fragment gets resumed and Moves all Fragments managed by
the controller's FragmentManager into the resume state.
Execute any pending actions for the Fragments managed by the
controller's FragmentManager.
If you check it life cycle vise it worked like below
onResume() - Activity
onResume() - Fragment check third point as explained above
onPostResume() - Activity

onPostResume is mainly reserved for system actions which want to finish some kind of setup after any subclasses have finished resuming.
The two things it is good for, (which might make you feel it's important) are for doing actions after your nested fragments are also resumed and when the applications is guaranteed to be visible to the user (it may not yet be visible during onResume).
It can be a little confusing from the method names when looking at the Sources, but if you log the flow you'll see what happens is
Activity Resumes
Fragment Resumes
onPostResume is called in Activity
I will add a word of caution for any future readers - if you use onPostResume to wait for your fragment, to call some get method (for example), then you have a bad, unreliable design. You should instead have a callback pattern from your fragment and have the fragment "send" the data back to the activity when it is ready

Before answering your question lets talk about onPostResume()
According to android
onPostResume()
added in API level 1
void onPostResume ()
Called when activity resume is complete (after onResume() has been called). Applications will generally not implement this method; it is intended for system classes to do final setup after application resume code has run.
So as they said it is called once the activity is resumed. So if you want to do something after an activity is resumed you can use this method. But mostly we do all the stuff in onResume() like begin animations, open exclusive-access devices (such as the camera), etc. so once Activity is resumed onPostResumed() get called. So don't you think it differs from on resume? Because in onPostResume() according to os activity is already resumed.And for the onPause and onStop().They are different. They are when an activity is going into the background but has not (yet) been killed and Called when you are no longer visible to the user respectively. So they are different from onResume() and onPostResume().
Now before relying on onPostResume() you should read these two things
As far as developers.android
1 - Applications will generally not implement this method; it is intended for system classes to do final setup after application resume code has run.
(But we can use it for our purpose no matter what the intent of this).
2 - Check this link . He said that onPostResume() is not ALWAYS called . And his case was for fragments ( Of course they are over an activity man ).
Here is the reply,
The issue is completely resolved in API level 16 and support library rev 9.
New method "FragmentActivity.onResumeFragments()" should be used.
So some of them having issues in relying on this method so it's up to you know.

onPostResume() was not quoted as life cycle method.
But I feel that this method is important method.
Most probably your feelings are wrong. And my answer on why it is so is a bit long and kind of abstract.
Abstract (but important) part
Typically various onPreXyz and onPostXyz (aka onBeforeXyz and onAfterXyz) methods are an attempt to make a base class open to extension by subclasses but still preserving some important behavior aspects. Assume that you are designing you own base class and you have a lifecycle event "Xyz" and your default handling behavior is following:
Do some initialization before any other handling
Do actual handling of event including customizable logic
When all customizable handling is done do some finishing logic
Now assume that you are making something like Activity class - a base class with some bits of logic and the one that would be heavily inherited from, probably with deep hierarchies of inheritance. Now you should think of where (when) sub-classes logic will be exectuted regarding to logic in your base class. The important tricky part here is that you want your sub-classes to put their additional logic around step #2 (i.e. after #1 and before #3). You can't easily achieve this goal with simple virtual method because subclass can either put their logic after call to super which is after #3 or (rarely) before super call i.e. before #1. So what would you do? The Template method pattern comes to the rescue. You orgainze you code in a following way
class Activity {
public final void performXyz(XyzEventData eventData) {
onPreXyz(eventData);
onXyz(eventData);
onPostXyz(eventData);
}
protected void onPreXyz(XyzEventData eventData) {
// put you logic from step #1 here
}
protected void onXyz(XyzEventData eventData) {
// put you logic from step #2 here
}
protected void onPostXyz(XyzEventData eventData) {
// put you logic from step #3 here
}
}
So you have single external entry point performXyz that is called by the whatever context generates lifecycle events when the Xyz event happens and it dispatches the event internally to 3 different methods enforcing some sequence of execution. Typically you put all your code in your subclasses inside the "main" onXyz method unless you have a good reason to put it in one of the two others i.e. you expect your class to be subclassed as well and you want to ensure some execution order.
There are a few more points worth noting:
Entry-point method performXyz is final (i.e. non-virtual). In this way you ensure that nobody can override it and break your execution order enforcement logic.
The base class might even leave onPreXyz and onPostXyz
methods empty by putting its steps #1 and #3 logic directly into performXyz. But if the designer of the base class expects possible deep inheritance hierarchies where some intermediate sub-class, that will be a base class for many other deeper subclasses (such as Layer supertype), might need the same execution order enforcement feature, it makes sense to provide such methods in the base class anyway.
One of the onPreXyz or onPostXyz method might be
omitted altogether if your case doesn't require 3-steps execution
separation and 2-steps are enough. This is what often happens in Android: there are much more onPostXyz methods than onPreXyz but AsyncTask seems to be one noticible exception that feature both of them.
Closer look at Android (and onPostResume)
So after this long introduction, how Android uses this approach for onPostResume? If you look at the code at Activity.onPostResume you'll notice that it does very few things in the base class and the ones that are tightly related to UI stuff and probably expect all data-structures to be fully ready. This of course is not very surprising.
What is more interesting is how it is used in the subclasses. One of the very few overrides is at FragmentActivity from the v4 support library which provides backported "Fragments" features for old devices. FragmentActivity.onPostResume contains logic to resume child fragments. You may notice that in the standard Activity class similar logic to resume fragments is put directly into performResume method between mInstrumentation.callActivityOnResume(this); and onPostResume(); calls so it seems to be a part of step #3 in my earlier abstract description just put into the caller code. Obviously FragmentActivity can't put any new code to the Activity.performResume to ensure that it will be executed after activity's resume is done. Thus it puts the logic to the overridden FragmentActivity.onPostResume and in this way preserves the same semantics that fragments should be resumed after activity has already been resumed. Note also that the fact that this semantics explicitly preserved in both Activity and FragmentActivity classes suggests that this is the way it better should be. So if your code actually uses fragments, you'd better not put extensive logic into your onPostResume or something bad might happen (not sure what exactly).

After using log and overriding methods of activity lifecycle I came to following conclusion:
This method can be very help ful in case you want to do execute any particular task in parent activity efter resuming a fragment (after loading a fragment) ....
I used/tried following code snippets to get to this conclusion :
in Parent activity :
//postResumemethod
#Override
protected void onPostResume() {
super.onPostResume();
Log.v("testPostResume","reached_postResume") ;
}
In called Fragment :
//On ResumeMethod
#Override
public void onResume() {
super.onResume();
Log.v("testStartFragment","reached_Startfragment") ;
}
This is my Log :
V/testStartFragment: reached_Startfragment
V/testPostResume: reached_postResume
We can clearly see the post resume is called after the onResume method of Fragment is executed . So after calling/loading fragment if you want to execute any code in activity(any task through acivity after loading fragment ) you can do that
I hope this clarifies the query

Can android activity be designed without having to override all kinds of lifecycle methods?

When I write my activities on android, I have to override a lot of "lifecycle" methods, such as onCreate, onActivityResult:
class MyAcitivity extends Activity {
#Override
public void onCreate(...) {}
#Override
public void onStart(...) {}
#Override
public void onActivityResult(...) {}
#Overide
public void onBackPressed(...) {}
}
I don't like this, because I found my logical code are split to everywhere in my class. I do some operation in this method, but I have to handle the result in another method.
Is it the only way to design Activity like this? Is there any other solution can let me do the same without overriding methods from super classes?
Update
I do some operation in this method, but I have to handle the result in another method.
For example:
public void onCreate(...) {
startActivityForResult(new Intent(this, AnotherAcitity.class), INTENT_ANOTHER);
}
public void onActivityResult(...) {
if(requestCode == INTENT_ANOTHER) {
// do something
}
}
Update again
I know how to use these lifecycle methods, what I'm thinking is the "design". Is there any different way to design android (in theory) without "overriding lifecycle methods" to write activities. Does ios and win8 on mobiles use the same design as android? If I develop an ios or win8 application, do I have to override all kinds of lifecycle methods as I do on android?

You only need to override the methods you're using in your Activity. So if your activity simple displays a help page that has already been populated in the XML, you only have to override onCreate() and call setContentView().
In general, if your overriden method is like:
public void myOverridenMethod() {
super.myOverridenMethod();
}
That is to say, it contains nothing but a super call, you need not override it.
In the example you provided, you must override the appropriate lifecycle methods as the calling of these is beyond your control, unless you're willing to develop a custom ROM for your device(s).
EDIT
The Android lifecycle methods are called by the system at specific predefined points in your app's life.
You cannot design an Activity in a different way, as if you do Android has no idea which method does what. However, it knows exactly when to call which method in the Android lifecycle. By using your own methods instead of these, you have an app which Android cannot interact with.
Additionally, many lifecycle methods like onCreate() etc. help setup the initial bits of your app (like getting it a Context).
iOS and Windows Phone and BlackBerry have similar lifecycle methods, but they don't always have an exact Android equivalent, as all are different platforms and handle their apps differently.

This is just a generic framework pattern, framework doesn't depend on you, just notifies you, all your actions are optional for framework. It's called Inversion of Control.
This is just opposite to the direct style of programming where you decide everything about the Application, and give commands to framework.
Google developers designed Activity class, and Android only works through them. Android calls these methods whenever it pleases. Android does not care what you do in those methods, it just cares to notify you of the life cycle events.
Since everything is optional, you just have to fill in the places you are really interested in. An empty Activity runs just fine.
public class MyActivity extends Activity { }
If anything additional needs to be done, just add the code at correct place:
public class MyActivity extends Activity {
#Override
public void onCreate(...) {
//---whatever you want to do in this stage of life cycle----
}
}

You dont necessarily need to override all methods of life cycle of an activty. They all are for a specified purpose
onCreate() :
Called when the activity is first created. This is where you should do
all of your normal static set up: create views, bind data to lists,
etc. This method also provides you with a Bundle containing the
activity's previously frozen state, if there was one. Always followed
by onStart().
onRestart() :
Called after your activity has been stopped, prior to it being started
again. Always followed by onStart()
onStart() :
Called when the activity is becoming visible to the user. Followed by
onResume() if the activity comes to the foreground, or onStop() if it
becomes hidden.
onResume() :
Called when the activity will start interacting with the user. At this
point your activity is at the top of the activity stack, with user
input going to it. Always followed by onPause().
onPause ():
Called as part of the activity lifecycle when an activity is going
into the background,
but has not (yet) been killed. The counterpart to onResume().
When activity B is launched in front of activity A, this callback will be invoked on A.
B will not be created until A's onPause() returns, so be sure to not
do anything lengthy here.
onStop():
Called when you are no longer visible to the user. You will next
receive either onRestart(), onDestroy(), or nothing, depending on
later user activity.
Note that this method may never be called, in low memory situations
where the system does not have enough memory to keep your activity's
process running after its onPause() method is called.
onDestroy() :
The final call you receive before your activity is destroyed. This
can happen either because the activity is finishing (someone called
finish() on it, or because the system is temporarily destroying this
instance of the activity to save space. You can distinguish between
these two scenarios with the isFinishing() method.

Activity life cycle confusion

The life cycle of an activity is documented in many places but I couldn't find the thing I need. This is my activity, it have a constructor and the onCreate method. In my project I have also a logging in this methods and every time when I go from portrait to landscape I see that both methods are executed. Why my the constructor is called ? isn't the activity in the stack and the instance of my activity is in the memory so when the configuration change is happen, then only the oncreate and on retainistancestate should happen (of course the onResume). Why the constructor is called every time, who is calling ? Is it every time when something get changed from the configuration both methods are guaranteed to be called (one after another, in this same sequence).
public TestActivity()
{
super(R.menu.main_menu, tag);
}
public void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
}
I was playing with my sample app but I want to know more details, can someone clarify me the scenario when the constructor is included ?, I founded a a lot of documentation about life-cycle but none explains the details when the constructor is included
Edit1:
I read in some places that there is stack in witch the activities are putted in so the next time they go up and running faster, but what when the configuration get changed ? Is it must to to call the constructor and the oncreate methods ?

On rotation your activity will be restarted complete. You can prevent that with android:configChanges="keyboardHidden| orientation" in your manifest.

As #rekire answered, the activity is restarted on screen rotation. Here restart means that the framework creates another instance of the activity, that's why the constructor of your activity class is called and then the onCreate(). The new activity instance replaces the old one which will be finally recycled by GC, if its reference isn't held by others.
If you want to avoid activity restart on screen rotation, please read this question.
I've drawn an UML diagram to describe the Android activity life cycle.

Hence there are no reason having constructor to invoke activity unless you have constructor with params(onCreate invoke it for us anyway...). However basically it seems like a java thing onCreate probably calling activties's default constructor which is
public ActivityName(){} // This might get call because onCreate somewhere under the hood invoking Activity :)
Try same thing with constructor with param like
public ActivityName(String s){}// This wouldn't be call unless you explicitly call it.
Hope this will help,
I would wait for more expert answer though :)
Edit : So when you rotate your phone which calls onCreate as it will get created again and onCreate probably calls default constructor to invoke instance of your activity :)... I forgot to mention this earlier.