Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix pulse numbering bug. #481

Merged
merged 6 commits into from
Sep 9, 2015
Merged

Fix pulse numbering bug. #481

merged 6 commits into from
Sep 9, 2015

Conversation

tasomaniac
Copy link
Member

The problem is because FragmentStatePagerAdapter was aggressively caching the states of its children Fragments.
Here is the bug reported and it is still open. https://code.google.com/p/android/issues/detail?id=37990

There are couple of ways to fix it using a really really custom FragmentStatePagerAdapter without subclassing it. I don't like those solutions. It is not optimal but recreating the adapter fixes this problem.

The problem is actually because of the positions calculation in the code. On orientation change it reset and makes another problem. I saved it on config change and now it works perfectly.

Fixes #451

@tasomaniac tasomaniac added the bug label Sep 3, 2015
@tasomaniac tasomaniac added this to the Release 2.3 milestone Sep 3, 2015
return (value.getPlusMembers() - value2.getPlusMembers()) * -1;
}
return 0;
return entry.getValue().compareTo(mode, entry2.getValue());
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

compareTo is a function in PulseEntry. And it was exact duplicate of this.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you just make PulseEntry implement Comparable and avoid this here altogether?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure. Makes sense.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The type of the objects is Map.Entry<String, PulseEntry> not just PulseEntry. Map.Entry does not implement Comparable. So it will not work. Getting rid of Map.Entry<String, PulseEntry> is out of this PR's scope I think.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This adapter manages an ArrayList of Map.Entry. WAT? 😉

I'll try to address this later because it bothers me physically. 😱

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I said OMG when I first saw it. :) It is everywhere in the adapter. The key in the map entry is actually used as the title.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Tracked as #487

@PareshMayani
Copy link
Member

👍 awesome contribution @tasomaniac

@tasomaniac
Copy link
Member Author

@PareshMayani you already reviewed this right?
Any one up for merge @friedger @Splaktar ?


private void refreshSpinner(String selectedPulse) {

mSpinner.setAdapter(mSpinnerAdapter);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This line needed to be reset every time? Looks out of scope for this method.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You are right. Fixing now.

@stefanhoth
Copy link
Contributor

I reviewed bits of the code but I don't understand enough to assess the change. If you could explain again what you persist, where and why it would help me understand. It'll be best to comment the lines where something is happening.

if (!previous.equals(mSpinnerAdapter.getItem(position))) {
Timber.d("Switching chapter!");
mViewPagerAdapter.notifyDataSetChanged();
refreshSpinner(mSpinnerAdapter.getItem(position));
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ViewPager's notifyDataSetChanged is not working because it aggressively cache the Fragment state which shouldn't be cached because we are changing the list completely. Eg. first we show countries, then we show cities in a specific country. This was causing ListView to restore its scroll position when we change cities, which doesn't make sense.

Multiple Spinner Adapter initialization is removed.
@stefanhoth
Copy link
Contributor

Ok, let's 🚢 it.

stefanhoth added a commit that referenced this pull request Sep 9, 2015
@stefanhoth stefanhoth merged commit 96181e4 into develop Sep 9, 2015
@stefanhoth stefanhoth deleted the 451/pulse-numbering branch September 9, 2015 15:11
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Pulse numbering bug.
3 participants