I'm creating a slideshow with ViewPager2. For example, the slideshow has 3 items and I want to show the second item when the activity opens. I use setCurrentItem(int item, boolean smoothScroll) method but it doesn't work and nothing happens. How can I achieve it?
viewPager.adapter = adapter
viewPager.setCurrentItem(1, true)
I think an easier more reliable fix is to defer to next run cycle instead of unsecure delay e.g
viewPager.post {
viewPager.setCurrentItem(1, true)
}
setCurrentItem(int item, boolean smoothScroll) works correctly in ViewPager but in ViewPager2 it does not work as expected. Finally, I faced this problem by adding setCurrentItem(int item, boolean smoothScroll) method into a delay like this:
Handler().postDelayed({
view.viewPager.setCurrentItem(startPosition, false)
}, 100)
Do not use timers, you will run into a lot of probable states in which the user has a slow phone and it actually takes a lot longer than 100 ms to run, also, you wouldn't want too slow of a timer making it ridiculously un-reliable.
Below we do the following, we set a listener to our ViewTreeObserver and wait until a set number of children have been laid out in our ViewPager2's RecyclerView (it's inner working). Once we are sure x number of items have been laid out, we start our no-animation scroll to start at the position.
val recyclerView = (Your ViewPager2).getChildAt(0)
recyclerView.apply {
val itemCount = adapter?.itemCount ?: 0
if(itemCount >= #(Position you want to scroll to)) {
viewTreeObserver.addOnGlobalLayoutListener(object: ViewTreeObserver.OnGlobalLayoutListener {
override fun onGlobalLayout() {
viewTreeObserver.removeOnGlobalLayoutListener(this)
// False for without animation scroll
(Your ViewPager2).scrollToPosition(#PositionToStartAt, false)
}
}
}
First off, I think that the accepted answer shouldn't be #hosseinAmini 's, since it's suggesting to use a delay to work around the problem. You should first be looking for what the assumed bug is caused by, rather than trusting unreasonable solutions like that.
#Rune's proposal is correct, instead; so I'm quoting their code in my answer:
viewPager.post {
viewPager.setCurrentItem(1, true)
}
The only thing I'd argue about is the aforementioned one's belief that their solution is just deferring the execution of that lambda in the next run cycle. This wouldn't make anything buggy work properly. Rather, what it is actually being done is deferring the execution of that lambda to once the view has been attached to a window, which implies it's also been added to a parent view. Indeed, there looks to be an issue as to changing the current ViewPager2 item before being attached to a window. Some evidence to support this claim follows:
Using whichever Handler won't work nearly as effectively.
Handler(Looper.getMainLooper()).post {
viewPager.setCurrentItem(1, true) // Not working properly
}
From a theoretical standpoint, it might incidentally work due to the ViewPager2 being attached to a window acquiring priority in the message queue of the main looper, but this shouldn't ever be relied upon as there's just no guarantee that it'll work (it's even more likely it won't) and if it even turned out to be working, further investigation running multiple tests should make my point clear.
View.handler gets null, which means the view hasn't been attached to any window yet.
View.handler // = null
Despite Android UI being tied to the main looper, which will always uniquely correspond to the main thread –hence also called the UI thread,– a weird design choice stands in the handler not being associated to each view until they get attached to a window. A reason why this may lay on the consequent inability of views to schedule any work on the main thread while they're not part of the hierarchy, which may turn useful when implementing a view controller that schedules view updates while unaware of their lifecycle (in which case it would employ the View's handler, if any — or just skip scheduling whatever it was going to if none).
EDIT:
Also, #josias has pointed out in a comment that it'd be clearer to use:
viewPager.doOnAttach {
viewPager.setCurrentItem(1, true)
}
Thanks for that suggestion! It expresses better the actual intent, rather than relying on the behavior of the View.post method.
Do not use timers and all that stuff with 'post', it's not the reliable solution and just a piece of code that smells.
Instead, try use viewPager.setCurrentItem(1, false). That 'false' is about smoothScroll, you can't smooth scroll your viewPager2 when your activity is just opened. Tested it on a fragment in onViewCreated() method, it also didn't work with "true", but works with "false"
As it was mentioned above you have to use setCurrentItem(position, smoothScroll) method on ViewPager2 in order to show selected item. To make it work you have to define a callback, here is an example:
ViewPager2.OnPageChangeCallback callback = new ViewPager2.OnPageChangeCallback() {
#Override
public void onPageSelected(int position) {
super.onPageSelected(position);
}
};
And then you have to register it as follow:
viewPager.registerOnPageChangeCallback(callback);
Also do not forget to unregister it:
viewPager.unregisterOnPageChangeCallback(callback);
When you call setCurrentItem(position) method it will call onPageSelected(int position) method from your callback passing your argument, and then method createFragment(int position) from FragmentStateAdapter class will be called to show your fragment.
I tried changing viewpager2 page in Handler().dely() and viewPager2.post{} and even 'viewPager2.get(0).post all didn't work for me, I'm using ViewPager with FragmentStateAdapter with Tablayout.
What worked for me is changing the position of the RecylerView in ViewPager2 after binding FragmentStateAdapter to yourViewPager2View.adapter manually:
(yourViewPager2View[0] as RecyclerView).scrollToPosition(moveToTabNumber)
Why
My problem is onCreateFragment(position:Int):Fragmeet function in FragmentStateAdapter always starting fragment at 0 position no matter what pageNumber I set the page
viewPager.setCurrentItem = pageNumber
I checked where it's called in FragmentStateAdapter it's called in FragmentStateAdapter:
onBindViewHolder(final #NonNull FragmentViewHolder holder, int position)`
so all I needed is to force onBindViewHolder to call onCreateFragment(position:Int) with the page number I wanted.
mViewPager.setCurrentItem(1, true); ---> this is sufficient as you written above
That should work,
in doubt, just check your position:
#Override
public void onPageSelected(int i) {
if (LOG_DEBUG) Log.v(TAG, " ++++++++ onPageSelected: " + i);
mViewPager.setCurrentItem(i);
//TODO You can use this position: to write other dependent logic
}
and also check
getItem(int position) in PagerAdapter
or else paste your code.
I noticed that it works fine when the view is initially created if you opt to not animate it.
viewPager2.setCurrentItem(index, false)
This is usually fine depending on your use case - this initial/default item probably doesn't need to be animated in.
I met the same problem. In my case, I make the viewPager2 Gone by default until network requests succeed, I fix it by setting the CurrentItem after I make the viewPager2 visible.
My answer may not be helpful now but i see no harm to post my expreince, i just came to this problem using ViewPager and ViewPager2 and unexpectedly solved it by just changing some line codes order.
Here is (java) solution for ViewPager:
reviewWordViewPager.addOnPageChangeListener(changeListener);
reviewWordViewPager.setCurrentItem(viewPosition, true/false);
reviewWordTabIndicator.setupWithViewPager(reviewWordViewPager, true);
(Java) solution for ViewPager2:
wordViewPager.registerOnPageChangeCallback(viewPager2OnPageChangeCallback);
wordViewPager.setCurrentItem(vpPosition, true/false);
new TabLayoutMediator(tabIndicator, wordViewPager,
((tab, position) -> tab.setText(viewPagerTitle[position]))).attach();
I did not look up for ViewPager2 whether it needs the following old code used in ViewPager
#Override
public int getItemPosition(#NonNull Object object) {
// refresh all fragments when data set changed
return POSITION_NONE;
}
But surprisingly no need for it in ViewPager2 to solve the problem i've been having, hope it helps others
In case you use context.startActivity to start new activities no need to use wordViewPager.setCurrentItem(item, smoothScroll) in your onResume function to get back to the last selected tab before you started new activity you just save ViewPager/ViewPager2 position like vpPisition = wordViewPager.getCurrentItem(); in onStop function.
vpPisition is a global variable.
as #Daniel Kim but a java version
RecyclerView rvOfViewPager2 = (RecyclerView) viewPager2.getChildAt(0);
rvOfViewPager2.getViewTreeObserver().addOnGlobalLayoutListener(new ViewTreeObserver.OnGlobalLayoutListener()
{
#Override
public void onGlobalLayout()
{
rvOfViewPager2.getViewTreeObserver().removeOnGlobalLayoutListener(this);
viewPager2.setCurrentItem(currentTabId, false);
}
});
First You need to Initilaze the Main activity under any listener or button You want then After that You need to put this Line..
here MainActvity is the Viewpager Main Class You are using and and 2 is the position where you want to move
MainActivity main = (MainActivity ) mContext;
main.selectTab(2, true);
I have a ViewPager which i populate with 4 items. I need it to be scrollable until the 3rd item (inclusive) but when the user tries to move to the 4th one it should just not let him.
When he validates the 3 pages, only then i need to allow him to move to the 4th.
Don't ask why, it's complicated, but I can't instantiate and set the 4th page to the adapter only AFTER the first 3 are validated. That would solve my problem, indeed. I need to have it already available in the list.
Any suggestions?
I tried playing around with onPageScrolled() to see if I can stop it from moving forward even a pixel, but I wasn't able to figure it out.
#Override
public int getCount() {
if(!isAccess) {
return 3;
} else {
return 4;
}
}
I have been looking for this answer a while, and i haven't found any good solution which would help me getting started in creating this. This is what i would like to do. Like we have view types in lists and we can show different layouts on different position in lists using those view types, i would like to do that also with viewpager. I'm showing some images from server in viewpager, so user can swipe them, but i would like to show user between those images on every 5 image ad. How can i accomplish that?
This is how my viewpager adapter looks:
private class JokesImagesAdapter extends FragmentPagerAdapter {
public JokesImagesAdapter(FragmentManager fm) {
super(fm);
}
#Override
public Fragment getItem(int position) {
JokePageFragment fragment = new JokePageFragment();
fragment.setArguments(jokes.get(position).toBundle());
return fragment;
}
#Override
public int getCount() {
return jokes.size();
}
}
And i guess that probably i need to create one more fragment and call it here with implementation of ads.
What kind of ads you want to show in your app - Interstitial or Native ad?
If you want to just show an interstitial ad on every 5 swipes - just attach an OnPageChangeListener to your ViewPager and count the swipes.
If you want to show a native ad, you have to create a new fragment (as you thought) which will be showing the ad. You have to count and return the ad fragment in the getItem() method of your adapter. Another way to handle this is to use one fragment which will be notified whether to show or not an ad view or a normal view.
What I believe is that you should modify your jokes model a little, which could accept objects instead of just images(and your custom parameters) and then cast the object to the required datatype and then while populating jokes, you should add the ad object every 5th position, that would do the work.
I have created pages in Android by using PagerAdapter. When I tried to get value in the third page from EditText, I got NullPointerException.
In the third fragment page, I have initialled that EditText already.
iName = (EditText) view.findViewById(R.id.name);
So does this problem occur while the third page haven´t initialled?
A ViewPager, by default, keeps one fragment on each side in memory. You can change this by setting the offscreen page limit.
From the documentation:
Set the number of pages that should be retained to either side of the
current page in the view hierarchy in an idle state. Pages beyond this
limit will be recreated from the adapter when needed.
This is offered as an optimization. If you know in advance the number
of pages you will need to support or have lazy-loading mechanisms in
place on your pages, tweaking this setting can have benefits in
perceived smoothness of paging animations and interaction. If you have
a small number of pages (3-4) that you can keep active all at once,
less time will be spent in layout for newly created view subtrees as
the user pages back and forth.
You should keep this limit low, especially if your pages have complex
layouts. This setting defaults to 1.
Parameters limit How many pages will be kept offscreen in an idle
state.
Example usage: yourViewPager.setOffscreenPageLimit(2);
When you use the default implementation of setOffscreenPageLimit() it is only loading the one fragment which is to the right of it. For eg. when you are on index 1, it has index 2 loaded in memory but not index 0, so swiping left will have to generate a new fragment from scratch. To test this theory you might want to use setOffscreenPageLimit(2) and then try swiping index 1->0. This in no way is the optimal solution but will help clear out your doubts about the concept.
you can store the fragment state of all the pages in the pages adaper like this and get reference of it.
PagerAdapter
private class ScreenSlidePagerAdapter extends FragmentStatePagerAdapter {
private List<Fragment> fragmentsList;
public ScreenSlidePagerAdapter(FragmentManager fm) {
super(fm);
}
#Override
public Fragment getItem(int position) {
Fragment fragment=new ScreenSlidePageFragment();
fragmentsList.add(fragment, position);
return fragment;
}
#Override
public int getCount() {
return NUM_PAGES;
}
public static List<Fragment> getFragmentsList(){
return fragmentsList;
}
}
In Activity:
List<Fragment> fragList=adapter.getFragmentsList()
View view = fragList.get(position).getView();
if (view !=null) {
view.findViewById(R.id.text_view).setText("Child Accessed :D");
}
I have a ViewPager that I shows more than one item. I used the solution of putting multiple items in one fragment and I created an Adapter that calculates how many items I can put per fragment based in the width of the screen.
The getItem of my FragmentPagerAdapter creates a range of items for each fragment, dividing the quantity of items for each fragment.
For example, I have 12 items and in the portrait orientation, I can put 3 items. The getItem will create fragments with the range of 0-2, 3-5, 6-8 and 9-11. In the landscape orientation, since the width of the screen is bigger, I can put, for example, 5 items. So, the ranges would be 0-4, 5-8 and 9-11.
With this requirement, I need to create new Fragments and destroy the old ones on orientation changes.
I created a solution, but it depends on the method isChangingConfigurations() of the Activity. But this method just exists for API level 11 and above. So I can't use it.
Basically, I I'm not allowing the Fragment to save its state and I'm removing it in the onPause if the configuration is changing. But since I don't have this method in old android versions, I need another solution.
Can anyone help me?
Another solution is:
#Override
public void onSaveInstanceState(Bundle savedInstanceState) {
if (pagerAdapter != null) {
pagerAdapter.removeAllfragments();
}
super.onSaveInstanceState(savedInstanceState);
}
And the code for adapter:
public void removeAllfragments()
{
if ( mFragmentList != null ) {
for ( Fragment fragment : mFragmentList ) {
mFm.beginTransaction().remove(fragment).commit();
}
mFragmentList.clear();
notifyDataSetChanged();
}
}
mFragmentList should add fragments inside of:
#Override
public Fragment getItem(int position) {}
The easiest solution to your current approach is probably to ensure that getItem(int) returns different values for the landscape and portrait orientations. The id is used to generate the fragment tag, that, after an orientation change, is used to retrieve a detached fragment and reattach it. With different ids for the situation where respectively 3 items and 5 items are next to each other, a fragment with 3 items will never be reattached if there should be 5.
By default, getItemId(int) simply returns the supplied position of the element, like so:
public long getItemId(int position) {
return position;
}
In order to return different ids for your situations, you have various options. A straightforward one would be to do something smart with the indices of all items displayed for the given position. Alternatively, you could do a simple device orientation check and offset the id with the total number of items, or do something smart with a string and a hashcode etc. Just make sure you return the same id for the same fragment in the same orientation.