Say I have a viewpager with multiple fragments that hold bitmaps. I use setOffScreenLimit(numberOfPagesInViewPager) to make sure that the fragments are instantly available at any time (this is a requirement of my app). Quite, obviously the more fragments I have, the more memory I will use because of the bitmaps inside the fragments and fragments being kept in memory.
Now, suppose that those fragments all show the same content and therefore hold the same bitmaps.
Would it be possible to create only one fragment and reuse it in the viewpager for all pages (and hence reducing the memory footprint to 1 fragment)?
In code I am thinking about something like this:
public class MyAdapter extends FragmentPagerAdapter {
private MyFragment mFragment;
public MyAdapter(FragmentManager fragmentManager) {
super(fragmentManager);
mFragment = MyFragment.newInstance();
}
#Override
public Fragment getItem(int position) {
// Reuse mFragment for all pages in the viewpager
return mFragment;
}
}
This approach does not work however, as I am getting this type of error:
java.lang.IllegalStateException: Can't change tag of fragment MyFragment{4259a4d0 id=0x7f0a0074 android:switcher:2131361908:0}: was android:switcher:2131361908:0 now android:switcher:2131361908:1
Would it be possible to create only one fragment and reuse it in the viewpager for all pages (and hence reducing the memory footprint to 1 fragment)?
Not with FragmentPagerAdapter and FragmentStatePagerAdapter. And I doubt that it would work even with your own custom PagerAdapter.
If you use an app that has a ViewPager, you will notice that the ViewPager animates when swiping, so you see parts of two pages at one time. That will be difficult with only one page. This is why ViewPager requires at least three pages at all times, so it can handle swipes in either direction.
Beyond that, I cannot quite understand why users will want to flip through a series of identical pages in a ViewPager.
Is your fragment complex? If it just has one imageview, you can implement a viewpager that uses simple layout view or just an image view as a base container.
The fragment adapter is frankly more useful if each of your fragments are of different structural code.
Not 100% sure, but I believe fragments get destroyed and re-created by view pager. You could double-check this in debugger. If this is true, then the fragment could be a thin wrapper around a bitmap, and bitmap itself could be cached instead of a fragment. There are multiple strategies on caching bitmaps as described at http://developer.android.com/training/displaying-bitmaps/cache-bitmap.html.
Related
I am trying to create an app using Viewpager2 that allows scrolling between fragments similar to below image but WITHOUT the tablayout at the top.
So if you scroll left and right you would swtich between the fragments. Thats fine and dandy.
However my final app would have more than 5 tabs so i dont want the tab layout listed on top. Instead I would have a menu option that would let user choose which fragment to view.
I cannot figure out how to get the viewpager to go to a specific fragment directly (eg. from 2nd fragment to the 5th fragment), and when navigating between fragments I do not want a fragment to start from scratch if if was created already.
I am using FragmentStateAdapter with my ViewPager2. Should i be using another adapter for this? Any ideas woule be greatful.
The easiest way to implement this feature is to define your ViewPager as static in your activity (so you can access it from anywhere in your application, including fragments). You can make it public, or you can make it private and create a getter for it.
private static ViewPager mViewPager; // This is the global variable
public static ViewPager getViewPager() { return mViewpager; } // This is the getter
Now lets say we have an activity MainActivity which contains the ViewPager. Each fragment inside this ViewPager contains a button which should control the page (doesn't have to be in the ViewPager, could be anywhere as long as it has a reference to your Activity and that Activity is still running, so don't start another one).
ViewPager contains the method
setCurrentItem(int item, boolean smoothScroll)
(smoothScroll is optional and is just for animation purposes)
Now you can do:
MainActivity.getViewPager().setCurrentItem(itemNr);
Or if you want a fancy scroll animation:
MainActivity.getViewPager().setCurrentItem(itemNr, true);
Now your second question / issue was that you mentioned you don't want fragments to get recreated. In that case I think it is better to use FragmentPagerAdapter, which maintains your fragments. You can call the following method to set a limit to these pages:
mViewPager.setOffscreenPageLimit(LauncherViewPageAdapter.NUMBER_OF_PAGES); //NUMBER_OF_PAGES was just a static constant in my LauncherViewPageAdapter class which extended ViewPageAdapter.
Note: Default this limit is 3, but you really don't have to worry about performance. I implemented 4 pages / fragments (widgets, tiles, app list, application settings) without any memory issues (even on older devices). Just don't put them full with bitmaps / heavy memory usage stuff.
I'm currently working on a launcher application which also uses ViewPager, so feel free to reply with a question about the ViewPager, since I solved the basic issues I had.
You can make use of setCurrentItem method of your ViewPager2. Just pass the index your wish to navigate to starting from 0. As for not wanting the fragments to start from scratch simply use setOffscreenPageLimit method of viewpager2 and set it to like 4 in case you have 5 pages so that all 5 pages stay in memory. It actually defeats the purpose of FragmentStateAdapter and ViewPager2 though.
I've been searching for it and all I found was the difference between them. And that's not the point.
If you use FragmentStatePagerAdapter in a ViewPager, you'll end up doing the same as you'd do with FragmentPagerAdapter, but consuming much less memory. If that's true, why should I use the FragmentPagerAdapter?
What is the advantages of using FragmentPagerAdapter?
What is the advantages of using FragmentPagerAdapter?
Speed, particularly when you have an intermediate number of pages: enough to easily hold in memory but beyond the handful that ViewPager wants to hold onto itself. With FragmentStatePagerAdapter, as the user navigates the pager, the adapter destroys some fragments and creates new ones. That takes time, both in terms of the direct Java code and in terms of the impact upon garbage collection. If you do not need that in some circumstance, why pay the price?
FragmentStatePagerAdapter:
If your page contains more fragments better to use FragmentStatePagerAdapter because it will save only state
of the fragment.
FragmentPagerAdapter:
Where as FragmentPagerAdapter will keep each fragment in memory as a result it will consume more moemory.
For example if you have around 3 fragments[in Viewpager] which contains less images/bitmaps better to go with FragmentPagerAdapter
For optimisation better to define mViewPager.setOffscreenPageLimit(2);
Set the number of pages that should be retained to either side of the current page in the view hierarchy in an idle state
if your structure depend on nested fragment and if you need to use childFragmentManager on inner fragment you might have a stack problem with FragmentStatePagerAdapter. when i got this problem i've changed FragmentStatePagerAdapter with FragmentPagerAdapter and it worked well.
What is the difference between FragmentPagerAdapter with ViewPager with OffScreenLimit set to 1 and FragmentStatePagerAdapter?
About FragmentPagerAdapter Google's guide says:
This version of the pager is best for use when there are a handful of
typically more static fragments to be paged through, such as a set of
tabs. The fragment of each page the user visits will be kept in
memory, though its view hierarchy may be destroyed when not visible.
This can result in using a significant amount of memory since fragment
instances can hold on to an arbitrary amount of state. For larger sets
of pages, consider FragmentStatePagerAdapter.
And about FragmentStatePagerAdapter:
This version of the pager is more useful when there are a large number
of pages, working more like a list view. When pages are not visible to
the user, their entire fragment may be destroyed, only keeping the
saved state of that fragment. This allows the pager to hold on to much
less memory associated with each visited page as compared to
FragmentPagerAdapter at the cost of potentially more overhead when
switching between pages.
I think if I set the offscreenlimit to 1, it would destroy all fragments outside of the two next of the current fragment, and it behaves similar to a FragmentStatePagerAdapter. Is this correct?
The difference is exactly as it's written in docs. But it can be a little confusing.
FragmentPagerAdapter holds its fragments in the FragmentManager in detached state while they are not visible (while they are over the offscreen limit bounds) and FragmentStatePagerAdapter removes them from the FragmentManager.
The offscreenPageLimit is something little different. All fragments within it stays attached to the UI. Once they go over, they are either removed, or detached.
You can see it in sources of FragmentPagerAdapter (line 121) and FragmentStatePagerAdapter (line 144)
I have created an android app that uses a ViewPager to swipe through three fragments (each of the three fragments contains a gridview).
I began learning about fragments recently and assumed that after my gridviews were created in their fragments, that each fragment would be in memory and never have to load again.
Recently I noticed that when I swiped from my left fragment, to the middle fragment, then to the right fragment, that the left-most fragment would have to have its gridview filled again with my adapter.
I was just wondering why this happens when I navigate from the left-most fragment to the right-most fragment, but not when I navigate between side-by-side fragments. Does it only keep the most recent fragment in memory and kill the other fragment? Or is there some other reason why an app wouldn't keep all three fragments in memory? My app gets a little laggy and slow when I quickly navigate between fragments, so it would be nice to only have to draw each gridview one time if possible.
I fill my arraylist (used to fill adapter) in onCreate(), and then fill my gridview with the adapter in onActivityCreated(Bundle savedInstanceState)
The ViewPager keeps a certain amount of off-screen tabs (Fragments, of course) in memory. The default, I believe for all devices, is 1. Thus, when you scroll to the far right, only the one to its left will be kept in memory.
If you want your ViewPager to retain all tabs in memory (careful--this can be hard on the device or other running apps), you can set how many off-screen tabs to keep in memory. To do this, use the setOffscreenPageLimit method of ViewPager on your ViewPager object.
Example:
ViewPager pager = (ViewPager) findViewById(R.id.pager); // Your pager's ID
pager.setOffscreenPageLimit(2); // Will retain 2 off-screen tabs + your selected tab
Hope this helps!
It's the nature of how a FragmentPagerAdapter and FragmentPagerStateAdapter work. From Google's site:
The fragment of each page the user visits will be kept in memory, though its view hierarchy may be destroyed when not visible.
Meaning, your GridView is refilling because your ViewPager killed the view and has to rebuild it.
EDIT: If you need to keep all three fragment Views in memory to speed things up, then you would have to create your own PagerAdapter that stores the views in instantiateItem(ViewGroup, int) inside an Collection of some sort.
Alternatively, if you are using Google's example verbatim, then you probably are doing something like this:
#Override
public Fragment getItem(int position) {
return ArrayListFragment.newInstance(position);
}
In which case, you're rebuilding a new fragment each time the ViewPager requests one.
By default ViewPager keeps in an idle state one fragment from the left and one from the right of the current page. You can change this behaviour with ViewPager.setOffscreenPageLimit(). See docs
I read the documentation for android pageadapter and fragmentpageadapter and I didn't see any difference. I mean one is a fragment and one isn't but.. is that all? I don't have really much experience with fragments so maybe thats why I don't notice any difference.
So whats the difference if I use a FragmentPagerAdapter or a PagerAdapter??
The difference is that you can use Fragments inside a FragmentPageAdapter. If you want to have fragments that are going to be used in other parts of your code this is your Adapter.
Otherwise if you only want to have code that isn't going to be reused, you can use PagerAdapter.
Implementation of PagerAdapter that uses a Fragment to manage each page. But I highly recommend to use FragmentStatePagerAdapter class also handles saving and restoring of fragment's state.
FragmentStatePagerAdapter version of the pager is more useful when there are a large number of pages, working more like a list view. When pages are not visible to the user, their entire fragment may be destroyed, only keeping the saved state of that fragment. This allows the pager to hold on to much less memory associated with each visited page as compared to FragmentPagerAdapter at the cost of potentially more overhead when switching between pages.
When using FragmentPagerAdapter the host ViewPager must have a valid ID set.
Subclasses only need to implement getItem(int) and getCount() to have a working adapter.
Here is an example implementation of a FragmentStatePagerAdapter pager containing fragments of lists