Summary:
Followup for #5822, addressing nits.
**Test Plan**
Travis CI (the author of #5822 tested the change).
Closes https://github.com/facebook/react-native/pull/10563
Differential Revision: D4081826
fbshipit-source-id: f3a2e1996bf02f81fecea6e53fe1c522b8c85689
Summary:
**Motivation**
I'm working on a project that uses React Native and needs to add direct synchronous bindings to native stuff through the JavaScriptCore C API. This is because it's performance-sensitive and would benefit from the quickest JS->C path. It does this using cross-platform C++ code that works on both iOS and Android. Most of the infrastructure for getting access to the JSC context is already in React Native actually, just had to add a few more things.
(lexs you mentioned to tag you in this pull request)
**Test plan**
Modify the JavaScriptCore context through the `JSContextRef` returned (eg. add an object at global scope) and verify that it exists in JavaScript.
Closes https://github.com/facebook/react-native/pull/10399
Differential Revision: D4080945
Pulled By: lexs
fbshipit-source-id: 6659b7a01e09fd84475adde183c1d3aca2d4cf09
Summary:
This PR adds a few unit tests to two devsupport classes, repectively
- JSDebuggerWebSocketClient
and
- JSPackagerWebSocketClient
Unit tests do not cover all methods / branches of the code. I solely focused on testing things having to do with JSON serialization as I am considering some quick refactoring to get rid of Jackson. Just prepping safety net with these few tests before starting.
Closes https://github.com/facebook/react-native/pull/10516
Differential Revision: D4067433
Pulled By: bestander
fbshipit-source-id: 97dc356c5eca5965914be074a7175cb48f038c4c
Summary: This is a simple hook to allow native side to fetch any file under the js root folder via packager. Historically, only the `main.jsbundle` is fetched via the packager. This then allows fetching local file like a json file that lives under the same root js folder
Reviewed By: yungsters
Differential Revision: D4037730
fbshipit-source-id: a2d6eb5e30d148fee573d413fc4036d0189f4938
Summary:
In most .gradle files, lines are indented with 4 spaces, but in some places they are indented with 2 spaces. This PR fixes them and enforce it by adding .editorconfig settings.
Closes https://github.com/facebook/react-native/pull/10267
Differential Revision: D4048335
Pulled By: lacker
fbshipit-source-id: df2f2556380f56672cf85690eb1c80e640a6aedf
Summary:
Implemented 2 TODOs from ReactART for Android:
- TODO(7255985): Use TextureView and pass Surface from the view to draw on it asynchronously instead of passing the bitmap (which is inefficient especially in terms of memory usage)
- TODO(6352067): Support dashes in ARTShape
We use ReactNativeART in our Android project.
1. Our app crashes sometimes on large screen smartphones with OutOfMemoryError. Crashes happen in ARTSurfaceShadowNode where TODO(7255985) was suggested in a comment in order to use memory more efficiently.
2. We needed dashes for drawing on ARTSurface.
**Test plan (required)**
I attach a screenshot of our app which shows dashed-lines and two ARTSurfaces on top of each other rendering exactly the same as in the pervious implementation of ARTSurface.
Closes https://github.com/facebook/react-native/pull/9486
Differential Revision: D4021303
Pulled By: foghina
fbshipit-source-id: 880175e841e3c598013982a7748b6fc691c7e8d6
Summary:
JS API very similar to web workers and node's child process.
Work has been done by somebody else for the Android implementation over at #7020, so we'd need to have these in sync before anything gets merged.
I've made a prop `messagingEnabled` to be more explicit about creating globals—it might be sufficient to just check for an onMessage handler though.
Closes https://github.com/facebook/react-native/pull/9762
Differential Revision: D4008260
fbshipit-source-id: 84b1afafbc0ab1edc3dfbf1a8fb870218e171a4c
Summary:
For some reason the transitive dependency isn't picked up in OSS, so make it hard.
bestander
Closes https://github.com/facebook/react-native/pull/10397
Differential Revision: D4024350
Pulled By: bestander
fbshipit-source-id: 32182857dcc88744ebf6ce0e5cf8eaee390bf067
Summary:
We're seeing a lot of crashes from `PermissionsModule` not being able to access the current activity, mentioned in #10009 and here: https://github.com/facebook/react-native/issues/9310#issuecomment-245657347
As far as I can tell, there is no way to ensure the Activity exists since the `ReactContext` holds a `WeakReference` to the current Activity and it appears that the lifecycle calls are happening in the right order (so not the same as #9310).
This will at least allow people to catch the error in JS and update the UI or try again as opposed to crashing the app.
I'm working on some bigger changes in #10221 but this is a smaller change and important to get fixed I think.
Closes https://github.com/facebook/react-native/pull/10351
Differential Revision: D4010242
fbshipit-source-id: 7a76973bb2b3e45817d4283917740c89a10ec0b0
Summary:
We've deprecated these APIs for quite a few releases and we should be able to get rid of them now.
Remove following deprecated modules/components
- AppStateIOS
- ActivityIndicatorIOS
- IntentAndroid
- SliderIOS
- SwitchAndroid
- SwitchIOS
- LinkingIOS
Update following modules to remove callback support
- Clipboard
- NetInfo
cc bestander
Closes https://github.com/facebook/react-native/pull/9891
Reviewed By: bestander
Differential Revision: D3974094
Pulled By: javache
fbshipit-source-id: 9abe32716bd85d0cea9933894f4447d53bdd5ee7
Summary: Instead of sending a list of modules over to JS on startup (and actually blocking script execution) instead provide a proxy object that constructs each of these lazily.
Reviewed By: lexs
Differential Revision: D3936979
fbshipit-source-id: 71bde822f01eb17a29f56c5e60e95e98e207d74d
Summary:
This allows the React JS code that's running from a Service (ie GcmListenerService) to check permissions (ie check for VIBRATE permissions before delivering notifications)
**Test plan (required)**
I've run this code from a GcmListenerService subclass, and it works correctly.
Closes https://github.com/facebook/react-native/pull/10229
Differential Revision: D3980853
fbshipit-source-id: 026b1f0c953d7093b5af2bec0b4a93ebd228f62e
Summary: This way `UIImplementation` can hold on to it and use it outside of calls from the `UIManagerModule`.
Reviewed By: lexs
Differential Revision: D3899774
fbshipit-source-id: 01e4956c4540bcdf30774a3f40a625e934714ee9
Summary:
Gradle unit tests started failing, this PR fixes mockito to be one specific version instead of loose 1.+
**Explain the **motivation** for making this change. What existing problem does the pull request solve?**
Circle CI started failing without any specific reason https://circleci.com/gh/facebook/react-native/tree/master, looks like a dependency error.
Alas it is, I can reproduce the error on master with clean caches.
**Test plan (required)**
After the fix:
```
bestander-pro:react-native bestander$ ./gradlew :ReactAndroid:testDebugUnitTest
Incremental java compilation is an incubating feature.
:ReactAndroid:preBuild UP-TO-DATE
:ReactAndroid:preDebugBuild UP-TO-DATE
:ReactAndroid:checkDebugManifest
:ReactAndroid:preDebugAndroidTestBuild UP-TO-DATE
:ReactAndroid:preDebugUnitTestBuild UP-TO-DATE
:ReactAndroid:preReleaseBuild UP-TO-DATE
:ReactAndroid:preReleaseUnitTestBuild UP-TO-DATE
:ReactAndroid:prepareComAndroidSupportAppcompatV72301Library UP-TO-DATE
:ReactAndroid:prepareComAndro
Closes https://github.com/facebook/react-native/pull/10239
Differential Revision: D3968396
Pulled By: matryoshcow
fbshipit-source-id: 63374261303fb98dc252898dfd5d3b3346597e4f
Summary:
When using webview on android and trying to link to an html file located on device (using `file://`), the application would crash with an error specifying that nothing handles the fired intent. This is due to [`33a1f28`](33a1f28654) which attempts to intercept all non `http(s)` links.
This is a simple fix so hopefully it can make it into the next stable release.
Closes https://github.com/facebook/react-native/pull/9668
Differential Revision: D3956485
fbshipit-source-id: 5a752abc21802a44e3a26e88669ccb6852076992
Summary:
Android (starting from API 23) supports "light status bar", thus it is possible to extend StatusBar and make `barStyle` property work not only for iOS, but also for Android.
This PR introduces one more `barStyle` option `dark-content` in addition to two existing ones (`default` and `light-content`).
Why there are 3 options instead of 2?
Two simple reasons:
1) to make all existing applications fully compatible with these changes;
2) the default status bar on Android is dark with white text and icons, while on iOS it is light with black text and icons on it. Thus the `default` option means something like "I don't really care, just apply the default color for this platform", while two other options (`light-content` and `dark-content`) allow to accurately specify the required result.
Closes https://github.com/facebook/react-native/pull/10185
Differential Revision: D3952346
fbshipit-source-id: 999a67614abff52321fbeb06298ebf1946c3f1d1
Summary:
The hack for the status bar height is not necessary any longer, so we can remove
all code related to it
Reviewed By: lexs
Differential Revision: D3943770
fbshipit-source-id: 2d70f4ea10dd76ea6e6a73bb6edccae388bde1c0
Summary:
On tablets, using Display.getRotation() returned ROTATION_0 or ROTATION_180 when it was in landscape, not portrait as it does on phones. This resulted in the Modal being sized incorrectly on tablets. Using size and comparing width and height is the only way I can think of to figure out the device orientation and give the modal the correct size. With this change, all issues listed in #7708 should be resolved.
**Test plan**
Modal should correctly fill screen on Android phone and tablet in both portrait and landscape.
Closes https://github.com/facebook/react-native/pull/10159
Differential Revision: D3950369
Pulled By: andreicoman11
fbshipit-source-id: 9488c4302a76cc48e4f8a4026eb5770d40b6e3d2
Summary:
I noticed that the example doesn't match the definition below.
cc bestander
Closes https://github.com/facebook/react-native/pull/10175
Differential Revision: D3943967
Pulled By: bestander
fbshipit-source-id: 6941d4d663e1fd42f8723cd722eb8a5712a63dc8
Summary: Provide a base `HeadlessJsTaskService` class that can be extended to run JS in headless mode in response to some event. Added `HeadlessJsTaskEventListener` for modules that are interested in background lifecycle events, and `HeadlessJsTaskContext` that basically extends `ReactContext` without touching it. The react instance is shared with the rest of the app (e.g. activities) through the `ReactNativeHost`.
Reviewed By: astreet
Differential Revision: D3225753
fbshipit-source-id: 2c5e7679636f31e0e7842d8a67aeb95baf47c563
Summary:
This changes modal behavior to resize when the keyboard appears/disappears.
Previously, the modal would not react in any way, or it would pan above to bring the
TextInput into view. Resizing is the correct behavior for android.
This is not trivial, as in, setting the flag, because of the combination of
react native laying out all views and the system reacting to the keyboard
appearance in a weird way. Namely:
- if `windowTranslucentStatus` is not set, the system will just call
`onSizeChanged` on the dialog's content view, and everything works nicely
- with `windowTranslucentStatus` set, the system will consider the dialog as a
full screen view that doesn't resize. In order for it to resize, the base
view of the layout needs to have
`setFitsSystemWindows(true)` called on it. This is needed, so that the system
can call layout on that base view with the new value of `paddingBottom` that
coincides with the height of the keyboard. Neat.
We fix this by wrapping our existing content view (mHostView) in a simple
FrameLayout that has `setFitsSystemWindows` set. That way, `mHostView` will have
`onSizeChanged` called on itself with the correct new size of the dialog.
This has the fortunate consequence of our layout now also getting `paddingTop` as the size of the
status bar, which means that we can remove the JS `top` hack in Modal, which
was necessary for no view getting drawn under the status bar.
This behavior is set as default, since that is the default correct Android behavior.
Reviewed By: astreet
Differential Revision: D3913784
fbshipit-source-id: 4378ada21f466dc7ac6e357abeca10b88009ca3f
Summary:
After D3876927 this test started failing on CI.
Locally we can't reproduce it, and it will take some time to understand what this test is intended for so that we could remove the variable part.
More investigation will follow, t13583009
Reviewed By: emilsjolander
Differential Revision: D3930334
fbshipit-source-id: 279f67eb5a77b5d4250afd48c8b94c828da6925c
Summary:
`ReactSwipeRefreshLayout` extends `SwipeRefreshLayout` which does not play nice with Android's touch handling system.
There are two problems:
1. `SwipeRefreshLayout` overrides and swallows `requestDisallowInterceptTouchEvent`, which means that Views underneath the `SwipeRefreshLayout` will not interact correctly with parent Views of
`SwipeRefreshLayout`. We've seen this in practice by H-ScrollViews having their touches intercepted by an enclosing ViewPager. This is fixed by passing `requestDisallowInterceptTouchEvent` up to the parents of `SwipeRefreshLayout`.
2. `SwipeRefreshLayout` overrides `onInterceptTouchEvent` and never calls `super.onInterceptTouchEvent`, therefore ignoring the value of `disallowIntercept`. That means that it will intercept some touches when it
shouldn't. One such case is again the H-ScrollView, which should receive all horizontal scrolls and stop `SwipeRefreshLayout` from intercepting any touch events after scrolling. Currently, after the H-ScrollView starts scrolling, it is still possible to get the `SwipeRefreshLayout` to detect and emit refresh events. This is fixed by checking and blocking on horizontal scrolls.
Reviewed By: foghina
Differential Revision: D3929893
fbshipit-source-id: e6f8050fb554e53318a7ca564c49c20cb5137df9
Summary:
Combining 2 animated values via addition, multiplication, and modulo are already supported, and this adds another one: division.
There are some cases where an animated value needs to invert (1 / x) another animated value for calculation. An example is inverting a scale (2x --> 0.5x), e.g.:
```
const a = Animated.Value(1);
const b = Animated.divide(1, a);
Animated.spring(a, {
toValue: 2,
}).start();
```
`b` will then follow `a`'s spring animation and produce the value of `1 / a`.
The basic usage is like this:
```
<Animated.View style={{transform: [{scale: a}]}}>
<Animated.Image style={{transform: [{scale: b}]}} />
<Animated.View>
```
In this example, the inner image won't get stretched at all because the parent's scaling gets cancelled out.
Also added this to native animated implementation.
Reviewed By: foghina, mmmulani
Differential Revision: D3922891
fbshipit-source-id: 32508956c4b65b2deb7574d50a10c85b4809b961
Summary:
This fixes measuring of items in the main axis of a container. Previously items were in a lot of cases measured with UNSPECIFIED instead of AT_MOST. This was to support scrolling containers. The correct way to handle scrolling containers is to instead provide them with their own overflow value to activate this behavior. This is also similar to how the web works.
This is a breaking change. Most of your layouts will continue to function as before however some of them might not. Typically this is due to having a `flex: 1` style where it is currently a no-op due to being measured with an undefined size but after this change it may collapse your component to take zero size due to the implicit `flexBasis: 0` now being correctly treated. Removing the bad `flex: 1` style or changing it to `flexGrow: 1` should solve most if not all layout issues your see after this diff.
Reviewed By: majak
Differential Revision: D3876927
fbshipit-source-id: 81ea1c9d6574dd4564a3333f1b3617cf84b4022f
Summary:
The styles that get applied to the Dialogs that are created in RN are set in
`themes.xml`, so I'm moving `windowTranslucentStatus` there as well so that we
have all of them collocated.
Reviewed By: astreet
Differential Revision: D3913402
fbshipit-source-id: 8f23e84fb017c8810634ffe8279171061292b351
Summary: Utilizes the build time annotation processor ReactModuleSpecProcessor that creates ReactModuleInfos for modules annotated with ReactModule and listed in the ReactModuleList annotation of LazyReactPackages. This way we don't have to instantiate the native modules to get the name, canOverrideExistingModule, and supportsWebWorkers values of the native modules. In the NativeModuleRegistry, we either store these ReactModuleInfos inside of a ModuleHolder or if we can't get the ReactModuleInfo for a specific module we instantiate that module to get the values (as we previously did) to store in a LegacyModuleInfo.
Reviewed By: astreet
Differential Revision: D3796561
fbshipit-source-id: f8fb9b4993f59b51ce595eb2f2c3425129b28ce5
Summary: Create separate buck library for image events so you can depend on that without depending on all of fresco
Reviewed By: brosenfeld
Differential Revision: D3907894
fbshipit-source-id: dca7a00d38b8b8bb5bab05b6883f6933fff3fa76
Summary:
Thanks for submitting a pull request! Please provide enough information so that others can review your pull request:
> **Unless you are a React Native release maintainer and cherry-picking an *existing* commit into a current release, ensure your pull request is targeting the `master` React Native branch.**
Explain the **motivation** for making this change. What existing problem does the pull request solve?
Prefer **small pull requests**. These are much easier to review and more likely to get merged. Make sure the PR does only one thing, otherwise please split it.
**Test plan (required)**
Demonstrate the code is solid. Example: The exact commands you ran and their output, screenshots / videos if the pull request changes UI.
Make sure tests pass on both Travis and Circle CI.
**Code formatting**
Look around. Match the style of the rest of the codebase. See also the simple [style guide](https://github.com/facebook/react-native/blob/master/CONTRIBUTING.md#style-guide).
For more info, see
Closes https://github.com/facebook/react-native/pull/10057
Differential Revision: D3913431
Pulled By: bestander
fbshipit-source-id: c761640839ce0e85196ffd7fc1a4e1c615078b06
Summary:
The dialog intercepts all key events, we need to redirect some of them to the
activity so that it can display the dev menu.
Reviewed By: foghina
Differential Revision: D3894503
fbshipit-source-id: fb62346a4da783f28a73c5a9e20566a451177629
Summary:
In some cases, the size of the content view changes before we add views to the
Modal. That means that the size of that view will not be set through the
`onSizeChanged` method. This can result in some apps apparently freezing,
since the dialog is created, but there are no actual views in it.
For that reason, we still need the ModalHostShadowNode to set the size of the
initial view, so that by the time the view gets added it already has the correct
size.
There's a new helper class so that we can reuse the modal size computation.
Reviewed By: foghina
Differential Revision: D3892795
fbshipit-source-id: 6a32bd7680a74d9912a21bfebb4ebd7a3c3c3e38
Summary:
Since API 18, Android locations have had the `isFromMockProvider()` function, to verify the validity of a provided location. This was one of many methods one could verify location data, but as of Marshmallow, the other ways of detecting if "Mock Locations" is on in developer settings has been deprecated or defunct.
This means some devices can only detect location mocking by exposing the method on the location object.
This change provides that exposure.
Closes https://github.com/facebook/react-native/pull/9390
Differential Revision: D3858205
Pulled By: bestander
fbshipit-source-id: 3bae429cc0596ea01926c5be204f4403e4a2414f
Summary: Some OEMs have changed out the default scroller implementation in their ScrollView. We now check for that case and handle it gracefully instead of crashing.
Reviewed By: foghina
Differential Revision: D3876492
fbshipit-source-id: 4d03b88c4972e939c8352eeb9f30275e3ecf76e2
Summary:
This adds support for `Animated.event` driven natively. This is WIP and would like feedback on how this is implemented.
At the moment, it works by providing a mapping between a view tag, an event name, an event path and an animated value when a view has a prop with a `AnimatedEvent` object. Then we can hook into `EventDispatcher`, check for events that target our view + event name and update the animated value using the event path.
For now it works with the onScroll event but it should be generic enough to work with anything.
Closes https://github.com/facebook/react-native/pull/9253
Differential Revision: D3759844
Pulled By: foghina
fbshipit-source-id: 86989c705847955bd65e6cf5a7d572ec7ccd3eb4
Summary:
The issue here is that on some devices (ie. Nexus 5X), under certain
circumstances, the text gets trimmed. A simple example is P56651885, where the
text is at the end of the line and some padding is set. Digging further with
P56659346, I found that only the paddings that have integer pixel values work
correctly: these are the values P56656483, and this is the screenshot of that
test: {F63510378}.
It turns out that when we set the padding directly on the TextView, we have to
convert from float to int, and use `ceil` in the process. We lose some precision
here, since the csslayout will use the float values to compute the layout of the
views. The ideal solution would be to just set the float values on the TextView,
but since we can't do that, we should avoid using `ceil` instead of `floor`
since it can have bad side-effects in some scenarios.
Going way back to D1881202 and D1710471, we started using `ceil` because that
is how android handles non-integer
density ratios: "This figure is the factor by which you should multiply the dp
units on order to get the actual pixel count for the current screen. (Then add
0.5f to round the figure up to the nearest whole number, when converting to an
integer.)", see https://developer.android.com/guide/practices/screens_support.html.
Reviewed By: emilsjolander
Differential Revision: D3876310
fbshipit-source-id: 701c05a8b1a045d4e06fc89ffe79162c1eecb62c
Summary:
With our previous fix to resize the Modal on orientation change, we broke the
computation of its size. The existing computation in `ModalHostShadowNode` was
in fact correct, and we were overriding it from `onSizeChanged`. By computing the
size of the Modal in `onSizeChanged` directly (and correctly), we fix this, and
simplify code by removing the `ModalHostShadowNode`.
Reviewed By: foghina
Differential Revision: D3863054
fbshipit-source-id: aaf4a8881798df4d2ab1dab882a9d9dfdc0a9342
Summary:
The original method getNativeProps in ViewManagerPropertyUpdater.java create more HashMaps and putAll method need to re-hash the key again to avoid conflicts. This pull request pass the map as params to avoid the problem and update ReactPropertyProcessor.java to adapt the change.
Closes https://github.com/facebook/react-native/pull/9916
Differential Revision: D3873152
fbshipit-source-id: 089840e5272265662cdbf58d88580f9203153b69
Summary:
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:
- 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. Right now I'm only reversing the drawing order as drawing only the header views last added a lot of complexity especially because of view clipping and I don't think it should cause issues.
- 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.
Closes https://github.com/facebook/react-native/pull/9456
Differential Revision: D3827366
Pulled By: fred2028
fbshipit-source-id: d346068734c5b987518794ab23e13914ed13b5c4
Summary:
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:
- 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. Right now I'm only reversing the drawing order as drawing only the header views last added a lot of complexity especially because of view clipping and I don't think it should cause issues.
- 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.
Closes https://github.com/facebook/react-native/pull/9456
Differential Revision: D3827366
fbshipit-source-id: cab044cfdbe2ccb98e1ecd3e02ed3ceaa253eb78
Summary: Introduce `overflow:scroll` so that scrolling can be implemented without the current overflow:visible hackiness. Currently we use AT_MOST to measure in the cross axis but not in the main axis. This was done to enable scrolling containers where children are not constraint in the main axis by their parent. This caused problems for non-scrolling containers though as it meant that their children cannot be measured correctly in the main axis. Introducing `overflow:scroll` fixes this.
Reviewed By: astreet
Differential Revision: D3855801
fbshipit-source-id: 3c365f9e6ef612fd9d9caaaa8c650e9702176e77
Summary: Introduce `overflow:scroll` so that scrolling can be implemented without the current overflow:visible hackiness. Currently we use AT_MOST to measure in the cross axis but not in the main axis. This was done to enable scrolling containers where children are not constraint in the main axis by their parent. This caused problems for non-scrolling containers though as it meant that their children cannot be measured correctly in the main axis. Introducing `overflow:scroll` fixes this.
Reviewed By: astreet
Differential Revision: D3855801
fbshipit-source-id: 6077b0bcb68fe5ddd4aa22926acab40ff4d83949
Summary: This is to be able to depend on ReactClippingViewGroup from BaseViewManager. Devs using ReactClippingViewGroup may need to update their imports when updating past this commit.
Reviewed By: lexs
Differential Revision: D3835328
fbshipit-source-id: 290c08b130d837e553b68a90377bd9a30b7ec6dc
Summary:
This automatically changes the size of the modal by listening to dialog size changes and propagating
those changes through UIManager.
In detail: I've looked into three ways of doing this:
1. Send `onSizeChanged` events/info from the View to the CSSNode directly. This is kinda hacky because you would need to hold a reference to the CSSNode somewhere, either in the View or in the ViewManager. But then you'll have to take care of the lifecycle of the CSSNode, so that you don't update it after it has been dismissed. Not great.
2. The version we went for, is to just update the size of the corresponding CSSNode in the same way we do it for root nodes: we inform the UIManager that the size of the root node has changed, and it will propagate that change, triggering a `dispatchViewUpdates` if none is underway, so that the layout is updated.
3. The other solution we thought of is to treat the Modal as a root view. This would mean rendering an application with the tag of the Modal as the root of the application. That tag would be received by calling some method into UIManager and ReactModalHostManager to create a new RootView, create a Dialog and plop the root view in it. The idea was to maintain the JS API that we now have, but make the implementation more correct (ie. since both RootView and the Modal must deal with touch handling), and could have other benefits (ie. no hacks necessary for making the inspector work on top of modals). However, the change is not trivial and I don't know just how much code would have to be changed to make this work correctly. We might revisit this at a later stage, after we've done more work on having several root views at the same time in the app.
Reviewed By: foghina
Differential Revision: D3841379
fbshipit-source-id: f5e363e27041b785cf44eb59da04bc789306ddb9
Summary:
Setting the line height with the help of Android-provided StaticLayout is incorrect. A
simple example app will display the following when `setLineSpacing(50.f, 0.f)`
is set: {F62987699}. You'll notice that the height of the first line is a few
pixels shorter than the other lines.
So we use a custom LineHeightSpan instead, which needs to be applied to the text
itself, and no height-related attributes need to be set on the TextView itself.
Reviewed By: lexs
Differential Revision: D3841658
fbshipit-source-id: 7257df4f1b2ce037554c7a7a5ca8f547a2056939
Summary:
This is just D3835023 again since it got reverted, plus the fix from D3841918 baked in. Here's the old summary:
We never actually closed the websocket connection. Furthermore, upon calling `closeQuietly()`, `onClose()` is called, which does `reconnect()`. This results in ReactInstanceManager leaking after calling `destroy()` and nullifying all references to it.
To fix this I made sure `closeQuietly()` actually closes the connection for good, and made sure we actually call it when destroying an instance.
Reviewed By: AaaChiuuu
Differential Revision: D3849353
fbshipit-source-id: e1ce5e2d5840bfbd42a13043c3cc8c617e9fa64a
Emily Janzer
Emil Sjolander
Martin Konicek
Giuseppe Ottaviano
Nikhilesh Sigatapu
Andrew Y. Chen
Michał Gregorczyk
Benoit Lemaire
Aaron Chiu
Kevin Gozali
Yoshiya Hinosawa
Dmitry Petukhov
Jacob Parker
Tim Yung
Felix Oghina
Konstantin Raev
Connor McEwen
Satyajit Sahoo
Pieter De Baets
Mike Lambert
Andy
Hoa Dinh
Alexander Pantyuhov
Andrei Coman
Dave Pack
Nicolas Charpentier
Chris Hopman
Marc Horowitz
Don Yu
Aaron Chiu
Brad Daily
Gant Laborde
Andy Street
Janic Duplessis
ransj
Fred Liu
leeight
