chore: Remove react-native-edge-to-edge from example apps

[kmichalikk]

Description

Closes https://github.com/software-mansion/react-native-screens-labs/issues/355

Changes

This PR removes the react-native-edge-to-edge dependency form Paper and Fabric example applications in favor of core RN API. For android, the transparent 3-button navigation bar is enabled to match the removed package behavior.

setNavigationBarContrastEnforced(false) is called in onAttachedToWindow() for each app's Activity so the navigation bar looks like this (prior to the PR):

instead of like this (the default without react-native-edge-to-edge):

Test plan

Run BottomTabsTest, verify that nothing changed in terms of edge-to-edge. Turn on 3-button navigation in Android setttings & verify that its view is transparent / matches the color of tab bar.

[kligarski]

LGTM, just please check that other example test screens work correctly.

[t0maboro]

1. we can remove

# This property is supported for RN >= 0.81.
# For RN < 0.81, react-native-edge-to-edge package is necessary.

from Example/android/gradle.properties either

2. Test2949 is using SystemBars from react-native-edge-to-edge and it's now crashing with

TurboModuleRegistry.getEnforcing(...): 'RNEdgeToEdge' could not be found. 

[kmichalikk]

@t0maboro

1. I intentionally left it here because old Example can be used with 0.80
2. My bad, the test needs to be removed then, because its purpose was to test the behavior with edge-to-edge

[kmichalikk]

ad 2. The test was created because screens were hardcoding some values for statusBar which would trigger overwriting system defaults when going back from another screen. The issue was fixed and to show the problem react-native-edge-to-edge API was used in order to change the color/translucency. Since we remove the library, the API is not available. We could rewrite the test to use core APIs, or, remove it as I did here. FWIW, the issue was orthogonal to the lib we remove. What would be more correct, considering https://github.com/software-mansion/react-native-screens-labs/pull/759 ?

cc @kkafar

[t0maboro]

ad 2. The test was created because screens were hardcoding some values for statusBar which would trigger overwriting system defaults when going back from another screen. The issue was fixed and to show the problem react-native-edge-to-edge API was used in order to change the color/translucency. Since we remove the library, the API is not available. We could rewrite the test to use core APIs, or, remove it as I did here. FWIW, the issue was orthogonal to the lib we remove. What would be more correct, considering software-mansion/react-native-screens-labs#759 ?

cc @kkafar

Thanks for the clarification. If only StatusBar is important for our case, I'd check if using the core API, we could achieve the same effect, e.g. https://reactnative.dev/docs/statusbar#barstyle . If both system bars are necessary, tbh I don't have a good recommendation as for now. If having the navigation bar in the TC is crucial and there's any reason to merge this PR quickly, I'm okay with temporarily disabling the example to unblock, but it needs to be resolved in the follow-up PR in the near future. Please link the issue ticket then.

[kkafar]

Looks good overall. I have few questions for code changes I do not understand. Please answer them.

I'll test the runtime once we're green on the code part.

[kkafar]

Regarding the Test2949 - we're no longer testing our API there. While it in some sense tests our integration with the react-native-edge-to-edge package I'm more in favour of dropping it.

[kkafar]

LGTM