What is the difference between OnCreate and OnCreateView in the lifecycle of fragments. Also why there is no OnCreateView in Activity life cycle but in frgaments. I am confusion in these two methods.
Please help me with the suggestion as I am very new to android programming.
onCreateView() allows you to inflate a layout for a fragment and get your views with findViewById().
The fragment's onCreate() gets always called directly before the onCreateView() method. It does not allow you to setup a fragment layout, so you always have to override onCreateView().
Most times you do not need the fragment's onCreate().
An activity does not need onCreateView(), since it has the setContentView() method, which allows you to setup a layout in the activity's onCreate().
Related
I keep reading everywhere that you can now use the activity/fragment constructor to define the layout id with AndroidX, but none answer my question.
What if you have others things to do in Activity's onCreate or Fragment's onCreateView ? Can you still use this new constructor ?
For Activities
Yes, it just means that the Activity will call setContentView() with the layout ID you provide as part of calling super.onCreate(savedInstanceState). Otherwise, you can proceed as normal in your onCreate().
For Fragments
Generally, if using the layout ID constructor, you'd want to move your code from onCreateView() to onViewCreated(), which is passed the View that was created by onCreateView().
Of course, if you do want to override onCreateView() for some reason, you'd want to call super.onCreateView() to retrieve the inflated layout corresponding with the layotu ID you provided to the constructor argument.
recently i saw some articles about inflating the fragment layout directly from the Fragment()
class ExampleFragment: Fragment(R.layout.example_fragment)
does this stand only for fragments that dont hold any data and interaction, when should we use this method
This was added in androidx.fragment version 1.1.0:
Fragment LayoutId constructor: Subclasses of Fragment can now optionally call into a constructor on Fragment that takes an R.layout ID, indicating the layout that should be used for this fragment as an alternative to overriding onCreateView(). The inflated layout can be configured in onViewCreated().
So in essence it's a shorthand for overriding onCreateView() that just inflates a layout and returns it, and encourages a style of configuring the view in onViewCreated() rather than onCreateView().
I have something that has me stumped. I have a Fragment (Fragment A) that has ViewPager that contains three fragments (for swiping left/right). So, if within another fragment, in the onBackPressed() method, I do a getFragmentManager().popBackStack() call, Fragment A will be again be visible (with the ViewPager of sub-fragments) which is the desired state. However, there is no method with Fragment A or within the ViewPager that indicates that Fragment A/ViewPager is again visible.
None of the fragment methods referenced in the Fragment lifecycle (http://developer.android.com/guide/components/fragments.html) that should be called when "The fragment returns the layout from the back stack" or any of the methods called within OnPageChangeListener (yes, I do call viewPager.setOnPageChangeListener(this) within Fragment A's onCreateView).
Thoughts on where I could look?
I have an app with a ViewPager that is added to the layout, then later replaced by another fragment, with the change added to the transaction back stack. I have Log statements in each of the lifecycle methods of the pager. When the Back button is pressed and the pager is returned to the layout, my logcat output shows these methods called for the pager: onCreateView(), onActivityCreated(), onStart(), onResume(). Note that when a fragment goes into the back stack, its view is destroyed, but the fragment object is not destroyed, so when the fragment returns from the back stack, there is no call to onCreate().
This behavior is consistent with the lifecycle diagram in the Fragment Guide. You should be able to use the call to onResume() as an indication that your pager is visible. I can only suggest that you add debug output to the lifecycle methods for your pager and look at the output. If you think its wrong, please add it to the post of your question. Also indicate what fragment transaction method(s) you are using. If by chance you are using hide() instead of remove() or replace(), then the lifecycle events are different and you may need to use onHiddenChanged().
I am working on a application for which I have some issues with fragments. First of all , I want to know if it is possible to make one fragment inside another fragment. And the second one is when to call onCreateView() and onActivityCreated() and which is best?
Per the Android sources:
onCreateView is called by the Activity during the construction of the view hierarchy. This is where the Fragment has the opportunity to instantiate its own user interface view.
onActivityCreated is called when the Activity has been fully created and finished instantiating the view hierarchy. At this point it's safe for the Fragment to access the its views and restore itself from some saved state.
You cannot create a fragment inside another fragment. You should communicate between fragments thru activity.See http://developer.android.com/guide/components/fragments.html#CommunicatingWithActivity
I didn't understand your second question clearly. But I generally leave onActivityCreated() blank without changing it. And use onCreateView() in a similar way with onCreate().
I know that a fragment's view hierarchy has to be inflated in onCreateView, but what other functionality can be in onCreateView vs. what should wait for onActivityCreated? My current implementation uses separate activities for everything, and a typical activity does most of its work in its onCreate method, including inflating the view, setting the content view, initializing the various widgets with data, setting up listeners, etc.
So can this probably all be moved into onCreateView, or should some functions be put into an onActivityCreated method instead?
If your view is static, then moving any code to the onActivityCreated method is not necessary. But when you - for instance, fill some lists from the adapter, then you should do it in the onActivityCreated method as well as restoring the view state when setRetainInstance used to do so.
Also accessing the view hierarchy of the parent activity must be done in the onActivityCreated, not sooner.
onActivityCreated() is deprecated in fragment 1.3.0-alpha02 and there is a recommendation to use onViewCreated() instead. View is already created here and you can set listeners, observe LiveData from ViewModel, initialize recyclerView, etc.
For a better understanding, you can take a look at my blog post, where I describe the Android Fragment lifecycle in 137 seconds.