Android View Pager: onCreateView getting called for both fragments - android

I am trying to implement swipe views with 2 tabs. For that, I am using view pager with 2 fragments. Now, the problem is that as soon as the main activity is opened (that contains those two tabs), onCreateView function is called for both the fragments. Please help me as how can I avoid calling of onCreateView of second fragment when one is in use.
Thanks,
Arpit

ViewPager retains the fragment to the left and to the right of the current view by default. This is to reduce a choppy user experience - that way you can begin swiping left or right and immediately see what is there without delay.
It is possible to disable (or increase the number of fragments to be retained) with setOffscreenPageLimit(0), but seriously consider if this is the right approach.

Related

How to use an activity component in different fragments with viewpager

I have an activity with 5 fragments. i'm using different functionalities on the same component's onClick inside different fragments. because of viewpager's fragment preloading, functionality of next fragment is executed instead of current fragment. what should i do?
There is no way to avoid it because of view pager has minimim offset is 1.
So I would suggest to you using another way to archive your result:
Idea 1: If you are using FragmentStatePagerAdapter second parameter as FragmentStatePagerAdapter.BEHAVIOR_RESUME_ONLY_CURRENT_FRAGMENT, it means only one fragment inside your view pager will be in onResume state. Therefore you could start all of your networking/side effects job in onResume method.
Idea 2: Why do you using view pager, when you do not need swipe left/right effect? Probably you are in the wrong way. You could use for example just frame layout, then with your fragment manager attach and detach fragment when a user interacts how you expected. I would advise you to look better at FragmentTransaction. Here is a link.
Feel free to ask me about one of these approaches.

How to not delete fragments in Scrollable tabs + swipe

I have an scrollable tabs + swipe activity with 3 different fragments on it. It works well but I don't want my fragments to be destroyed when I navigate between them. For example, when I create the activity, it's shown the first fragment but it's created the second one too. When I swipe to the second fragment, the third is created, so I can swipe to the third one and it will be created before I open it. When I return to the second one, my third fragment still stays created but when I return to the first one, the third fragment is deleted.
There would be any way to avoid this? I don't want my fragments to be deleted when I navigate between them.
If you use a ViewPager, it has a method called setOffscreenPageLimit(int limit). Try and see if setting that higher works
This answer should help you figure out what's going on. Pretty much you are most likely using a FragmentStatePagerAdapter, when you should be using a FragmentPagerAdapter. That keeps it from deleting fragments not in view.
If, for performance reasons, you need to have the fragments deleted when they aren't being used, there are other options. Either look at why the performance is that bad when you have only 3 tabs (It shouldn't be unless you are doing something wrong with a listview, or have a map open, etc.) or you can code the fragments to save their state when they are being destroyed (which should be happening anyways with a FragmentStatePagerAdapter).
If that doesn't help, we'll need more info on what you are doing exactly to help.

In ViewPager, Fragment (n+1) depends on user input in Fragment (n). How to create Fragment (n+1)?

The ViewPager object is implemented such that the next screen is already created in memory before the user swipes to it. ViewPager has a method setOffscreenPageLimit(n) in which you can set the number of ViewPager fragments that are created in advance, but n=0 is not allowed. The reason behind that is to garantee a 'smooth user experience'. In my case however then content of page n+1 is determined by what the user has done on page n. For instance if the user has clicked on a checkbox on page n, it can happen that some widget should not be shown on page n+1. My question is: how can I ensure that page n+1 is recreated? If that goes at the cost of a 'smooth user experience' so be it. I am able to intercept the swipe event in:
pager.setOnPageChangeListener(new ViewPager.SimpleOnPageChangeListener()
In that method I can call a refresh() method of the current fragment. The problem is: what do I do in that refresh() method or is this the wrong approach? The user interface I want to recreate is in the onCreate method, a callback method. Or can't this work and do I need to replace the Fragment (n+1) in memory with a new one and if so, how do I do that?
Any help would be appreciated.
Trying to replace the fragment associated with a page in a ViewPager is going to be the responsibility of your fragment-based PagerAdapter. I am not aware of an easy way to accomplish that with FragmentPagerAdapter or FragmentStatePagerAdapter. My ArrayPagerAdapter can handle it better, though I don't offer a direct replace() operation.
In your case, the better solution is to adjust the fragment that you have, rather than to replace the fragment outright. In theory, this should be possible for just about any degree of change. In practice, there is probably a level of complexity after which trying to replace the fragment would be simpler than trying to have a mashup of all possible fragments.
Note that nested fragments might be another option, where the N+1th page was a placeholder and ran a FragmentTransaction to populate itself when shown. Nested fragments are tricky and quirky.
With regards to the "holes", View.INVISIBLE indicates that you want the widget to continue taking up space (e.g., so stuff after it in a LinearLayout does not move), but do not draw the pixels. View.GONE means that the View is totally ignored for layout purposes, though it is still in the hierarchy and so can be easily toggled back to View.VISIBLE if needed. Another possibility would be to remove the View entirely from the parent container, though this should have no visible change when compared with View.GONE.

Calling onCreate of next fragment in view pager

while using View pager, I face a strange problem.
In my project i have three fragment in a view pager, but while loading the second fragment by swiping from left to right , the OnCreate of third Fragment is automatically calling.in onCreate method i called an Api for getting some data.hence the Api is also called.Normal scenario is like that it only called while loading third fragment by swiping from left to right.
Thanks in Advance
View pager works same as listview.
It have same buffer of fragments to increase the UI experience.
so it creates fragments in advance and show to he user when asked.
so use http://developer.android.com/reference/android/support/v4/view/ViewPager.OnPageChangeListener.html
for your purpose.
Thanks

Recreating fragment's view when paging tabs in Action Bar

I use ActionBarSherlock compatibility library and experience a strange behavior when paging between tabs of Action Bar. Each tab contains a simple Fragment, nothing special. I observed that fragment's onCreateView method is called too often even though there is no screen orientation change. It looks like some kind of pre-caching. I have three tabs there, when the activity is created, the onCreateView is called only for the first two fragments. The last fragment doesn't create view until I page one step forward. The same behavior occurs when paging from the last tab to the first.
Has anybody any idea why this occurs? I would assume creating all views at once, when the parent activity finishes its creating. I don't want to create views again and again, there are no changes in the fragments, they are static. It has no sense and causes paging to be sluggish a bit...
After a few hours I found what's happening there. ViewPager has a default setting DEFAULT_OFFSCREEN_PAGES which sets the maximum number of views (fragments in my case) to be stored in the view container of ViewPager. It is obviously some kind of resource optimization; invisible views can be thrown away and restored when needed.
There is nothing easier then change this value by setOffscreenPageLimit(int limit) setter which I overlooked.
I think it was done consciously to increase user experience.
The same way ViewPager from compatibility lib is implemented.
Anyway, sources are available.

Categories

Resources