Currently (Android API 17), the only mention of super in the Android Reference on Fragment is casually via some code examples (unlike the Android Reference on Activity, which carefully notes where super is required).
SO suggests searching the web as needed, or waiting for a crash, to identify where a call to super is required. I'm asking SO users to share their knowledge on which of the Fragment lifecycle methods require a call to super.
Fragment lifecycle methods - require call to super
onAttach()
onCreate() - presumably yes, as Activity version requires it
onCreateView() - seems ok with or without
onActivityCreated()
onViewStateRestored()
onStart() - presumably yes, as Activity version requires it
onResume() - presumably yes, as Activity version requires it
onPause() - presumably yes, as Activity version requires it
onStop() - presumably yes, as Activity version requires it
onDestroyView()
onDestroy() - presumably yes, as Activity version requires it
onDetach()
onSaveInstanceState() - presumably yes, as Activity version requires it
All of the corresponding Activity lifecycle methods except onSaveInstanceState require calls to super. In addition:
onAttach() - yes
onActivityCreated() - yes
onViewStateRestored() - is not a Fragment method
onDestroyView() - yes
onDetach() - yes
onSaveInstanceState() - from Fragment#onSaveInstanceState it
looks like a no
All of the methods that require calls to super share the first line of their method in android.app.Fragment:
mCalled = true;
That way the FragmentManager can check if mCalled is true and throw a SuperNotCalledException when it is not called. See FragmentManager#moveToState to see this implementation.
When generating a fragment with Eclipse, the onCreateView method template code does not have a call to super.onCreateView. Also, the generally quite good book published by WROX: Android 4 Application Development misses it out in its sample lifetime code (it does not miss out any other calls to super).
Of course both these two sources could be incorrect, but using the Eclipse template and not adding super.onCreateView has not caused me an issue.
I am typing with capital letter 'O' instead of small letter 'o'
means : OnCreate instead of onCreate methods.
Its a silly mistake but need to remember :)
Thanks
Related
This is the question worth to be asked on the behalf of the new developers in Android.
Idea is to provide a deep understanding to why the framework is written as such.
Also, developers face dangling pointers, illegal states and such run-time crashes, and they do not have a clue that why it is happening.
Programmers now a days heavily use call back and factory patterns. Use of delegate class objects reduce the need for Singleton classes, and the need of multiple inheritance in languages like C, C++.
Developers thrill when they come to understand Handler based message passing between components.
Which one of these methods is more reliable to know that the context of the Fragment, should no longer be used by its components, or outside from the Activity that is parenting it:
onStop()
onDetach()
onDestroyView()
onDestroy()
Best Regards.
Kindly go through this link to understand the lifecycle of Fragments
It says that while your current fragment (you can track using getter and setter in Application extended class) is in dying phase, getView(), and getActivity() will return null. So you should not be using these methods and be cautious of the concerned life cycle callbacks (again can be tracked using boolean getters and setters in the abstract BaseFragment/BaseActivity sub-classes of the regular concrete Fragments and Activity classes).
source
I am tracking all of these methods, to stop using getView() of fragment. I logically feel onDestroy(), is the most suitable method for this purpose.
I am using the trackers in the same way in this answer:
https://stackoverflow.com/a/52017405/787399
This inheritance strategy greatly helps and improves the meaning of the Activity and Fragments life-cycles. I fact it is so power full that you can have those features that are not implicitly provided: Like you can handle system back press (managed in the BaseActivity in onBackPressed() method) whenever back is pressed on the Fragment, and you can block the back pressed event call, till some condition is met, or place an OK_Cancel confirmation alert, that whether you want to really exit the current fragment.
Happy coding :-)
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
After updating the SDK to API level 23, I found that onAttach (Activity activity) is deprecated and the new method is onAttach (Context context). can any one enlighten me on why this change was made?
I think it has basically been to expand the scope of the method, but the official changelog doesn't say anything about it.
As you can see in the changelog they have removed the void onAttach(Activity) but they added a new one with the same name, and it says that is deprecated in the Android Official Documentation.
As richq commented, the support version of Fragment also deprecates onAttach(Activity) and has an onAttach(Context) that can be used instead on all Android versions right back to prehistoric ones.
To adapt to this new changes you can follow this steps:
Change the argument type of onAttach callback from Activity to Context. For unknown reason, this modification results in the fact that the method onAttach(Context) is not called anymore during the fragment lifecycle.
Move the code that was in onAttach method to onCreate one since it gets still executed.
With this modification, the app turns to run as before. No additional import statements are required.
Until this change happened, a fragment could only be attached to an activity. After this change Google can work towards attaching fragments to Services too. Something like how Facebook chat heads work, they could have fragment floating outside an activity too.
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.