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 ;)
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
Already fixed in latest support lib.
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 Loader
s 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.
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.