Summary:
It seems like the `resizeMode` propType was missing from `Image.android.js`, this PR adds it.
I caught by trying to use `Image.propTypes.resizeMode` on Android, and getting a warning because it was `undefined`.
It's not supposed to break anything, maybe pop a few warnings but not much more.
**Test Plan:**
- Launched UIExplorer
Closes https://github.com/facebook/react-native/pull/7355
Differential Revision: D3648559
fbshipit-source-id: a4397938d14c11ded909d6bf4652a4b0fcebed3b
Summary: Mirrors Android's support for multiple sources for Image, allowing us to fetch new images as the size of the view changes.
Reviewed By: mmmulani
Differential Revision: D3615134
fbshipit-source-id: 3d0bf2b75f63a4379e0e49f2dab9aea351b31d5f
Summary:
There is a conflict between RCTImageLoader and RCTAssetsLibraryRequestHandler on handling images, which was caused by making RCTPhotoLibraryImageLoader able to handle assets library requests as well. This gives more priority to RCTImageLoader instead.
Fixes#9031.
Reviewed By: mmmulani
Differential Revision: D3627451
fbshipit-source-id: 7ffd2c66f43ce1479c9a117768fb2d29f9d0dc08
Summary:
Before this PR, ```RCTImageLodaer```'s Cache was too big(200MB on disk) and It doesn't work with HTTP Cache-Control header. So to provide dynamic image, the users must have to add random value on url( ex. adding current date) to avoid cache.
So I change that cache system to default ```NSURLRequest```'s cache system, which is well-working with HTTP specs. As the discussion on this issue #7571 , making custom cache policy processor is not ready yet and useless, over-tech things, I think.
Even we have no plan about image cache system(or would change plan later), before having a nice plan, I think we should let user use image module with common HTTP Specs.
So I remove custom ```NSURLCache```, and make logic like below,
1. try fetch image,
2. on response, get ```Date``` on response's header and make ```cacheKey``` with ```Date```.
> (why? because if ```NSURLRequest```'s response was cached, the response's ```Date``` header dosen't change.)
3. find decoded imag
Closes https://github.com/facebook/react-native/pull/8235
Reviewed By: bnham
Differential Revision: D3469086
Pulled By: javache
fbshipit-source-id: 35a5552cda6e6c367481020bbf3c28eb4a9d0207
Summary:
This uses `[UIImage imageNamed:]` to load local assets that are bundled using `require('../image/path.png')` and makes sure it is done synchronously on the main queue to prevent images from flickering. This improves user experience a lot when using large local images and prevents icon flickers to match the behaviour of most native apps.
This adds to methods to the ImageLoader protocol, one to tell if the image loader must be executed on the url cache queue and one to tell if the result of the image loader should be cached. I then use these to make the LocalImageLoader bypass the url cache queue and avoid caching images twice.
Note that this doesn't affect debug builds since images are loaded from the packager.
I'm not sure if we want to still support async loading of local images as I'm not sure how much of a perf difference this will make. Maybe someone at fb can benchmark this see how it affects your apps but there wasn't a noticeable one in mine. Also I only enabled this for loading png and jpg im
Closes https://github.com/facebook/react-native/pull/8102
Reviewed By: bnham
Differential Revision: D3433647
Pulled By: javache
fbshipit-source-id: 37bd6aff20c0465c163db3cdbcaeaedff55f7b1f
Summary:
Addresses this comment: https://github.com/facebook/react-native/issues/2296#issuecomment-232446493
This pull request adds the `center` value to `ImageResizeMode`.
When set, it will center the image within its frame.
If the image is larger than its frame, the image is downscaled while maintaining its aspect ratio.
That is how the Android implementation works, too.
Sorry, don't have time to write tests. 😢
Any reviewers should make sure `RCTTargetRect` returns the correct value when:
- the image is smaller than its frame (ie: no downscaling needed)
- the image is larger than its frame (should be downscaled to avoid clipping)
Closes https://github.com/facebook/react-native/pull/8792
Differential Revision: D3586134
Pulled By: javache
fbshipit-source-id: 78fb8e5928284003437dac2c9ad264fa584f73ec
Summary:
I would like to believe it's some black magic code but no it's just a typo.
Closes https://github.com/facebook/react-native/pull/8712
Differential Revision: D3550809
fbshipit-source-id: 00a7ba1cbcd36e29af44cdefd5fc1148d11d26e3
Summary: This removes `node_modules/react` from the list of directories that are used for haste module resolutions. Modules required from React are now imported with `require('react/lib/…')`.
Reviewed By: astreet
Differential Revision: D3509863
fbshipit-source-id: 32cd34e2b8496f0a6676dbe6bb1eacc18124c01e
Summary:
Hi there,
Here is a fix for #7538 (and #5085).
I had originally discovered this issue when using `resizeMode` through the style props. Although this might arguably be an incorrect usage (see https://github.com/facebook/react-native/issues/4759#issuecomment-164301166) the same issue would happen with the `tintColor` and `overlayColor` style props.
To test this, you can render the following:
```jsx
const imageContainerStyle = {width: 100, height: 100, backgroundColor: 'green', marginLeft: 10, marginTop: 10, };
const imageStyle = {flex: 1, width: undefined, height: undefined, resizeMode: 'contain', };
return (
<View style={styles.container}>
<View style={imageContainerStyle}>
<Image style={imageStyle} source={
{uri:'http://resizing.flixster.com/DeLpPTAwX3O2LszOpeaMHjbzuAw=/53x77/dkpu1ddg7pbsk.cloudfront.net/movie/11/16/47/11164719_ori.jpg'}
}>
</Image>
</View>
<View style={imageContainerStyle}>
<Image style={imageStyle} source={
{
Closes https://github.com/facebook/react-native/pull/8410
Differential Revision: D3488010
Pulled By: andreicoman11
fbshipit-source-id: e9d1283cce8426c8878f9c3c66a43a2141232277
Summary:
GIF Image will disappear after press the home button and return back.
Set `removedOnCompletion` to be`false` will fix all `CAAnimation` disappear like stopping after going into the background.
Closes https://github.com/facebook/react-native/pull/7612
Differential Revision: D3481403
fbshipit-source-id: 101bded300f5e34bb53ec6c54a40eb5aece22fba
Summary:
This adds a new resize mode for iOS 'repeat' that tiles the image over it's frame. This allow to easily create a view with a repeating background pattern which there is no way to do at the moment without including a bunch of different sized assets.
I'm not 100% sure it should be a resizeMode or a separate prop but I went with resizeMode since it made more sense to me and the are not really any use cases where we'd want to use this with another resizeMode other than 'stretch'.
**Test plan**
Tested mainly by adding a UIExplorer example, also tested that changing the resizeMode prop from and to 'repeat' worked properly.
I'd like to implement this on Android too but it is a bit trickier since Fresco's ImageView doesn't support image tiling and would require submitting a PR there too :(
Closes https://github.com/facebook/react-native/pull/7968
Differential Revision: D3469119
Pulled By: javache
fbshipit-source-id: ab9dbfe448a5b0771dbf0c41fcceeb366210f583
Summary:
This adds support for specifying multiple sources for an image component, so that native can choose the best one based on the flexbox-computed size of the image.
The API is as follows: the image component receives in the `source` prop an array of objects of the type `{uri, width, height}`. On the native side, the native component will wait for the layout pass to receive the width and height of the image, and then parse the array to find the best fitting one. For now, this does not support local resources, but it will be added soon.
To see how this works and play with it, there's an example called `MultipleSourcesExample` under `ImageExample` In UIExplorer.
Reviewed By: foghina
Differential Revision: D3364550
fbshipit-source-id: 66c5aeb2794f2ffeff8da39a9c0b95155fb2d41f
Summary:
Under rare and as-yet-to-be determined circumstances, images can sometimes fail to load/download and get "stuck", without producing an error.
Because the `RCTNetworkTask` for these images is stuck in the "in progress" state, they clog up the RCTImageLoader task queue, which has a limit of 4 concurrent in-progress tasks.
This was previously masked by the fact that we automatically cancelled image requests when the RCTImageView moved offscreen, but we no longer do that.
This diff adds logic to detect some types of stuck task and remove them, thereby unblocking the queue. I've also restored the functionality of cancelling downloads for offscreen images (but not unloading the image itself) so that stuck images will be cancelled when you move to another screen, instead of using up space in the queue forever.
Reviewed By: fkgozali
Differential Revision: D3398105
fbshipit-source-id: 75ee40d06a872ae8e1cb57f02f9cad57c459143c
Summary:
Now that we no longer have a separate NetworkImageView implementation, we can remove that code path from Image.js
I've also moved the prefetch method into RCTImageViewManager for consistency with the getImageSize method, which means we no longer need to export the RCTImageLoader module to js.
Reviewed By: javache
Differential Revision: D3398157
fbshipit-source-id: fbbcf90a61549831ad28bad0cb3b50c375aae32c
Summary:
As per https://twitter.com/olebegemann/status/738656134731599872, our use of "main thread" to mean "main queue" seems to be unsafe.
This diff replaces the `NSThread.isMainQueue` checks with dispatch_get_specific(), which is the recommended approach.
I've also replaced all use of "MainThread" terminology with "MainQueue", and taken the opportunity to deprecate the "sync" param of `RCTExecuteOnMainThread()`, which, while we do still use it in a few places, is incredibly unsafe and shouldn't be encouraged.
Reviewed By: javache
Differential Revision: D3384910
fbshipit-source-id: ea7c216013372267b82eb25a38db5eb4cd46a089
Summary:
Allows developers to specify headers to include in the HTTP request
when fetching a remote image. For example, one might leverage this
when fetching an image from an endpoint that requires authentication:
```
<Image
style={styles.logo}
source={{
uri: 'http://facebook.github.io/react/img/logo_og.png',
headers: {
Authorization: 'someAuthToken'
}
}}
/>
```
Note that the header values must be strings.
Works on iOS and Android.
**Test plan (required)**
- Ran a small example like the one above on iOS and Android and ensured the headers were sent to the server.
- Ran a small example to ensure that \<Image\> components without headers still work.
- Currently using this code in our app.
Adam Comella
Microsoft Corp.
Closes https://github.com/facebook/react-native/pull/7338
Reviewed By: javache
Differential Revision: D3371458
Pulled By: nicklockwood
fbshipit-source-id: cdb24fe2572c3ae3ba82c86ad383af6d85157e20
Summary:
Previously, only Text and Image could be nested within Text. Now, any
view can be nested within Text. One restriction of this feature is
that developers must give inline views a width and a height via
the style prop.
Previously, inline Images were supported by using iOS's built-in support
for rendering images with an NSAttributedString via NSTextAttachment.
However, NSAttributedString doesn't support rendering arbitrary views.
This change adds support for nesting views within Text by creating one
NSTextAttachment per inline view. The NSTextAttachments act as placeholders.
They are set to be the size of the corresponding view. After the text is
laid out, we query the text system to find out where it has positioned each
NSTextAttachment. We then position the views to be at those locations.
This commit also contains a change in `RCTShadowText.m`
`_setParagraphStyleOnAttributedString:heightOfTallestSubview:`. It now only sets
`lineHeight`, `textAlign`, and `writingDirection` when they've actua
Closes https://github.com/facebook/react-native/pull/7304
Reviewed By: javache
Differential Revision: D3365373
Pulled By: nicklockwood
fbshipit-source-id: 66d149eb80c5c6725311e1e46d7323eec086ce64
Summary: The decoded image cache was previously static, meaning that cached images could persist beyond the lifetime of the module. This resulted in some flakiness in the RCTImageLoaderTests due to the loader returning cached image instanced from previous tests instead of the correct instance.
Reviewed By: bestander
Differential Revision: D3346329
fbshipit-source-id: 375af8894cef1c5b6303c6cdfd7eb57ebcfe3251
Summary:
Some apps are complaining about flashing images when performing navigation transitions. An example issue would be:
1. Load a master list view with many images
2. Click on an image to go to a detail view
3. Go back to the master list view
At step (3), users see a number of images flash from a placeholder image back to the final image because `-[RCTImageView didMoveToWindow]` calls `clearImage` when the image view exits the view hierarchy between (1) and (2) and calls `reloadImage` (which sets the image property asynchronously) when the image view re-enters the view hiearchy between (2) and (3).
This diff fixes the issue by being less aggressive about clearing image contents. It only clears image contents when the app receives a memory warning or the app goes into the background.
For comparison, CKNetworkImageComponent in ComponentKit doesn't have this purging behavior at all.
Reviewed By: javache
Differential Revision: D3325009
fbshipit-source-id: efca10099cdfdb49afbb3f550854d4b8a40511d0
Summary:
In RN we cache image data after loading/downloading an image, however the data we store is the compressed image data, and we decode this asynchronously each time it is displayed.
This can lead to a slight flicker when reloading image components because the decoded image is discarded and then re-decoded.
This diff adds a small (5MB) cache for decoded images so that images that are currently on screen shouldn't flicker any more if the component is reloaded.
Reviewed By: bnham
Differential Revision: D3305161
fbshipit-source-id: 9969012f576784dd6f37d9386cbced2df00c3e07
Summary:
This works with D3305161 to minimize image flashing. After D3305161, the completion handler passed to `-[RCTImageLoader loadImageWithoutClipping:size:scale:resizeMode:progressBlock:completionBlock:]` may be called back on the main queue in the case of a cached image. In this case, we want to set the image view's image property synchronously rather than on the next runloop iteration via dispatch_async. This minimizes the amount of image flashing the user sees when displaying a cached image.
The exception to this case is for blurred images. A blur can be an expensive (taking multiple ms on the CPU), so we always make sure to perform the blur off the main queue even if the image is cached and the callback came back on the main queue.
Reviewed By: nicklockwood
Differential Revision: D3310176
fbshipit-source-id: 6820782527b65e4956879cf06e8ed2c09c622a58
Summary:
Previously, only Text and Image could be nested within Text. Now, any
view can be nested within Text. One restriction of this feature is
that developers must give inline views a width and a height via
the style prop.
Previously, inline Images were supported by using iOS's built-in support
for rendering images with an NSAttributedString via NSTextAttachment.
However, NSAttributedString doesn't support rendering arbitrary views.
This change adds support for nesting views within Text by creating one
NSTextAttachment per inline view. The NSTextAttachments act as placeholders.
They are set to be the size of the corresponding view. After the text is
laid out, we query the text system to find out where it has positioned each
NSTextAttachment. We then position the views to be at those locations.
This commit also contains a change in `RCTShadowText.m`
`_setParagraphStyleOnAttributedString:heightOfTallestSubview:`. It now only sets
`lineHeight`, `textAlign`, and `writingDirection` when they've actua
Closes https://github.com/facebook/react-native/pull/7304
Differential Revision: D3269333
Pulled By: nicklockwood
fbshipit-source-id: 2b59f1c5445a4012f9c29df9f10f5010060ea517
Summary:
`tintColor`, even in style, works on Android; this must be some old comment but that confused me when reading the docs.
**Test plan:**
- Launched website locally
Closes https://github.com/facebook/react-native/pull/7465
Differential Revision: D3278166
fbshipit-source-id: 4e986e0f2a9ba05de4404b93d28687596fbb4fad
Summary: Fixed a crash where making a network request with unrecognized/unsupported scheme would crash by attempting to insert a nil RCTNetworkTask into an array.
Reviewed By: javache
Differential Revision: D3275810
fb-gh-sync-id: be208c6bf87d882209901b850dcc25da4ba79a08
fbshipit-source-id: be208c6bf87d882209901b850dcc25da4ba79a08
Summary: To prevent layout popping, when inserting images inside text we would render a blank placeholder image while the real image was loading. It turns out that this isn't necessary, as we can just specify the size of the image without having an actual image to display.
Reviewed By: javache
Differential Revision: D3212766
fb-gh-sync-id: e98851b32a2d0ae809fc0a4be47e6b77f3b17996
fbshipit-source-id: e98851b32a2d0ae809fc0a4be47e6b77f3b17996
Summary:Split out from PR #4252 - kmagiera I've made the changes to how the radii arrays are allocated, is the approach I've taken correct? also it looks like ImageStylePropTypes are needed so I left them in for the moment. I suppose this pull request will only be valid if iOS supports image corner radii, but at least it's here if/when needed. Attached an image of how it handles the existing case:
Closes https://github.com/facebook/react-native/pull/5197
Differential Revision: D3138725
Pulled By: mkonicek
fb-gh-sync-id: df772fd07fe85386ae4c681f9e79a19d2316d38b
fbshipit-source-id: df772fd07fe85386ae4c681f9e79a19d2316d38b
Summary:Adds `Image.prefetch` to prefetch remote images before they are used in an actual `Image` component. This is based off of #4420 by sospartan and skevy's work.
Closes https://github.com/facebook/react-native/pull/6774
Differential Revision: D3153729
Pulled By: bestander
fb-gh-sync-id: ef61412e051a49b42ae885edce7905a8ca0da23f
fbshipit-source-id: ef61412e051a49b42ae885edce7905a8ca0da23f
Summary:Remove Trailing Spaces.
Why:
Sometimes there are conflicts with trailing spaces
Saves space
Those whose tools automatically delete them will have their pr watered down with trailing space removal
Closes https://github.com/facebook/react-native/pull/6787
Differential Revision: D3144704
fb-gh-sync-id: d8a62f115a3f8a8a49d5b07f56c540a02af38cf8
fbshipit-source-id: d8a62f115a3f8a8a49d5b07f56c540a02af38cf8
Summary:Adds a `center` option to `Image`'s `resizeMode` prop, which doesn't enlarge images.
This is how it looks in UIExplorer:
{F60386921}
Reviewed By: dmmiller
Differential Revision: D3064284
fb-gh-sync-id: 79cd2da8f44c5b3da2e42d3bebf3131335f53c28
shipit-source-id: 79cd2da8f44c5b3da2e42d3bebf3131335f53c28
Summary: This diff introduces a blur radius property to the Image component on ios. If the radius specified is greater then 0 then native will apply a blur filter to the image
Reviewed By: nicklockwood
Differential Revision: D3054671
fb-gh-sync-id: d7a81ce5a08a3a2091c583f5053c6a86638b21b2
shipit-source-id: d7a81ce5a08a3a2091c583f5053c6a86638b21b2
Summary:When using the `Image` component with a `src` property instead of `source` the component fails silently. vjeux suggested to add a warning (https://twitter.com/Vjeux/status/704509214937317378).
Tested with the UIExplorer example on iOS and Android simulators.
Closes https://github.com/facebook/react-native/pull/6221
Differential Revision: D3011659
Pulled By: mkonicek
fb-gh-sync-id: c9bae6c802c173ef85d9c4552747db994c58906e
shipit-source-id: c9bae6c802c173ef85d9c4552747db994c58906e
Summary:Initializing native modules can block the main thread for tens of milliseconds when it starts up, making it difficult to instantiate the bridge on demand without causing a performance blip.
This diff splits up the initialization of modules so that - although they still happen on the main thread - they don't block the thread continuously.
Reviewed By: javache
Differential Revision: D2965438
fb-gh-sync-id: 38c9c9d281e4672b5874d68b57d4c60d1d268344
shipit-source-id: 38c9c9d281e4672b5874d68b57d4c60d1d268344
Summary:Follow-up to https://github.com/facebook/react-native/pull/5084
This…
- changes all requires within RN to `require('fbjs/lib/…')`
- updates `.flowconfig`
- updates `packager/blacklist.js`
- adapts tests
- removes things from `Libraries/vendor/{core,emitter}` that are also in fbjs
- removes knowledge of `fbjs` from the packager
Closes https://github.com/facebook/react-native/pull/5084
Reviewed By: bestander
Differential Revision: D2926835
fb-gh-sync-id: 2095e22b2f38e032599d1f2601722b3560e8b6e9
shipit-source-id: 2095e22b2f38e032599d1f2601722b3560e8b6e9
Summary:Images cropped using the ImageEditor were always given an alpha channel, even if opaque.
This causes them to be saved as PNGs instead of JPEGs (increasing memory and bridge traffic) and also causes unnecessary blending when they are drawn.
Reviewed By: fkgozali
Differential Revision: D2982682
fb-gh-sync-id: b65f361efd78e35f259836111b38d914bae49847
shipit-source-id: b65f361efd78e35f259836111b38d914bae49847
Summary:Diff D2647083 cleaned up image editing related logics and introduced an image cropping bug.
The bug is that the result of the image cropping will be wrong if displaySize is specified.
In particular, in Ads Manager App, we generate thumbnail by calling the image cropping function with displaySize set.
With this bug, the thumbnail we get is not correct.
This diff fixed the bug by replacing `image` with `croppedImage`. It should be a typo from D2647083
Reviewed By: zjj010104
Differential Revision: D2947730
fb-gh-sync-id: df7c7f3ddac5b053425db884f808e27b8418116e
shipit-source-id: df7c7f3ddac5b053425db884f808e27b8418116e
Summary:
should use UIGraphicsEndImageContext rather than UIGraphicsGetCurrentContext
public
Reviewed By: nicklockwood, chaceliang
Differential Revision: D2875657
fb-gh-sync-id: 0fa059e2da3d0bb1ffe5fe50a1bdaeddafc2bbfa
Summary:
After the release of 0.14, static images should be placed in the source code tree and then required as explained in the [Images guide] (https://facebook.github.io/react-native/docs/images.html). This pull request updates the image documentation and examples to the new asset system. UIExplorer tested on iOS and Android.
Closes https://github.com/facebook/react-native/pull/4987
Reviewed By: svcscm
Differential Revision: D2796276
Pulled By: bestander
fb-gh-sync-id: 732ffa2f136391bb8a3e40a54b5b1ff5022c97f2
Summary:
In Android, Fresco's default rounding corners support mode is BITMAP_ONLY which doesn't work in all cases (such as animated GIF's, some scale types, etc.).
Specifying the new "overlayColor" property on an Image will cause Fresco to switch to the other rounding corners mode, OVERLAY_COLOR, and will draw rounded corners by overlaying the solid color specified.
Fresco's behaviour is explained here: http://frescolib.org/docs/rounded-corners-and-circles.html
Closes https://github.com/facebook/react-native/pull/5366
Reviewed By: svcscm
Differential Revision: D2854696
Pulled By: mkonicek
fb-gh-sync-id: 251701ee8a64acbfc22694e9d4661c40eef75725
Summary:
public
Previously, `<Image>` elements embedded inside `<Text>` ignored all style attributes and props apart from `source`. Now, the `width`, `height` and `resizeMode` styles are observed. I've also added a transparent placeholder to be displayed while the image is loading, to prevent the layout from changing after the image has loaded.
Reviewed By: javache
Differential Revision: D2838659
fb-gh-sync-id: c27f9685b6976705ac2b24075922b2bf247e06ba
Summary:
public
Standardises the image decoding logic for all image sources, meaning we get the benefits of efficient downscaling of images from all sources, not just ALAssets.
Reviewed By: javache
Differential Revision: D2647083
fb-gh-sync-id: e41456f838e4c6ab709b1c1523f651a86ff6e623
Summary:
public
React Native currently exposes the iOS layer shadow properties more-or-less directly, however there are a number of problems with this:
1) Performance when using these properties is poor by default. That's because iOS calculates the shadow by getting the exact pixel mask of the view, including any tranlucent content, and all of its subviews, which is very CPU and GPU-intensive.
2) The iOS shadow properties do not match the syntax or semantics of the CSS box-shadow standard, and are unlikely to be possible to implement on Android.
3) We don't expose the `layer.shadowPath` property, which is crucial to getting good performance out of layer shadows.
This diff solves problem number 1) by implementing a default `shadowPath` that matches the view border for views with an opaque background. This improves the performance of shadows by optimizing for the common usage case. I've also reinstated background color propagation for views which have shadow props - this should help ensure that this best-case scenario occurs more often.
For views with an explicit transparent background, the shadow will continue to work as it did before ( `shadowPath` will be left unset, and the shadow will be derived exactly from the pixels of the view and its subviews). This is the worst-case path for performance, however, so you should avoid it unless absolutely necessary. **Support for this may be disabled by default in future, or dropped altogether.**
For translucent images, it is suggested that you bake the shadow into the image itself, or use another mechanism to pre-generate the shadow. For text shadows, you should use the textShadow properties, which work cross-platform and have much better performance.
Problem number 2) will be solved in a future diff, possibly by renaming the iOS shadowXXX properties to boxShadowXXX, and changing the syntax and semantics to match the CSS standards.
Problem number 3) is now mostly moot, since we generate the shadowPath automatically. In future, we may provide an iOS-specific prop to set the path explicitly if there's a demand for more precise control of the shadow.
Reviewed By: weicool
Differential Revision: D2827581
fb-gh-sync-id: 853aa018e1d61d5f88304c6fc1b78f9d7e739804
Summary:
https://github.com/facebook/react-native/issues/3679 was only partially fixed as the behaviour only works on iOS. This implements the same behaviour for Android. If the JSBundle was loaded from the assets folder, this will load images from the built-in resources. Else, load the image from the same folder as the JS bundle.
EDIT: For added clarity:
On iOS,
Bundle Location: 'file:///Path/To/Sample.app/main.bundle'
httpServerLocation: '/assets/module/a/'
Name: 'logo'
type: 'png'
**Resolved Asset location: '/Path/To/Sample.app/assets/module/a/logo.png'**
On Android,
Bundle Location: 'file:///sdcard/Path/To/main.bundle'
httpServerLocation: '/assets/module/a/',
name: 'logo'
type: 'png'
**Resolved Asset location: 'file:///sdcard/Path/To/drawable_mdpi/module_a_logo.png'**
Closes https://github.com/facebook/react-native/pull/4527
Reviewed By: svcscm
Differential Revision: D2788005
Pulled By: mkonicek
fb-gh-sync-id: 3f6462a7ee6370a92dd6727ac422c5de346c3ff1
Summary:
public
This diff adds a `getSize()` method to `Image` to retrieve the width and height of an image prior to displaying it. This is useful when working with images from uncontrolled sources, and has been a much-requested feature.
In order to retrieve the image dimensions, the image may first need to be loaded or downloaded, after which it will be cached. This means that in principle you could use this method to preload images, however it is not optimized for that purpose, and may in future be implemented in a way that does not fully load/download the image data.
A fully supported way to preload images will be provided in a future diff.
The API (separate success and failure callbacks) is far from ideal, but until we agree on a unified standard, this was the most conventional way I could think of to implement it. If it returned a promise or something similar, it would be unique among all such APIS in the framework.
Please note that this has been a long time coming, in part due to much bikeshedding about what the API should look like, so while it's not unlikely that the API may change in future, I think having *some* way to do this is better than waiting until we can define the "perfect" way.
Reviewed By: vjeux
Differential Revision: D2797365
fb-gh-sync-id: 11eb1b8547773b1f8be0bc55ddf6dfedebf7fc0a
Summary:
Problem: https://github.com/facebook/react-native/issues/4708
Solution: Added a ColorPropType that validates the color used by the dev
Notes:
1) I'm working a Win8.1 machine and couldn't build the react-native using the github repo. As soon as I figure that out, I'll probably figure how to run the tests and how to add some for this feature.
2) It's my first pull request. Be gentle :)
Closes https://github.com/facebook/react-native/pull/4866
Reviewed By: bestander, svcscm
Differential Revision: D2783672
Pulled By: nicklockwood
fb-gh-sync-id: ca22aa3c0999188075681b5d20fff0631496e238
Summary:
public
Added JS wrappers for ImageStore(Manager) and ImageEditor(Manager) so they can be required in the normal way instead of accessed directly via NativeModules.
Reviewed By: dmmiller
Differential Revision: D2773822
fb-gh-sync-id: 6eeafd3f80a87b1b91a04a2aebad6e2fd31b0e98
Summary:
public
A previous refactor introduced a bug where setting the tintColor of an <Image> to null no longer cleared the tint. This fixes it again.
Reviewed By: javache
Differential Revision: D2744279
fb-gh-sync-id: 1b5e0d546bf456d7b93e2ceee73c568c185c305c
Summary:
public
The +[RCTConvert UIImage:] function, while convenient, is inherently limited by being synchronous, which means that it cannot be used to load remote images, and may not be efficient for local images either. It's also unable to access the bridge, which means that it cannot take advantage of the modular image-loading pipeline.
This diff introduces a new RCTImageSource class which can be used to pass image source objects over the bridge and defer loading until later.
I've also added automatic application of the `resolveAssetSource()` function based on prop type, and fixed up the image logic in NavigatorIOS and TabBarIOS.
Reviewed By: javache
Differential Revision: D2631541
fb-gh-sync-id: 6604635e8bb5394425102487f1ee7cd729321877
Summary: ~~This is a WIP, just finished the first bit and wanted to get some feedback to see if this approach seems appropriate, as I haven't done a lot of Android development.~~
Looks ready for review now.
Closes https://github.com/facebook/react-native/pull/3791
Reviewed By: svcscm
Differential Revision: D2672262
Pulled By: mkonicek
fb-gh-sync-id: 1e8f1cc6658fb719a68f7da455f30a7c9b1db730
Summary: public
The `bridge.modules` dictionary provides access to all native modules, but this API requires that every module is initialized in advance so that any module can be accessed.
This diff introduces a better API that will allow modules to be initialized lazily as they are needed, and deprecates `bridge.modules` (modules that use it will still work, but should be rewritten to use `bridge.moduleClasses` or `-[bridge moduleForName/Class:` instead.
The rules are now as follows:
* Any module that overrides `init` or `setBridge:` will be initialized on the main thread when the bridge is created
* Any module that implements `constantsToExport:` will be initialized later when the config is exported (the module itself will be initialized on a background queue, but `constantsToExport:` will still be called on the main thread.
* All other modules will be initialized lazily when a method is first called on them.
These rules may seem slightly arcane, but they have the advantage of not violating any assumptions that may have been made by existing code - any module written under the original assumption that it would be initialized synchronously on the main thread when the bridge is created should still function exactly the same, but modules that avoid overriding `init` or `setBridge:` will now be loaded lazily.
I've rewritten most of the standard modules to take advantage of this new lazy loading, with the following results:
Out of the 65 modules included in UIExplorer:
* 16 are initialized on the main thread when the bridge is created
* A further 8 are initialized when the config is exported to JS
* The remaining 41 will be initialized lazily on-demand
Reviewed By: jspahrsummers
Differential Revision: D2677695
fb-gh-sync-id: 507ae7e9fd6b563e89292c7371767c978e928f33
Summary: public
A missing return statement in RCTImageLoader meant that cached images would be loaded twice - once from cache and again from the source.
This was mostly innocuous, causing only a slight perf regression due to the image cache being effectively disabled, however in some cases (such as RCTImageEditingManager.cropImage) it caused the success callback to fire twice, resulting in a crash.
Reviewed By: fkgozali
Differential Revision: D2684956
fb-gh-sync-id: 7580a6fbfe00a30807951803e04bfcdbee3bb80a
Summary: public
I had previously assumed (based on past experience and common wisdom) that `[UIImage imageWithData:]` was safe to call concurrently and/or off the main thread, but it seems that may not be the case (see https://github.com/AFNetworking/AFNetworking/pull/2815).
This diff replaces `[UIImage imageWithData:]` with ImageIO-based decoding wherever possible, and ensures that it is called on the main thread wherever that's not possible/convenient.
I've also serialized access to the `NSURLCache` inside `RCTImageLoader`, which was causing a separate-but-similar crash when loading images.
Reviewed By: fkgozali
Differential Revision: D2678369
fb-gh-sync-id: 74d033dafcf6c412556e4c96f5ac5d3432298b18
Summary: Hi,
I'm currently building an app that changes metadata, does some resizes, maybe watermarking ...etc. I want to use RCTImageStoreManager to store the original image in memory and allow me to command different modifications from javascript as it gives me more flexibility. As RCTImageEditingManager does for example.
But currently the RTCImageStoreManager uses UIImage to store the image, the problem is that UIImage losses metadata.
So i suggest we change it to NSData.
Additionally I added a method to remove an image from the store.
A related PR can be found here https://github.com/lwansbrough/react-native-camera/pull/100.
Closes https://github.com/facebook/react-native/pull/3290
Reviewed By: javache
Differential Revision: D2647271
Pulled By: nicklockwood
fb-gh-sync-id: e66353ae3005423beee72ec22189dcb117fc719f
Summary: public
Removed redundant calls to [RCTNetwork canHandleRequest] in release mode when loading images, and improved perf for handler lookups when running in debug mode.
Reviewed By: tadeuzagallo
Differential Revision: D2663307
fb-gh-sync-id: 13285154c1c3773b32dba7894d86d14992e2fd7d
Summary: This adds the basic support for embedding an image in a TextView.
Implementation details :
We create a ReactTextInlineImageShadowNode whenever an Image is embedded within a Text context.
That uses the same parsing code as ReactImageView (copied, not shared) to parse the source property to figure out the Uri where the resource is.
In ReactTextShadowNode we now look for the ReactTextInlineImageShadowNode and place a TextInlineImageSpan so that we can layout appropriately
Later at the time we go to setText on the TextView, we update that TextInlineImageSpan so that the proper Drawable (downloaded via Fresco) can be shown
public
Reviewed By: mkonicek
Differential Revision: D2652667
fb-gh-sync-id: 8f24924d204f78b8bc4d5d67835cc73b3c1859dd
Summary: Fixes#3679, see https://github.com/facebook/react-native/issues/3679
The idea is to always load images from the same folder that we loaded JS bundle.
This doesn't change the current behavior, since `imageNamed:` inferred the
absolute path to the image from app's bundle, but now we make it explicit.
The benefit for OTA updates implementations is that they can simply ask RN
to load js from some `~/Documents/<build-id>/main.jsbundle` folder and RN will
look for images in `~/Documents/<build-id>/assets/`.
Note that for Android we will have to come out with a different plan, since
in prod we load images from built-in resources.
public
Reviewed By: vjeux
Differential Revision: D2616995
fb-gh-sync-id: 2906c62380280ecb987525edf9a0e3e727a1008b
Summary: public
Added lightweight genarics annotations to make the code more readable and help the compiler catch bugs.
Fixed some type bugs and improved bridge validation in a few places.
Reviewed By: javache
Differential Revision: D2600189
fb-gh-sync-id: f81e22f2cdc107bf8d0b15deec6d5b83aacc5b56
Summary: public
The image loader was previously returning on the main thread, which could lead to poor performance due to various call sites doing further image processing (resizing, cropping, etc.) directly in the completion block.
This diff modifies the loader to return on a background thread (the same one used to load the image), and updates the call sites to dispatch to the explicit thread they need.
Reviewed By: javache
Differential Revision: D2549774
fb-gh-sync-id: fed73b7c163fdf67ff65bae72ab1986327e75815
Summary: public
If the frame is set, or the image view moves to a window, we should attempt to load the "real" image. The sizing logic shouldn't kick in if we're only displaying the default image.
Resolves https://github.com/facebook/react-native/issues/3460.
Reviewed By: tadeuzagallo
Differential Revision: D2555316
fb-gh-sync-id: c0c13070ee080bad2b30ca01d9d5173bead406e3
Summary: public
Added RCTDataRequestHandler, which is responsible for loading data URLs. This moves the logic for data URL handling out of RCTImageDownloader (no longer needed) and into the RCTNetwork library, where it makes more sense.
This also means that it is now possible to load data URLs via XHR, and use them for purposes other than just images.
Reviewed By: javache
Differential Revision: D2540964
fb-gh-sync-id: 4f0418bd6b9186f047cc8297276bb970795af104
Summary: public
There was a race condition issue in RCTDownLoadTask whereby the request handler would sometimes call one of the delegate methods before setup was complete, causing an error to be logged because the request token had not been set, and causing te request to fail because the class was not yet set up.
This diff fixes that issue by adding an explicit `start` method to RCTDownloadTask, and changing the setup order to allow for the request to call back immediately without this being treated as an error.
Reviewed By: tadeuzagallo
Differential Revision: D2553628
fb-gh-sync-id: 5ca4e791574a632ccbf2e873e28ac88bffdf851d
Summary: @public
We previously discovered that using an NSURLSessionDataTask to load local files is noticably less efficient than using regular filesystem methods.
This diff adds RCTFileRequestHandler as a replacement for RCTHTTPRequestHandler when loading local files. This reduces loading time when loading local files via XMLHttpRequest, as well as improving the performance for some image load requests.
Reviewed By: @javache
Differential Revision: D2531710
fb-gh-sync-id: 259714baac131784de494d24939f42ad52bff41a
Summary: @public
The legacy 'isStatic' property for image sources is no longer used anywhere in our codebase, but was still being generated by the packager and referenced in the JS in various places.
This diff removes all the remaining references.
Reviewed By: @frantic
Differential Revision: D2531263
fb-gh-sync-id: 0bba0bb8473b1baa908ef7507cbf6d83efb0d9ee
Summary: @public
This diff unifies the logic for detecting when images refer to XCAsset files into a single function (RCTXCAssetNameForURL) and uses it for both +[RCTConvert UIImage:] and RCTImageLoader.
I've also tightened the definition of XCAssets so that it only applies to images inside .car files, not any image inside the main bundle. This avoids using the +[UIImage imageNamed:] when not strictly necessary, which is desirable since that method is not thread-safe, and has undocumented caching behavior that is difficult to reason about.
Reviewed By: @javache
Differential Revision: D2526400
fb-gh-sync-id: 7199c2a44f1d55ff236d2c38a0a9368739b993d5
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: When `RCTImageView` is removed from the view hierarchy, it clears out its `image` to save memory. This makes sense, except that it gets removed from the window (view hierarchy) even when becoming the child of another view.
This fixes the logic so that it only clears out the image if the view hasn't been moved somewhere else within one frame.
@public
Reviewed By: @javache
Differential Revision: D2493849
Summary: This sort of logging helped me identify issues with reloading images too frequently (and for trivial reasons), so leaving it in might be useful for future optimization work, or for anyone building apps using these components.
@public
Reviewed By: @alexeylang
Differential Revision: D2475613
Summary: @public
It's less important to reload for downscaling than upscaling, so increase the threshold in that direction. Also, this now considers each dimension separately, and a big enough change either way should result in a reload.
Finally, this considers both the current image size and the inflight target size, so we don't reload if either is already good.
Reviewed By: @tadeuzagallo
Differential Revision: D2470911
This is an early release and there are several things that are known
not to work if you're porting your iOS app to Android.
See the Known Issues guide on the website.
We will work with the community to reach platform parity with iOS.
Summary:
The CameraRoll-related APIs were mixed in with the Image classes due to legacy coupling issues. Now that the APIs have been decoupled, it makes more sense for the CameraRoll classes to live in a separate library.
This will be a breaking change for apps using the CameraRoll or related APIs. Fix is to add the RCTCameraRoll lib to your project.
Summary:
GIF images are currently loaded as a CAKeyframeAnimation, however returning this animation directly from RCTImageLoader was dangerous, as any code that expected a UIImage would crash.
This diff changes RCTGIFImageLoader to return a UIImage of the first frame, with the keyframe animation attached as an associated object. This way, code that is not expecting an animation will still work correctly.
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:
require('./image.jpg') returns a number and therefore the propType is wrong. Adding it to the propType to fix the warning and dealing with flow which is completely broken for this.
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:
Addresses #1534
When an image has a known width, but a height of 0 (which can happen if `flex: 1` is set on the `Image` element), `RCTDownloadManager` attempts to scale it to an invalid size, which results in a `NULL` `CGContextRef` and some scary warnings from UIKit:
```
<Error>: CGContextTranslateCTM: invalid context 0x0. This is a serious error. This application, or a library it uses, is using an invalid context and is thereby contributing to an overall degradation of system stability and reliability. This notice is a courtesy: please fix this problem. It will become a fatal error in an upcoming update.
```
This adds a check for zero width or height to the `RCTClipRect` function. If either dimension is zero, it is calculated based on the aspect ratio of the source image. This ensures that we don't try to create an invalid `CGContextRef`, and that images with an unknown dimension are still scaled, blended, etc.
Closes https://github.com/facebook/react-native/pull/2278
Github Author: Yusef Napora <yusef@napora.org>
Summary:
In the latest 0.9.0-rc of React Native, the default image won't load due to a typo and a missing condition in `setImage`. This PR contains fixes for both of them.
Closes https://github.com/facebook/react-native/pull/2269
Github Author: Tom Hastjarjanto <tom@intellicode.nl>
Summary:
For some reason we're now spamming the logs everytime we render an Image because overflow is not defined in the whitelist. overflow: 'hidden' is needed for network images with cover mode.
The way we currently define those is not optimal where we try to factor as many things as possible into distinct propTypes. However for Text we're not even using this but we are getting all the ones from View (which many do not apply) and remove some that aren't needed.
It may be useful to cleanup this in the future but in the short term, it's better to remove this warning that doesn't have much value anyway.
Summary:
This is a quick fix for the RCTDownloadTaskWrapper crashing on iOS 7. The issue was that the object returned by -[NSURLSession downloadTaskWithURL:] on iOS was not actually a subclass of NSURLSessionTask, so the category that adds associated blocks was not working. I've fixed that by making it a category on NSObject instead.
Summary:
This diff implements highlighting of tapped text subranges for the iOS `<Text>` component, styled to match how iOS webkit views highlight links (translucent grey overlay with rounded corners).
Highlighting is enabled by default for any `<Text>` component which has an onPress handler. To disable the highlight, add `suppressHighlighting={true}` to the component props.
Summary:
Update to https://github.com/facebook/react-native/pull/1969
--
Recent improvements allow RCTImageLoader to select a more appropriate sized image based on the layout dimensions. Sizes:
- asset.thumbnail
- asset.aspectRatioThumbnail
- asset.defaultRepresentation.fullScreenImage
- asset.defaultRepresentation.fullResolutionImage
Prior, only the fullResolutionImage was used. This was memory intensive and resulted in crashes when loading several large images at once. The updated implementation works well, but can be made more efficient:
Consider loading 10 8MP (3264x2448) images in 150x150 pixel containers. The target size (150x150) is larger than asset.thumbnail (approx 100x100), therefore the fullScreenImage representation is used instead (approx 1334x1000).
This commit will scale the asset to the minimum size required while taking into account original aspect ratio and device scale. Memory usage is considerably lower and many more images can be loaded in
sequence without having to worry
Closes https://github.com/facebook/react-native/pull/2008
Github Author: Adam Roth <adamjroth@gmail.com>
Summary:
RCTNetworkImageView and RCTStaticImage had significant overlap in functionality, but each had a different subset of features and bugs.
This diff merges most of the functionality of RCTNetworkImageView into RCTStaticImage, eliminating some bugs in the former, such as constant redrawing when properties were changed.
I've also removed the onLoadAbort event for now (as it wasn't implemented), and renamed the other events to match the web specs for `<img>` and XHMLHttpRequest. The API is essentially what Adobe proposed here: http://blogs.adobe.com/webplatform/2012/01/13/html5-image-progress-events/
The following features have not yet been ported from RCTNetworkImageView:
- Background color compositing. It's not clear that this adds much value and it increases memory consumption, etc.
- Image request cancelling when images are removed from view. Again, it's not clear if this is a huge benefit, but if it is it should be combined with other optimisations, such as unloading offscreen images.
(Note that this only affects the open source fork. For now, internal apps will still use FBNetworkImageView for remote images.)
Summary:
RCTImageDownloader was ignoring server response codes. When receiving a response other than 200 it would treat this as success, meaning the image would never load, nor report failure.
This diff fixes that by treating responses with non-200 status as an error so that error handler is called.
Summary:
Merged RCTStaticImage with our internal RKStaticImage and ported over logic where assets are loaded at the optimal size and reloaded if the view size changes.
Summary:
Remote images now support the `tintColor` prop.
Also picked nicer demo colors for the UIExplorer example.
Fixes#1867
Closes https://github.com/facebook/react-native/pull/1932
Github Author: James Ide <ide@jameside.com>
Summary:
Change `RCTImageDownloader` so it stores the `RCTDownloadTaskWrapper` for reuse. Modify `RCTDownloadTaskWrapper` to use associated objects to store the completion/progress blocks.
Summary:
This PR adds 4 native events to NetworkImage.
Using these events I could wrap `Image` component into something like:
```javascript
class NetworkImage extends React.Component {
getInitialState() {
return {
downloading: false,
progress: 0
}
}
render() {
var loader = this.state.downloading ?
<View style={this.props.loaderStyles}>
<ActivityIndicatorIOS animating={true} size={'large'} />
<Text style={{color: '#bbb'}}>{this.state.progress}%</Text>
</View>
:
null;
return <Image source={this.props.source}
onLoadStart={() => this.setState({downloading: true}) }
onLoaded={() => this.setState({downloading: false}) }
onLoadProgress={(e)=> this.setState({progress: Math.round(100 * e.nativeEvent.written / e.nativeEvent.total)});
onLoadError={(e)=> {
alert('the image cannot be downloaded because: ', JSON.stringify(e));
this.setState({downloading: false});
}}>
{loader}
</Image>
}
}
```
Useful on slow connections and server errors.
There are dozen lines of Objective C, which I don't have experience with. There are neither specific tests nor documentation yet. And I do realize that you're already working right now on better `<Image/>` (pipeline, new asset management, etc.). So this is basically a proof concept of events for images, and if this idea is not completely wrong I could improve it or help somehow.
Closes https://github.com/facebook/react-native/pull/1318
Github Author: Dmitriy Loktev <unknownliveid@hotmail.com>
Summary:
This introduces a new `RCTResponseErrorBlock` block type that allows a bridge module writer to call it with an `NSError` instance rather than a dictionary.
Summary:
If you try to create a cached response from a nil response the app will crash. Looking at the code that uses NSURLSession and NSURLCache, this fix looks correct to me.
Fixes#1850
Closes https://github.com/facebook/react-native/pull/1852
Github Author: James Ide <ide@jameside.com>
Summary:
resizeMode is a native prop, but it is also in the propTypes, so this causes an incorrect warning:
```
Prop resizeMode = `contain` should not be set directly on Image.
```
@public
Test Plan: No warnings on image example in UIExplorer
Summary:
This PR adds support for UIImagePickerController to allow selecting a photo / video from the users camera roll.
Example:
Selecting something from camera roll
```
ImagePickerIOS.openSelectDialog(<config>, <successCallback>, <cancelCallback>);
ImagePickerIOS.openSelectDialog({
showImages: true, // defaults to true
showVideos: false // defaults to false
}, function (data) {
console.info("Got a callback!");
console.info(data); // file URL as in assets-library://asset/asset.JPG?id=E2741A73-D185-44B6-A2E6-2D55F69CD088&ext=JPG
}, function() {
console.info("Cancelled");
});
```
Using camera
```
ImagePickerIOS.openCameraDialog(<config>, <successCallback>, <cancelCallback>);
ImagePickerIOS.openSelectDialog({
videoMode: false, // defaults to true, whether to record videos instead
}, function (data) {
console.info("Got
Closes https://github.com/facebook/react-native/pull/1620
Github Author: David Mohl <me@dave.cx>
Test Plan: Imported from GitHub, without a `Test Plan:` line.
Summary:
@public
I've increased the warning levels in the OSS frameworks, which caught a bunch of minor issues. I also fixed some new errors in Xcode 7 relating to designated initializers and TLS security.
Test Plan:
* Test the sample apps and make sure they still work.
* Run tests.
Summary:
@public
This is a refactor of @philikon's original diff that decouples the dependencies between the Network and Image modules, and replaces RCTDataQueryExecutor with a more useful abstraction.
I've introduced the RCTURLRequestHandler protocol, which is a new type of bridge module used for loading data using an NSURLRequest. RCTURLRequestHandlers can be registered using RCT_EXPORT_MODULE() and are then available at runtime for use by the RCTDataManager, which will automatically select the appropriate handler for a given request based on the handler's self-reported capabilities.
The currently implemented handlers are:
- RCTHTTPRequestHandler - the standard open source HTTP request handler that uses NSURLSession
- RKHTTPRequestHandler - the internal FB HTTP request handler that uses FBNetworking
- RCTImageRequestHandler - a handler for loading local images from the iOS asset-library
Depends on D2108193
Test Plan:
- Internal apps still work
- OSS port still compiles, Movies app and a sample Parse app still work
- uploading image to Parse using the above code snippet works
- tested `FormData` with string and image parameters using http://www.posttestserver.com/
Summary:
This adds a parameter for fetching videos from the camera roll. It also changes the default to fetch both videos and photos.
Closes https://github.com/facebook/react-native/pull/774
Github Author: Joshua Sierles <joshua@diluvia.net>
Test Plan: Imported from GitHub, without a `Test Plan:` line.
Summary:
With this in place, it's possible to upload a picture from the `CameraRoll` to Parse, for instance:
xhr = new XMLHttpRequest();
xhr.onload = function() {
data = JSON.parse(xhr.responseText);
var parseFile = new Parse.File(data.name);
parseFile._url = data.url;
callback(parseFile);
};
xhr.setRequestHeader('X-Parse-Application-Id', appID);
xhr.setRequestHeader('X-Parse-JavaScript-Key', appKey);
xhr.open('POST', 'https://api.parse.com/1/files/image.jpg');
// assetURI as provided e.g. by the CameraRoll API
xhr.send(new NativeFile(assetURI));
Closes https://github.com/facebook/react-native/pull/1357
Github Author: Philipp von Weitershausen <philikon@fb.com>
Test Plan: Imported from GitHub, without a `Test Plan:` line.
Summary:
@public
Our background color propagation mechanism is designed to make rendering of translucent content more efficient by pre-blending against an opaque background. Currently this only works for text however, because images are not composited into their background even if the background color is opaque.
This diff precomposites network images with their background color when the background is opaque, allowing them to take advantage of this performance optimization.
I've also added some logic to correctly crop the downloaded image when the resizeMode is "cover" or "contain" - previously it was only correct for "stretch".
Before:{F22437859}
After:{F22437862}
Test Plan: Run the UIExplorer "<ListView> - Paging" example with "color blended layers" enabled and observe that the images appear in green now, instead of red as they did before.
Summary:
ActivityIndicator was forwarding all of its props except `style` to the inner native view. This meant that onLayout would report a zero-sized frame that was relative to the wrapper view instead of the parent of the ActivityIndicator.
This diff adds `onLayout` to the wrapper view instead of the native view.
In general, all components that forward props need to be audited in this manner.
Closes https://github.com/facebook/react-native/pull/1292
Github Author: James Ide <ide@jameside.com>
Test Plan: `<ActivityIndicator onLayout={...} />` reports the size of the spinner plus a position relative to its parent view.
Jimmy Mayoukou
Nicolas Charpentier
Maria Mateescu
David Goldman
Nathan Azaria
Konstantin Raev
Scott Wolchok
Olivier Notteghem
skatpgusskat
Janic Duplessis
Pieter De Baets
aleclarsoniv
yeshuang
Jesse Luo
Skotch Vail
David Aurelio
Christoph Pojer
Jean Regisser
Joel Marcey
wenzhao.yin
Andrei Coman
Kasim Tan
Nick Lockwood
Maarten Schumacher
Hedger Wang
Adam Comella
Ben Nham
Corné Dorrestijn
Howard Yeh
mattds
James Ide
Nick
Marc Horowitz
Alon Schwarz
Reem Helou
Zahan Malkani
Varun Vachhar
Rui Chen
Fada Chen
Christopher Dro
Wenjing Wang
Andreas Drivenes
Noam Bartov
sunnylqm
Geoffrey Goh
Milen Dzhumerov
Satyajit Sahoo
StefanT
Qiao Liang
Justas Brazauskas
zjlovezj
sathis
Brent Vatne
Krzysztof Magiera
Matthieu Achard
Pawel Sienkowski
Dave Miller
Alex Kotliarskyi
Justin Spahr-Summers
Ben Alpert
Dral
Martin Konicek
Spencer Ahrens
Alex Akers
Oliver (Cunpu) Bo
Christopher Chedeau
Adam Roth
Yusef Napora
Tom Hastjarjanto
Philipp von Weitershausen
Dmitriy Loktev
James Ide
Eric Vicenti
David Mohl
Tadeu Zagallo
Andy Street
Joshua Sierles
Premasagar Rose
Peter Zich
