I am just starting my experience with Android development (I am watching tutorials right now). I looked at the activity lifecycle on the Android developers page, and I realized that the activity always goes through the onResume() method before it's visible to the user. Assuming I will be using no fragments in the activity, does that mean that most of the code logic should be within the onResume() method, and I should just inflate the layout once inside the onCreate() at the beginning?
Please Refer the site for the better understanding of the activity lifecycle
https://developer.android.com/guide/components/activities/activity-lifecycle
and also this for brief understanding
https://www.javatpoint.com/android-life-cycle-of-activity
Now answering your question onCreate() is not just for inflating the layout.
The main part of the core logic is written here and onResume() is called when you minimize the or open the app once again it is called again and again but onCreate() is called once untill and unless the control is not forwarded to another activity
Like in Java the start running from
public static void main(String[] args){
}
In Android(Activity) the first line will be executed will be from onCreate() and not from the onResume()
if you will practice the same and will habitual of this process again and again then you better understand what i m trying to tell nothing can be more useful than you practice and your understanding try to print the toast or Log on each and every state of the activity lifecycle and you better understand this without the help of anyone
Cheers Happy Coding!
Related
In the sample app fetch method is called in onCreate(). Is it really a good place to do this? The application can be used (moves from foreground to background and vice-versa, opens new activities and going back to main activity) for weeks and onCreate() from the main Activity won't be called again. I don't think it is good solution where my app won't update my configs for such a long time.
Update:
It is very bad idea to fetch config values only in onCreate() method, some kind of check should be done in onStart(). Here is also some useful information: https://firebase.googleblog.com/2017/01/firebase-remote-config-loading.html
The link you shared shows example for demo purpose. Ideally you should do initialization in onCreate() and call for data in onStart() when onResume() gets called, the activity is visible and user can interact with your app.
As said by #Doug Stevenson in comment that there is no obligation, but you should follow what is given in docs for best practice.
I want my activity the recognize when it is left and a new activity is started so for example when i'll do
startActivity(intent);
It will perform a certain code.
I tried using onPause();
But it only work on leaving the activity manually
Why don't you perform the operation before calling the new startActivity() and go read about the android activity life cycle to understand how it works
EDIT::
if i truly understand what you are saying..then i think you are looking for onStop() method
Look at the Android activity lifecycle here. onPause is called when "another activity comes to the foreground". If I understand your question correctly, it seems like overriding your first activity's onPause method will work. It's called when you add a new activity on the back stack or when you send the app to the background.
For convenience, here's the chart from the link I provided that I refer to for activity lifecycle questions:
I am attempting to save keys to SharedPreferences during an onPause() event, but this is called BOTH when I leave the activity and when I return to the activity.
Therefore my values get overwritten with zero and default values when I return to the activity, and my methods in the oncreate method do not respond like I would expect them to because of this.
Perhaps I am misunderstanding the Android lifecycle, but I've seen the lifecycle graph a dozen times and my programs do not act like I would expect them to.
Insight appreciated.
From my experience some devices are completely nuts about the event lifecycle of an activity.
The only solution I found was to make the activity as independent of the lifecycle as possible. I've seen devices that when they return from onPause destroy the activity only to create a new one. You should probably check if that's not your case.
The android tests for devices seems to lack a lot in this area.
As per activity life cycle, onPause() will be called both after onResume() and just before onStop(). So anything you do in onPause() will gets execute twice. But in my experiance some devices skipping onPause() before onStop() some times. So you don't rely onPause() alone. Better to write codes on onCreate() or onResume() with proper conditions.
Please put your code here for more clarification.
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.
According to the "Application Fundamentals" article, section "component lifecycle", onResume() is always called when a View becomes active, independent of the previous state.
In the Notepad tutorial, Exercise 3, I have found something confusing in NoteEdit.java:
There is a call to populateFields() in onCreate() as well as in onResume().
Wouldn't it be enough (or even better) to have it only in onResume() ?
In such a small example, it will not do any harm if populateFields() is performed twice, but in a bigger App, things can be different ...
Thanks and Regards,
Markus N.
From a look at Notepad3, I would say you are correct. There doesn't seem to be any reason for them to call populateFields() in both onCreate() and onResume(). onResume is sufficient.
I can see where you need it in both places, if application pauses then you would need it in onResume and if your process gets killed or user navigates back to activity then you will need it in onCreate especially if you are doing some pre-processing.
Per the documentation....for onResume() they recommend using it for lightweight calls unlike in onCreate():
"The foreground lifetime of an activity happens between a call to onResume() until a corresponding call to onPause(). During this time the activity is in front of all other activities and interacting with the user. An activity can frequently go between the resumed and paused states -- for example when the device goes to sleep, when an activity result is delivered, when a new intent is delivered -- so the code in these methods should be fairly lightweight. "
The Notepad app may want a variable declared if the method was already hit by onCreate not to redo in onResume().