Summary:
This avoids a crash when we try to load a PHAsset with nil image url. Specifically, the following condition evaluates to true when `imageURL` is nil:
```objc
if ([imageURL.scheme caseInsensitiveCompare:@"assets-library"] == NSOrderedSame) {
assetID = [imageURL absoluteString];
results = [PHAsset fetchAssetsWithALAssetURLs:@[imageURL] options:nil];
}
```
The crash will be "attempt to insert nil object from objects[0]" when we build the `@[imageURL]` array literal.
We've seen this emerge as a very common crash among Expo users, so I wanted to at least provide a clear error message instead of terminating the app.
Load an image from the photo library with a nil request url.
Closes https://github.com/facebook/react-native/pull/15952
Differential Revision: D5835219
Pulled By: ericnakagawa
fbshipit-source-id: 7be00a15e674a0905cf5c27c526ce9085d1b308f
Summary:
To make React Native play nicely with our internal build infrastructure we need to properly namespace all of our header includes.
Where previously you could do `#import "RCTBridge.h"`, you must now write this as `#import <React/RCTBridge.h>`. If your xcode project still has a custom header include path, both variants will likely continue to work, but for new projects, we're defaulting the header include path to `$(BUILT_PRODUCTS_DIR)/usr/local/include`, where the React and CSSLayout targets will copy a subset of headers too. To make Xcode copy headers phase work properly, you may need to add React as an explicit dependency to your app's scheme and disable "parallelize build".
Reviewed By: mmmulani
Differential Revision: D4213120
fbshipit-source-id: 84a32a4b250c27699e6795f43584f13d594a9a82
Summary:
Resolves#7081 by allowing iCloud to download photos not stored on the device.
**Test plan (required)**
1. Verified existing photos stored on the device still display.
2. Deleted my iCloud photo library from my phone and verified the image downloads and displays.
Closes https://github.com/facebook/react-native/pull/9530
Differential Revision: D3838470
Pulled By: mkonicek
fbshipit-source-id: 810830a4246714b6e166e4411f3fa848b1f1b71c
Summary:
RCTPhotoLibraryImageLoader was not using the scale argument so the image loaded wasn't always the right resolution.
**Test plan**
On my iPhone 6, which has `RCTScreenScale() === 2`, see that an `<Image>` rendered with a `ph://XXX` URI is rendered properly in 2x.
More thoroughly, I used `PHAsset.fetchAssetsWithMediaType(.Image, options: fetchOptions)` to fetch PHAssets to get a `asset.localIdentifier` to test. Then, I rendered a `<Image source={{uri: `ph://${localIdentifier}`}} style={{width: 375, height: 375}} />`.
Closes https://github.com/facebook/react-native/pull/8458
Differential Revision: D3492495
fbshipit-source-id: 34b2757f880edf6ff1751773f6e1a0f62c289f5a
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
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:
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.