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.
Related
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!
I am preparing new version of one of my apps, and I made such huge changes in my app, that I need to do some data conversion exactly after update of app as absolutely first thing (before doing anything else). I figured out, that best place to do it would be in my class (which extends Application) in onCreate() method. I tested it few times, and it seems to work ok, but then I read documentation:
Base class for those who need to maintain global application state.
You can provide your own implementation by specifying its name in
your AndroidManifest.xml's tag, [b]which will cause
that class to be instantiated for you when the process for your
application/package is created[/b].
It looks like I am right, but I am not quite sure. Can you confirm/disprove it?
The Application constructor will be called first. Then the Application::onCreate() method will be called. The only exception I know of is if the Application contains a ContentProvider, it can receive calls before the Application does.
This is from here: http://developer.android.com/reference/android/app/Application.html#onCreate()
public void onCreate ()
Added in API level 1 Called when the application is starting, before
any activity, service, or receiver objects (excluding content
providers) have been created. Implementations should be as quick as
possible (for example using lazy initialization of state) since the
time spent in this function directly impacts the performance of
starting the first activity, service, or receiver in a process. If you
override this method, be sure to call super.onCreate().
Yes, that is right. You should do all your initial app configuration in the onCreate() method of the Application.
Besides if you use sqllite you can make migration in onUpgrade method of the SQLiteOpenHelper.
http://developer.android.com/reference/android/database/sqlite/SQLiteOpenHelper.html
I have not tested it, and maybe there are some more relevant options out there, but for the upgrade the following looks promising: SQLiteOpenHelper.onUpgrade( SQLiteDatabase db, int oldVersion, int newVersion ).
So you can hang your update routines on that. The method you override should fire only when the database upgrade is needed.
Yes. The application onCreate method is the first method that is called when the process is started. you can put your code there without any problems.
here the documentation http://developer.android.com/reference/android/app/Application.html#onCreate()
Called when the application is starting, before any activity, service, or receiver objects (excluding content providers) have been created. Implementations should be as quick as possible since the time spent in this function directly impacts the performance of starting the first activity...
be careful to make all the changes very quickly and be sure that you call the "upgrade" method only once.
Consider also the possibility to put this method in an AsyncTask, if its possible.
No it dosent..say you have activity A(launcher activity) and B...when you launch your app ...A loads starting from onCreate()...and say u started activity B, then it launches B and its onCreate method is executed..but now if you navigate back to A..it will call th onResume activity and not the onCreate..
I'm learning about android programming from official website(http://developer.android.com).
I understand most of life cycle, but I'm not sure when system is destroying activity.
From what I understand, system is destroying activity when some activity stays for longer time in onStop() or when foreground activity needs more resources. Is that right ?
And from what I read the most efficient way to update data base is in onStop(), but let's say user is adding one word to my 'dictionary' application. So I need to gather this words in list and then update data base? Or I should insert rows to DB with each word ( in other method ) ?
As i understand you will never know when android force your application to stop.
So it is like this
onCreate() // here you could initialize
This is safe
onResume() // here turn on
onPause() // here turn off
// After this it is not sure
But if you are sure that finish() is always called you could use others
Data has to be persisted in the onPause()method. Otherwise, the system might terminate your process without further notice.
Should you get data via a cursor and fill in the data on the screen, such as setting the window title, in onStart() or onResume()?
onStart() would seem the logical place because after onStart() the Activity can already be displayed, albeit in the background. Notably I was having a problem with a managed dialog that made me rethink this. If the user rotates the screen while the dialog is still open, onCreateDialog() and onPrepareDialog() are called between onStart() and onResume(). If the dialog needs to be based on the data you need to have the data before onResume().
If I'm correct about onStart() then why does the Notepad example give a bad example by doing it in onResume()? See http://developer.android.com/resources/samples/NotePad/src/com/example/android/notepad/NoteEditor.html NoteEditor.java line 176 (title = mCursor.getString...).
Also, what if my Activity launches another Actvity/Dialog that changes the data my cursor is tracking. Even in the simplest case, does that mean that I have to manually update my previous screen (a listener for a dialog in the main activity), or alternatively that I have to register a ContentObserver, since I'm no longer updating the data in onResume() (though I could update it twice of course)?
I know it's a basic question but the dialog only recently, to my surprise, made me realize this.
Again the solution depends on what suits you.
If you want the cursor to be pre-populated once per application (and not bothered about any change, then you can do it in onCreate(). This method will be recalled only if the app process is killed and app is reinitiated.
If you want the cursor to be prepopulated everytime the visible lifetime starts (most cases a service/broadcast is calling your activity, you should use onStart()
If you want the cursor to be prepopulated for every foreground lifecyle of activity, you should use onResume(). So if you have a dialog box or another subactivity modifying some information and hence you want to reload the cursor, it is best you do so in onResume(). The downside for this method is everytime the activity comes in foreground the cursor is reloaded.
Hope this makes it clear
To answer your question about NoteEditor, simply take a look at the lines above the one you cite and you'll see...
// Requery in case something changed while paused (such as the title)
mCursor.requery();
The comment seems to explain it all. Although I haven't gone through the NotePad example myself, it appears the author(s) are building in the ability to recover from changes whilst the NoteEditor is paused (and then resumed).
As GSree explains (whilst I was typing this), there isn't a right or wrong answer and it simply depends on what needs to be done at which point of the Activity life-cycle.
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().