I´ve just realised that android has another method called onActivityReenter.
What is this for? can it be used like onActivityResult?
Documentation says that is used for transitions, but not 100% what for.
according to the doc
The purpose of this function is to let the called Activity send a hint about its state so that this underlying Activity can prepare to be exposed. A call to this method does not guarantee that the called Activity has or will be exiting soon. It only indicates that it will expose this Activity's Window and it has some data to pass to prepare it.
so you can get data from the other activity even when it is still running. but for the onActivityResult we get the data when the activity is finished.
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.
Is there a method of the Activity lifecycle that is guaranteed to get called when my app crashes?
I put logs in all methods and crashed my app but I didn't see anything.
I couldn't find anything in the docs too.
I basically want to save changes in a database but ideally I do not want to do it in every update but rather in a method like onPause or onStop etc.
None of the lifecycle methods will be called if your Activity crashes.
However, for child activities started using startActivityForResult you do get a RESULT_CANCELED code returned in onActivityResult on the parent Activity.
My Problem: Is it possible to prevent an activity to call OnResume() when it is being created? As I saw after the OnCreate() and onStart() method runs, the next one is the onResume(), although I only want to have it when I resume the activity from the paused state.
Why do I need this: I launch my activity (FragmentActivity, so lets say OnPostResume() ) starting with a thread which takes about 2-3s to be ready getting data from an external database. After the thread is done, I call a method which needs these data and I want to call it everytime that activity gets visible. The thread runs only when the FragmentActivity is created (onCreate()), and I cannot put the method into the onResume() because onResume() would be running way before the thread would finish its task. So it would receive not-ready data.
Anyone has a better idea?
Not sure of the exact application of this but I'll make a suggestion.
If you use an AsyncTask, you can send it off to get the data you need and in the onPostExcecute() method you can call your method that requires the data or update the view as needed. (It runs on the UI thread)
If you happen to already have the data you need in certain scenarios you could also bypass the AsyncTask and directly update the view.
This AsyncTask can be triggered in the onResume() method.
If I'm missing something, please let me know and I can adjust my suggestion.
I didn't understand the purpose of this, but here's a possible solution:
If you only wish to get the even of onResume on states that didn't have the onCreate before, just use a flag.
In the onCreate, set it to true, in the onResume check the flag (and also set it to false). if it was true, it means the onCreate was called before.
I personally would prefer to check if the result available, rather than always executing the getter-code in onResume. If the user somehow resumes your activity before the background thread is finished, you'd have a call on onResume, but don't want to display a result.
Maybe it would be a good idea to calculate/fetch the values in the thread, and let the thread return immediately (and cause the values to get filled in) if the values are already cached somewhere. That way you'd only have one entry point (the thread) for updating your UI instead of two (the thread and the onResume method).
In Activity lifecycle the onActivityResult method is called before the onCreate methode, where all my buttons etc. are initialized.
How is it possible to access them though? Thx for some background knowledge!
The only way to an onActivityResult event should happen is if you used startActivityForResult to create the new activity that generates that event.
Which means your calling activity should be in the stack and already created but just paused so your onCreate was already called.
Unless there is an orientation change in between which I have never tried and poses an interesting question.
Are you having an issue or just trying to understand the mechanism? If you are having and issue post some code.
I know Android's Activity model is a bit different from what I usually consider to be an "app".
I want to do something (in this case, check some notifications on a server and show them if available) when my app is "launched". What is a good way to accomplish this?
I likely don't want to do it in an activity's OnCreate, since each activity can be created any number of times - the code would get called more often than necessary.
The app also has multiple entry points - would I have to duplicate the check in each activity?
What I'm thinking of doing is setting up this code inside the Application object, along with a flag that tracks whether it's already been called - and just call it from each Activity's onCreate().
Is there a better or more "proper" way to do this?
The right, Android-approved way to do this is:
Create your own android.app.Application class
Override the onCreate method
In the AndroidManifest.xml, change the android:name attribute of the application element to the name of your class
Now, whenever your app is "started" (any one of your activites is started for the first time and no other instances are alive) onCreate will be called.
You may also find the onTerminate method useful.
Can you just check if the bundle passed to onCreate() is null?
It's not null "If the activity is being re-initialized after previously being shut down..."
There's probably no harm in putting it in onCreate; the Activity is really only destroyed when the OS needs the RAM for something else, not when the user goes to another app.
EDIT: You can also have a Service that runs when the device gets booted up, too. This might be a better option if you also want to check when the app starts, since you'll only have to call context.startService from the Activity to run the check. Just be sure to stop it when it's done if you don't need it to be persistent.