[Android] Implement ScrollView sticky headers on Android

[janicduplessis]

This adds support for sticky headers on Android. The implementation if based primarily on the iOS one (https://github.com/facebook/react-native/blob/master/React/Views/RCTScrollView.m#L272) and adds some stuff that was missing to be able to handle z-index, view clipping, view hierarchy optimization and touch handling properly.

Some notable changes:

Adds a stickySectionHeaders prop on ListView to control whether section headers are sticky. This is true on iOS and false on Android by default.

Add ChildDrawingOrderDelegate interface to allow changing the ViewGroup drawing order using ViewGroup#getChildDrawingOrder. This is used to change the content view drawing order to make sure headers are drawn over the other cells.

Add collapsableChildren prop that works like collapsable but applies to every child of the view. This is needed to be able to reference sticky headers by their indices otherwise some subviews can get optimized out and break indexes.

Make TouchTargetHelper take drawing order into consideration when finding the touch target.

Take translate into consideration when clipping subviews.

Fixes issues after the original PR (#9456) was reverted .

Test plan
Tested using the UIExplorer main menu on android.
Tested the Paging ListView example that uses LayoutAnimation to make sure it works.
Tested that touches get dispatched to the sticky header when over other touchable views.
Tested that touchables inside a sticky header work properly.

[ghost]

By analyzing the blame information on this pull request, we identified @astreet and @sahrens to be potential reviewers.

[janicduplessis]

This includes @astreet's fix for nodes that was also reverted as part of the original PR.

I think the main issue that caused the revert was the fact that I used to simply inverse the drawing order instead of changing the drawing order to only affect sticky headers. This adds quite a bit of complexity but it works well and should fix the bug that caused this to be reverted.

This also adds a fix for a bug that happened with LayoutAnimation where the sticked header would get animated in a weird way. To fix this I added a way for a view to opt out of LayoutAnimation.

Lastly this adds a prop on ListView to control whether sections headers should be sticky or not. Defaults to true on ios and false on android so it should make this PR not affect any ListView unless they opt in. This will still affect apps that use stickySectionIndices directly as it used to be a noop on android.

[janicduplessis]

Not sure about this approach but layout animation didn't work properly at all here since the new position of the view isn't docked yet it gets animated in a weird way. What I did is simply add a flag to disable layout animation on ReactViewGroup.

[astreet]

@facebook-github-bot import

[astreet]

I'm gonna pass this to the adsmanager team so they can test it out :)

[ghost]

Thanks for importing. If you are an FB employee go to Phabricator to review internal test results.

[ghost]

@janicduplessis updated the pull request - view changes - changes since last import

[janicduplessis]

@astreet Oups it didn't build with buck, fixed.

[ghost]

@janicduplessis updated the pull request - view changes - changes since last import

[nihgwu]

got time to test this PR, and it's really awesome, all the bugs I mentioned before are resolved
BTW, I think you can also add stickySectionHeaders={true} to UIExplorerExampleList to show power of this feature 😄

[nihgwu]

unfortunately this new PR break my app completely 💔 , I'm making further investigating

[nihgwu]

Every time I change the stickySectionHeaders I get this error(HMR is enabled) seems change whatever will occur this error

The header should be transparent but get white background

The sticky header is overlapped by the content until another sticky header is triggered

[janicduplessis]

@nihgwu Could you send me the code that reproduces these issues?

Also thanks a lot for testing this :)

[nihgwu]

@janicduplessis The first issue should be introduced by recent commits to the master branch, the rest are only found in my app, but it works quite well with the old PR, quite strange, I've try a similar situation in UIExplorer, this new PR works well as expected. I'm struggling to find the cause

ScollView sticky header on Android and Native Animated Event are the last features I'd love to have, thanks for you great work

[facebook-github-bot]

@janicduplessis updated the pull request - view changes - changes since last import

[janicduplessis]

@nihgwu This PR changed the way we handle z-index by changing drawing order so it might be a bug with be new technique. First PR used to just reverse drawing order but that caused other issues, now it will keep the drawing order for non-sticky views and draw all sticky views at the end.

Lets say you have 5 rows:
1: sticky, 2: normal, 3: normal, 4: sticky, 5: normal

old PR:
5, 4, 3, 2, 1
new PR:
2, 3, 5, 1, 4

Code: https://github.com/facebook/react-native/pull/9957/files#diff-49a8f2a72edb3b8c02365cd11a8f2984R471

[janicduplessis]

Thinking about this more I should not have to change the drawing order for all sticky headers, I could only change it for the one that is currenty sticked on top. It would probably simplify this quite a bit.

[nihgwu]

I've notice that you change the drawing order, so I suspect that would be the cause for the different behave, I just don't know why the UIExplore is OK but my app isn't

[nihgwu]

Just test with the newest PR, the first issue is another one and I've create an issue #9969 , the second one no longer exists, but the third is still there, should be something wrong with the drawing order logic

[astreet]

I'm trying to think, is there a chance that the view that's supposed to be sticky could be collapsed? If so, we might need to automatically wrap the children at the sticky header indices in a View that has collapsable=false in JS to make sure this approach works.

[janicduplessis]

Yea it should be possible that it happens. Something like

<View>
  <Text />
  <View style={{ backgroundColor: '#eee', height: 1 }} />
</View>

should get collapsed and is kind of common (pretty sure UIExplorer has something like this).

[astreet]

Felix, can you keep an eye on this/help review while I'm away?

[nihgwu]

any progress on this?

[janicduplessis]

@nihgwu No, haven't had the time to look at this yet

[facebook-github-bot]

It's been a while since the last commit was reviewed and the labels show this pull request needs review. Based on the blame information for the files in this pull request we identified @astreet as a potential reviewer. Could you take a look please or cc someone with more context?

[astreet]

Hey, I was away during October. It looks like this is waiting on changes from you @janicduplessis?

[janicduplessis]

Yes, I haven't had time to update this with what we discussed yet.

[ouabing]

looking forward to this feature too :)

[vitorebatista]

I need this!! :)

[Ehesp]

Any updates @janicduplessis? Would love to see this in!

[janicduplessis]

Planning to work on this in the next few weeks.

[janicduplessis]

Closing this and will open a new PR as I've used a completely different approach.

[janicduplessis]

Follow up: #11315