I was getting the following compilation errors when I pulled in this repo.
```
error: unmappable character for encoding ASCII
```
The root cause seems to be the character below was not from the ASCII set.
The docs do not state that react-native-screens is also used by default for the tab and drawer navigators. I updated the docs to include that. I didn't see support in any of the other navigators that I looked at, but if there are any others, we should update the documentation for them as well.
Add suport to gradle 4.10.1 or high!
The new version of android studio 3.3 recommendete to update gradle project to 4.10.1
> To take advantage of the latest features, improvements, and security fixes, we strongly recommend that you update the Android Gradle plugin to version 3.3.0 and Gradle to version 4.10.1. [Release notes ](https://developer.android.com/studio/releases/gradle-plugin)
>Android plugin 3.2.0 and higher now support building the Android App Bundle—a new upload format that defers APK generation and signing to compatible app stores, such as Google Play. With app bundles, you no longer have to build, sign, and manage multiple APKs, and users get smaller, more optimized downloads. [Learn more](https://developer.android.com/guide/app-bundle/?utm_source=android-studio)
but if the upgrade to the new Android gradle warning come up, becouse was obsoleted
> WARNING: API 'variant.getJavaCompile()' is obsolete and has been replaced with 'variant.getJavaCompileProvider()'.
> It will be removed at the end of 2019.
> For more information, [see ](https://d.android.com/r/tools/task-configuration-avoidance.)
> To determine what is calling variant.getJavaCompile(), use -Pandroid.debug.obsoleteApi=true on the command line to display a stack trace.
Changelog:
----------
[Android] [Deprecated] - fix warinings obsolete to update to gradle 4.10.1 or high
Test Plan:
----------
change gradle-wrapper.proprerties:
`- distributionUrl=https\://services.gradle.org/distributions/gradle-4.4-all.zip`
`+ distributionUrl=https\://services.gradle.org/distributions/gradle-4.10.1-all.zip`
and in build.gradle
` - classpath 'com.android.tools.build:gradle:3.2.0'`
`+ classpath 'com.android.tools.build:gradle:3.3.0'`
for warnnings starts, use this change and fix the problem! =)
This fixes crash on Expo client which is wrapping Activity prior to passing it as a context to the root view.
After my recent change in the logic on how we access main activity we know extract the reference to it using `getContext` from the root view. Previously we were using `getTopLevelActivity` which wasn't working well in the cases where other non-react-native activities were transitioning in or out. The new approach however turned out not to be the best as for example expo client does not pass activity instance as a context directly to the root view. Instead the activity class is wrapped in ContextThemeWrapper ([see it here](41458d1de9/android/expoview/src/main/java/versioned/host/exp/exponent/ReactUnthemedRootView.java (L13))).
We now try to unwrap the context if it is not a fragment activity using `getBaseContext`
This fixes https://github.com/expo/expo/issues/3191
Previously we weren't triggering transaction finish when going from none active screens to 1 active screen. This turns out to be the case in tab navigator where for a sub-frame moment the active state changes for the current screen to `NO` and then new screen isn't active yet.
Fixes#53
This change makes us reach to fragment manager only when screen container is attached to window (and therefore we are sure that the current activity is react one). The problem reported in #33 was due to the fact we'd do that when container is instantiated which does not necessarily mean that react activity is in foreground. We didn't need to actually access fragment manager while not in foreground so this change removes fragmentManager as a member and we get it directly from context when needed.
Supposedly fixes#33
This change adds an ability for screen container on Android to apply the correct mechanism for transparent layer blending. This is specifically important as screens are usually a complex views that may displays many layers and while transitioning often opacity is used to animate these. When we detect screen transitioning we (a) turn on offscreen alpha compositing (which makes the opacity being applied for the whole screen layer at once instead of making all the children semi-transparent) and also (b) turn on hardware layer that makes offscreen compositing render to GPU (which is both faster and consumes only GPU memory).
In addition to that change we also need to disable wrapping Screen's children with View, as in such a case opacity is applied on the underlying View instead of a Screen. That workaround has been added because of a bug in Animated library and fixed in RN 0.57+
This is a follow up to #48 which makes Screen component ignore setting of pointerEvents. As it turns out react-navigation tries to set this setting and in addition to handling it manually we also need to prevent it to be set via React prop.
This change automates first responder restoring when screen is deactivated and the activated back (e.g. when we push new screen on top and then go back). In addition we disable pointerEvent setting for the Screen component as changes made to that prop would cause underlying views to resign responder before we can remember it. Because of that we add an automatic handling for pointer events for the Screen component that disables all touch interactions when screen is transitioning.
With this change in the screens that are being transitioned get detach+attach events similarily to how it is done in UINavigationController. This allows views underneath to get notified that the transition is started and react to it when necessary (e.g. hide keyboard)
