feat(Android): added navigationBarTranslucent option

[alduzy]

Description

Once upon a time there was an issue regarding navigation bar. The problem was that the background color set to the navigation bar covered the content behind, see examples:

navigationBarColor: 'transparent'	navigationBarColor: 'yellow'

Then PR 1988 solved the issue, but introduced another problem: sometimes it may be intended to have content behind the navigation bar.

navigationBarColor: 'transparent' after PR 1988	navigationBarColor: 'transparent' before PR 1988

This PR intents to add a new screen option, enabling navigation bar translucency control, so that the developers can decide if they want to show content behind the navigation bar independently.

Fixes #2122 #1719

Changes

• added navigationBarTranslucent option

Test code and steps to reproduce

Checklist

• Included code example that can be used to test this change
• Updated TS types
• Updated documentation:
  • https://github.com/software-mansion/react-native-screens/blob/main/guides/GUIDE_FOR_LIBRARY_AUTHORS.md
  • https://github.com/software-mansion/react-native-screens/blob/main/native-stack/README.md
  • https://github.com/software-mansion/react-native-screens/blob/main/src/types.tsx
  • https://github.com/software-mansion/react-native-screens/blob/main/src/native-stack/types.tsx
• Ensured that CI passes

[kkafar]

Hey, few initial remarks.

Why is this a problem since 3.30, why was the code removed that was responsible for this behaviour.

If we go with new prop, we do not restore backward compatibility and we commit to introducing breaking change in behaviour.

I want to see some description in PR why this is the way to go instead of restoring old behaviour and keeping backward compatibility.

Another issue is that we want to have similar behaviour on both platforms. How does this look like on iOS, does the problem occur there? How do we plan to handle this prop there?

[alduzy]

@kkafar Right before 3.30 release this commit changed the navigation bar behavior.

As far as I know WindowCompat.setDecorFitsSystemWindows() caused problems with screen layout and/or jumps in some cases, so it's not a good idea to add the logic back in all cases when navigation bar is not hidden.
In certain situations users may want to achieve such appearance and I think it's best to enable it through a separate option.

@tboba feel free to share your thoughts.

[kkafar]

I think we need some elaboration on reasons & whys of the situation in the PR's description.

This commit you refer to #1988 went under my radar & I'm not convinced it was good change.

By adopting the suggested approach we would commit to a small, but still breaking change in behaviour & I'm not convinced we do need this.

So basically I want you to understand & advocate for why #1988 was needed / or it was not, and then we can continue here.

There is one more level to this change, how does this behave in context of edge-to-edge and not edge-to-edge applications?

Also my questions related to iOS are still open.

I'm picky today in my reviews 😅

[WoLewicki]

The code looks good overall, but we need to have it properly documented in the PR description why is it needed, so the users know how to correctly use it.

[tboba]

That looks better, LGTM! Just one thing before merging 😄

[kkafar]

These changes look good, thank you! 🎉

There is one more thing, however, namely have you tested what happens on iOS (especially Paper, but check Fabric too) when somebody uses this prop? Won't we get any undesired behaviour?

[alduzy]

@kkafar I've tested the prop on both fabric and paper and also checked to make sure it does not impact iOS

[kkafar]

Provided that iOS behaves nicely I think we're good to go