Skip to content
This repository has been archived by the owner on Mar 24, 2020. It is now read-only.

zendeskarchive/android-support-v4

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

50 Commits
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

This is a fork of support-v4 library version 23.1.1. upstream contains the original support-v4 code, master branch includes our changes in implementation (to fix some issues that affected us) and build scripts (to allow project compilation outside of AOSP).

Here's a detailed list of implementation changes between upstream and master, unless noted otherwise, the issues are not fixed in newer versions of support lib:

Already fixed in upstream

Prevents unnecessary data reload. Does not change the correctness of Loader implementation, might have a microscopic performance impact ;)

Changes to observer registration in CursorLoader (part 1, part 2)

Ensures the initial load is delivered as soon as possible, which seems to be the CursorLoaders author intention. Without this change the observer is registered in background thread and the change notification might be triggered before the result is delivered. In most pathological case it might cause infinite reloading.

Supplements the existing logic for disallowing non-static member Loaders.

There is a race condition that might cause result delivery loss. A better looking fix was done in support-v4 upstream

Fixed onActivityResult() dispatching to child fragments (part 1, 2 and 3)

Already fixed in latest support lib.

Fixed in support lib (1, 2)

Fix invalid Fragment state restoring (part 1, part 2).

This is an intermingled state machines extravaganza, a bug on the joint of LoaderManager, FragmentManager and FragmentStatePagerAdapter.

In some cases the child Fragments initialize their identifier (mWho internal property) before their parents, and due to the null behavior in Java String concatenation they end up with null:0 identifier instead of android:fragment:0:1 or something like this.

This identifier is used for LoaderManager initialization. If you have multiple Fragments with child Fragments added to ViewPager, they might end up sharing the LoaderManager instance, and when they use the same Loaders ids, you end up with data corruption, ClassCastException or LoaderCallbacks deregistering one another.

I verified that this bug exists in old support-v4 version, it was fixed in this fork and it was fixed in the upstream as well.

The future of this fork

Is not bright. Maintaining it before The Great Support Lib Split was already a pain in the ass, and I expect the merge with the current upstream to be at least twice as painful.

All critical issues were already fixed in the upstream and the other changes have negligible impact.