Summary: releasing the viewControllers referred by _navigationController.viewControllers, which is also releasing the related views
Closes https://github.com/facebook/react-native/pull/3808
Reviewed By: svcscm
Differential Revision: D2604735
Pulled By: javache
fb-gh-sync-id: f202d155f04169f3f0f0ef26365b37b8525b6687
Summary: Make <Modal> visible by default and fix the scenario where we present a modal immediately when adding it to the view hierarchy.
Closes#3724Closes#2952
public
Reviewed By: nicklockwood
Differential Revision: D2595938
fb-gh-sync-id: 1571790d36fe486f1fbbed9f2d66f1e6add73d91
Summary: public
* No longer sends events when not observing valueChanged.
* Snaps to step value while dragging.
* Added additional example to UIExplorer.
Reviewed By: javache
Differential Revision: D2595594
fb-gh-sync-id: 1e92427d2ab2e71e4eb4a9a7a75cd0f5f4a3a529
Summary: This addresses #3577 and #3533. It adds the ability to test for subview.clipsToBounds.
Closes https://github.com/facebook/react-native/pull/3750
Reviewed By: svcscm
Differential Revision: D2592878
Pulled By: nicklockwood
fb-gh-sync-id: a87842b87dc0b455120e6007059b5d9a51a53ea2
Summary: added a new property named 'disable' to SliderIOS
this property prevents the user from being able to slide the slider
Closes https://github.com/facebook/react-native/pull/3730
Reviewed By: svcscm
Differential Revision: D2590154
Pulled By: javache
fb-gh-sync-id: b8a9c82c1b05eb813d9b81180cb1083b3f1852ac
Summary: We have a use case in the development of our app, where we are rendering some HTML content in a web view. But this content comes from the back end, and varies in height. There are other components on the page, so it's not a full screen web view. We need to dynamically alter the web view height, to fit the HTML content without scrolling, and to push the non-web view content on the screen down.
The solution I came up with, was to use the _loadingFinish callback, to send the evaluation of the injectedJavaScript property back to the React Native side. In my example above, injecting 'document.getElement(elementId).offsetHeight' evaluates to the height of the element, with margins and borders applied, and once returned to the RN app, it can change the app state and cause the web view height to be adjusted.
Closes https://github.com/facebook/react-native/pull/2753
Reviewed By: svcscm
Differential Revision: D2578688
Pulled By: mkonicek
fb-gh-sync-id: fc9c0d0f84994a409e037016a555534549f8957a
Summary: public
This has been broken for a while. The styles in the JS were being set on the container instead of the activity view itself.
Also, due to the way frames were set directly on layer properties instead of the view, resizing didn't work properly because the UIImageView inside the UIActivityView was not being realligned when the bounds changed. This also caused problems for other controls such as maps, where it was fixed with a method override, but the simpler solution is just to set the view center and bounds directly.
Before: {F23631143}
After: {F23631144}
Reviewed By: javache, tadeuzagallo
Differential Revision: D2575156
fb-gh-sync-id: e82e56d36648e7c924df77da1750e03037b5d5be
Summary: @public
This diff implements inline image support for <Text> nodes. Images are specified using <Image> tags, however all properties of the image are currently ignored apart from the source (including width/height styles).
Images are loaded asyncronously, and will trigger a text re-layout when they have loaded.
Reviewed By: @javache
Differential Revision: D2507725
fb-gh-sync-id: 59d0696d00a1bc531915cc35242a16b2dec96e85
Summary:
Currently, the system for mapping JS event handlers to blocks is quite clean on the JS side, but is clunky on the native side. The event property is passed as a boolean, which can then be checked by the native side, and if true, the native side is supposed to send an event via the event dispatcher.
This diff adds the facility to declare the property as a block instead. This means that the event side can simply call the block, and it will automatically send the event. Because the blocks for bubbling and direct events are named differently, we can also use this to generate the event registration data and get rid of the arrays of event names.
The name of the event is inferred from the property name, which means that the property for an event called "load" must be called `onLoad` or the mapping won't work. This can be optionally remapped to a different property name on the view itself if necessary, e.g.
RCT_REMAP_VIEW_PROPERTY(onLoad, loadEventBlock, RCTDirectEventBlock)
If you don't want to use this mechanism then for now it is still possible to declare the property as a BOOL instead and use the old mechanism (this approach is now deprecated however, and may eventually be removed altogether).
Summary:
`view.screen` can be nil if the view has not yet been added to the view hierarchy (e.g. new view), so we should use `[UIScreen mainScreen]` instead.
In the future, if we need to support multiple screens, one possible fix is to set the rasterization scale in didMoveToWindow/Superview. For now we have just one screen, though.
Closes https://github.com/facebook/react-native/pull/2334
Github Author: James Ide <ide@jameside.com>
Summary:
This diff removes calls to `-updateClippedSubviews` by only re-clipping when the scroll view moves by a certain number of pixels.
leeway = 50pt => 46.9% of calls removed
leeway = 10pt => 13.2% " " "
Summary:
Our events all follow a common pattern, so there's no good reason why the configuration should be so verbose. This diff eliminates that redundancy, and gives us the freedom to simplify the underlying mechanism in future without further churning the call sites.
Summary:
Moved the view creation & property binding logic out of RCTUIManager into a separate RCTComponentData class - this follows the pattern used with the bridge.
I've also updated the property binding to use pre-allocated blocks for setting the values, which is more efficient than the previous system that re-contructed the selectors each time it was called. This should improve view update performance significantly.
Summary:
The bridge implementation on React Android does not currently support boxed numeric/boolean types (the equivalent of NSNumber arguments on iOS), nor does Java support Objective-C's nil messaging system that transparently casts nil to zero, false, etc for primitive types.
To avoid platform incompatibilities, we now treat all primitive arguments as non-nullable rather than silently converting NSNull -> nil -> 0/false.
We also now enforce that NSNumber * objects must be explicitly marked as `nonnull` (this restriction may be lifted in future if/when Android supports boxed numbers).
Other object types are still assumed to be nullable unless specifically annotated with `nonnull`.
rocman
Dave Sibiski
Pieter De Baets
Nick Lockwood
Ivan Sorokin
Milen Dzhumerov
Andr3wHur5t
Chace Liang
Jay Garcia
Manuel Nakamurakare
Pawel Sienkowski
PJ Cabrera
Alexey Lang
Mike Armstrong
rxb
Aaron Chiu
Matt Mahoney
James Ide
Alexsander Akers
Zack Gomez
Tj
Brent Vatne
Kevin Gozali
