Opening Achievement Screen also calls API of leaderboard, contribution fragment

[neeldoshii]

Click on more, then from bottomsheet open Achievements. For some reason from logs you can see even being at Achievement Screen the leaderboard api is being called?

2024-12-26 21:03:22.611 OkHttpJsonApiClient     fr.free.nrw.commons                  I  Url https://tools.wmflabs.org/commons-android-app/tool-commons-android-app/leaderboard.py?user=Devanonymous&duration=weekly&category=upload&limit=100&offset=0
2024-12-26 21:03:22.611 OkHttp                  fr.free.nrw.commons                  V  --> GET https://tools.wmflabs.org/commons-android-app/tool-commons-android-app/leaderboard.py?user=Devanonymous&duration=weekly&category=upload&limit=100&offset=0
2024-12-26 21:03:22.611 OkHttp                  fr.free.nrw.commons                  V  --> END GET

Unable to share full logs due to github text limit.

Take it up while working at #6063

[parneet-guraya]

That is intended, because in the Profile screen we use Viewpager and it has page limit of 1 by default so it instantiate neighboring fragment and fragment does trigger a network request as it is instantiated. In this case opening Achievements fragment opens Leaderboard one too as it is next to it. and also if the fragment was in center it would have retained 1 on each (L&R) side. Hope that makes sense :-)

[neeldoshii]

That is intended, because in the Profile screen we use Viewpager and it has page limit of 1 by default so it instantiate neighboring fragment and fragment does trigger a network request as it is instantiated. In this case opening Achievements fragment opens Leaderboard one too as it is next to it. and also if the fragment was in center it would have retained 1 on each (L&R) side. Hope that makes sense :-)

Yes you are correct. Apologies, my bad I didn't wrote the description clear. I think we should migrate from Viewpager to Viewpager2 since it uses RecyclerView.Adapter so it dynamically allocates and deallocates the left and right one's. Wdyt?

[parneet-guraya]

I don't think it would be any different besides we want to have those pre instantiated for the faster context switches.

Also, since we already are picking up Jetpack compose, I think we should use that instead.