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.
Related
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.
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.
After spending a fair bit of time figuring out that the reason my fragments chosen from a drawer layout weren`t displaying sometimes due to the choreographer skipping frames (I was using transaction.replace rather than show/hide) it made me wonder -- what are the situations where one would want to use replace rather than show/hide or detach/reattach? My problem went away when I switched to using show/hide btw.
Taken from this thread I got this on what happens when you call FragmentTransaction.replace():
Android will effectively perform a sequence of
FragmentTransaction.remove(...) (for all Fragments currently added to
that container) and FragmentTransaction.add(...) (for your supplied
Fragment). Removing a Fragment from the FragmentManager will cause the
Fragment to be destroyed and its state will no longer be managed. Most
noticeably, when you re-add the Fragment all of the views will have
been reset. Note: since you are reusing the same Fragment instance,
the Fragment will still keep the value any instance variables.
and from this thread I got that it is probably better to show/hide rather than replace if you plan on using that fragment again. My question is, in which situations do you use FragmentTransaction.Replace()? The only place I could see it really being useful is for something you know you won`t need again, kind of like a dialog picker with options but I use dialog fragments for those situations.
Does anyone use FragmentTransaction.replace regularly, and if so, why did you choose that over another method? Cheers
It maybe useful, for example, when implementing a deep fragments hierarchy in Multi-pane pattern (when click on item in the right fragment moves it to the position of the left).
Also, since hiding a Fragment keeps it in FragmentManager, it maybe expensive if you have a heavy content in it or hide multiple instances. Calling remove() or replace() and properly saving fragment's state is more Android-way, I think.
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.
Offtopic: thank you for your time and sorry for my English.
The problem is the lag when swiping on ViewPager.
The configuration used is a TabHost with Tabs (and dummy content), ViewPager with four fragments and FragmentPagerAdapter to manage it.
All 4 fragments have a list, some with other widgets in the layout. The thing is 2 fragments, or the 2 list in those fragments are quite heavy. The list items are LinearLayout with ~10 weighted items inside binded with a CursorAdapter. I know here resides the big problem, but I have struggled my small head to get an approach to this "percentage width" list item without any luck.
But, after some logs, I have figured out that the 3 managed fragments are "invalidated" during every swipe. I mean "invalidated" because what I see is every list binding items many ( a lot of ) times. And because of the redrawing of the 3 list, including my 2 heavy lists, the lag occurs.
2 things more to point of my code: I'm using cursor loaders, that I'm sure are not the cause of recreation because loader callbacks aren't arise on swipe.
On FragmentPagerAdapter.onPageSelected I'm only updating the current tab.
Setting ViewPager.setOffScreenPageLimit(3) to keep 4 fragments alive do things worse. Even when I swipe from fragment 3 to 4, the list on first fragment is re-rendered, what I really don't want and don't understand.
My workaround is using the onPageSelected to set the visibility of current list view to Visible and the others hidden. With these approach the lag disappears (let's say 95%), but I can see, when I scroll the empty list view before is created.
I would like to ask, if I'm wrong at some point, maybe missing an important idea. If anyone has a possible solution, maybe avoiding those recreations (I don't know how) or, if other people is getting same, and there is nothing to do to solve it.
I will try to take I look to ViewPager source, but I've just opened the file woouu..
I will try to get a test project with this issue.
Thank you very much.