I found a really strange behavior in the Fragment lifecycle.
After several tests on one Fragment, I realized than I got this execution order every time:
onCreateView()
onStart()
onCreateOptionsMenu()
I am really surprised because I was convinced that onStart would only be called after the execution of onCreateOptionsMenu.
FYI, I was trying to set a MenuItem as a global class variable in onCreateOptionsMenu to be able to use it in onStart. Of course I got a null pointer because of the execution order explained above.
It seems the more I dig into the Fragment's lifecycle, the more I am lost and the documentation only details the main methods, never the ones such as onCreateOptionsMenu, onPrepareOptionsMenu, onCreateContextMenu etc.
Does someone has any additional information about this, the documentation is not really helpful...
Thank you
Check this out https://github.com/xxv/android-lifecycle. There you can see a full lifecycle for both fragment and activity.
Related
Like many others, I'm struggling with this error:
java.lang.IllegalStateException: Fragment xyz not attached to Activity
This question offers some ideas on how to deal with this. There are no explanations to the question however, why does a Fragment detach from their Activity in the first place? Does an understanding of why this happens help me to design my app in a way to avoid this happening?
In may case I do not have some asynchronous task and call getResources() when it completes; I call getResources() in the onCreate() method of the Fragment. And sometimes, when I'm navigating my app rather fast, said error surfaces. Is it to be expected that the Fragment is not even necessarily attached to its Activity during its own onCreate() method?
Secondly, the solutions provided in the linked question (guarding getResources() with isAdded() and getActivity() != null) don't help me. There is no reasonable way to deal with getResources() not being available.
Because Android supposes that Activities may be destroyed and recreated to accommodate configuration changes. Fragments, in contrast, are not.
Is it to be expected that the Fragment is not even necessarily attached to its Activity during its own onCreate() method?
Yes, it is "expected." Bad design IMO, but expected.
Android activity and fragment lifecycles have many stages (onCreate(), onStart(), onResume(), onPause(), onStop(), onDestroy(), etc). I have been coding in Android Studio for a few months now and there're many times where I haven't used all of lifecycle methods.
My question is that do you need to use all of the lifecycle methods of a fragment or an activity to write a good code? Will it cause crashes otherwise?
Nope. You can override those methods to add more functionality to your app but those methods already have their own function and will run whether you override it or not.
You could read more on the Android Activity Life Cycle: http://developer.android.com/reference/android/app/Activity.html#ActivityLifecycle
You could see this post as well: Android activity life cycle - what are all these methods for?
No, You dont need to write all the lifecycle. But you should have the idea of what lifecycle is going on and what will be the behaviour of Android app. Like why you have to attach activity context to fragment context in onAttach() life cycle method.
What lifecycle will be perform on dialog open or moving from one activity to another??
Read here more.
https://developer.android.com/reference/android/app/Activity.html
Not all, only methods you thing is essential for your task. see docs on Activity's lifecycle: https://developer.android.com/reference/android/app/Activity.html
I've been searching for this for a while now and haven't found any solution so far,
so I have a sliding menu, and withing it I call getActivity(), so far so good, but when I get out of the app (home button) and come back in a few minutes, the getActivity() returns nullpointerexception
if anyone has a clue about this it would be much appreciated
thanks
You have to be careful about exactly when you call getActivity(). It will return null in any call triggered by the parent activity's lifecycle all the way through onResume(). You have to make sure it is already attached to the parent activity before you can safely call it. Take a look at
http://developer.android.com/reference/android/support/v4/app/FragmentActivity.html#onResumeFragments()
Perhaps it will help you resolve your problem.
Depending on what you're trying to do, I would look into saving a pointer to the activity in the fragment so it can be referenced at times when getActivity might be null. That said, this could be kinda dangerous so be careful if that is the route you choose to take
Situation
My activity waits on an Async operation and after it hears back from async operation, it needs to pass information to 2 fragments inside it.
Requirement
1. Both fragments need their onCreateView calls to be done for them to have their layouts loaded,
2. They need for themselves to be attached to their activity so that getActivity() works.
I wrote a setData() method in both the fragments and am looking for the "correct" place in the activity's lifecycle to invoke them.
onCreate() of the activity does not work, onStart() of the activity does not work and onStart() of the fragment does not work.
Nothing works, what am I missing here?
The official documentation for the Fragment lifecycle explains this clearly - please refer to it and then ask follow-up questions if something is unclear.
This Image will be helpful to understand both life cycles together.
As many people complaints and it is somewhat valid argument that this life cycle is too complicated, in Google I/O 2018,They have suggested to use Architecture component Framework. Please check this Docs
when you are at Activity2---->backpress--->Fragment2(Activity1)---means Activity1 again attach from fragment2 so on OnAactivityCreated() method Activity1 is completely loaded ....so at that we can call setData() method of your Activity1...
onAttachFragment()-activity is called before onCreate()-activity and after onAttach()-fragment
Call onDestroy on onStop of your fragment. This should call onCreate when the fragment is launched.
Let me know if works as an ideal solution for your problem.
I'm attempting to save a ListFragment subclass across an orientation change so I added setRetainInstance(true) to the end of my onCreate function. I added an onSaveInstanceState method to add all of it's data to a bundle, then added code into onActivityCreated to load that data back. Unfortunately, it wouldn't work.
When I added some debugging messages with the help of Log.d I discovered that not only was onSaveInstanceState not being called, but onCreate was (which the documentation seems to say shouldn't happen when retainInstance is true). Neither onCreate nor onActivityCreated have bundles with my data (unsuprisingly).
I'm guessing this may be a problem with compatibility library, though I don't have an android 3.0+ device to test this.
Any help is appreciated and I can post some code snippets if necessary, though I'm not doing anything complicated.
Update: onDestroy is not being called when I change orientation (which is how it should be), so it seems that some of setRetainInstance is working
I finally figured out what my problem was. It all came down to a single line I'd forgot to add. In my FragmentActivity subclass I'd overrode onSaveInstanceState, but I never called super.onSaveInstanceState. Apparently, unlike other methods whose parents I'd forgotten to call, onSaveInstanceState won't throw a runtime error when I forget to call the parent classes version of it, instead setRetainInstance just stops working. I hope this saves someone the headache I went through trying to solve this.
It seems, when you set setRetainInstance = true while both onSaveInstanceState() and onActivityCreated() are called, then Bundle will not be returned.
However, as the as the ListFragment is being retained, you can simply store its state into a field, and handle it inside onActivityCreated().
Bear in mind, the Activity will still be destroyed and recreated.