[expo-camera] Remove @koale/useworker (#23967)# Why `@koale/useworker` is only used for Web QR code scanning and has been causing some issues due to lack of maintenance. Fixes: https://githu
[expo-camera] Remove @koale/useworker (#23967)# Why `@koale/useworker` is only used for Web QR code scanning and has been causing some issues due to lack of maintenance. Fixes: https://github.com/expo/expo/issues/17846 Related: https://github.com/expo/expo/issues/23296, and the PR to revert its 'fix' https://github.com/expo/expo-cli/pull/4746 # How Refactors the existing code to use vanilla JS 1. We create a inline webworker by creating an inline blob with `qrWorkerMethod.toString()` (code adapted from `@koale/useworker`) 2. Create a smaller wrapper that tracks messages being sent to the worker via a queue of promises As the worker is synchronous and will receive messages in order a simple First In First Out queue should suffice. This does _slightly_ change the functionality of the existing code. 1. Previously we created a new Worker for every instance of `<Camera />`. Now a single worker is shared across all instances. 1. As the worker is declared in the global scope, it is created regardless if QR code scanning is enabled. We could lazy initialise it, but because its extremely small and inline (no network requests) I don't see this being an issue. I also removed an extra `useEffect` hook by moving its logic into the cleanup step of the enabling hook.
show more ...
[docs] Fix internal links in Expo Camera doc (#23748)
[web][camera] Fix permissions check in Firefox (#22855)# Why As described in #19485, the current logic for checking camera/microphone permissions does not work in Firefox and leads to a `TypeErr
[web][camera] Fix permissions check in Firefox (#22855)# Why As described in #19485, the current logic for checking camera/microphone permissions does not work in Firefox and leads to a `TypeError` being thrown, as it is not considered a valid permission to check for. <!-- Please describe the motivation for this PR, and link to relevant GitHub issues, forums posts, or feature requests. --> # How <!-- How did you build this feature or fix this bug and why? --> I've fixed this by catching the `TypeError` and returning an undetermined status, so the requesting application can then request permission accordingly. # Test Plan <!-- Please describe how you tested this change and how a reviewer could reproduce your test, especially if this PR does not include automated tests! If possible, please also provide terminal output and/or screenshots demonstrating your test/reproduction. --> I added a unit test that ensures that we return an undetermined status whenever a `TypeError` is thrown while checking for permissions. # Checklist <!-- Please check the appropriate items below if they apply to your diff. This is required for changes to Expo modules. --> - [x] Documentation is up to date to reflect these changes (eg: https://docs.expo.dev and README.md). - [x] Conforms with the [Documentation Writing Style Guide](https://github.com/expo/expo/blob/main/guides/Expo%20Documentation%20Writing%20Style%20Guide.md) - [x] This diff will work correctly for `npx expo prebuild` & EAS Build (eg: updated a module plugin).
[expo-camera][ios] Use CoreMotion to detect device orientation (#21956)# Why Expo-camera doesn't allow landscape photos when the screen orientation is locked or if the React native app orientati
[expo-camera][ios] Use CoreMotion to detect device orientation (#21956)# Why Expo-camera doesn't allow landscape photos when the screen orientation is locked or if the React native app orientation is locked. This is contrary to how most cameras work (including apple's native camera), which allow you to take landscape photos despite orientation being locked to portrait. Closes https://github.com/expo/expo/issues/21938 # How The reason this happens is because `expo-camera` [relies on UIDeviceOrientation](https://github.com/expo/expo/blob/6085491bf6236a1aa82f96616ea31bbf4eda06ae/packages/expo-camera/ios/EXCamera/EXCamera.m#L357) to determine what type of a photo to take (portrait or landscape). It then sets the AVVideoOrientation to pass to Apple's `takePicture` or `startRecordingToOutputFileURL` function based on that. However, if the orientation is locked, the device orientation is always given as portrait by Apple which means the picture is always taken in portrait. The only workaround I am aware of is to use the `CoreMotion` framework to check where the device is in space and then use that to determine what type of photo should be taken (portrait or landscape). This was also how the react-native-camera [package worked](https://github.com/react-native-camera/react-native-camera/blob/7cdfb6ec127decf1ac5686635afb7f07557becc5/ios/RCT/RCTSensorOrientationChecker.m#L72) - I've added a property (ios only) `responsiveOrientationWhenOrientationLocked' to determine whether or not we should use the physical orientation of the device to determine the capture orientation when orientation is locked. This way, we won't be breaking any users of the package who rely on the existing behavior. - I've also added a callback that applies when this property is set to true. Since `responsiveOrientationWhenOrientationLocked` means that landscape photos can be taken when the app is locked to portrait or when the device is locked to portrait, the screen itself will no longer rotate. The callback provides the user with the ability to rotate icons/buttons when the camera capture orientation changes (also what the native iOS camera does) # Test Plan <!-- Please describe how you tested this change and how a reviewer could reproduce your test, especially if this PR does not include automated tests! If possible, please also provide terminal output and/or screenshots demonstrating your test/reproduction. --> # Checklist <!-- Please check the appropriate items below if they apply to your diff. This is required for changes to Expo modules. --> - [x] Documentation is up to date to reflect these changes (eg: https://docs.expo.dev and README.md). - [x] Conforms with the [Documentation Writing Style Guide](https://github.com/expo/expo/blob/main/guides/Expo%20Documentation%20Writing%20Style%20Guide.md) - [x] This diff will work correctly for `expo prebuild` & EAS Build (eg: updated a module plugin).
[docs][camera] clean up types, update code comments (#20796)
[camera][ncl] correct camera type, update NCL example (#20130)
[camera][Android] Use downsampling in case of the OOM exception (#20131)# Why This a follow-up to the https://exponent-internal.slack.com/archives/C0238THKESC/p1667334481543559. # How Adde
[camera][Android] Use downsampling in case of the OOM exception (#20131)# Why This a follow-up to the https://exponent-internal.slack.com/archives/C0238THKESC/p1667334481543559. # How Added the ability to turn on the downsampling in the case of the OOM exception on Android. Also, when the out-of-memory error is thrown we try to reject the promise instead of crashing the app. However, that may not work - we don't know if the app will work normally after the OOM. # Test Plan - NCL ✅
[barcode][camera] Make `cornerPoints` not optional (#19519)# Why A follow-up to the https://github.com/expo/expo/pull/19357#pullrequestreview-1137648018. Made `cornerPoints` not optional and ad
[barcode][camera] Make `cornerPoints` not optional (#19519)# Why A follow-up to the https://github.com/expo/expo/pull/19357#pullrequestreview-1137648018. Made `cornerPoints` not optional and add missing `bounds` property to the barcode result object. # Test Plan - NCL - android, ios ✅
[android][camera] Add cornerPoints to barcode scanning result (#19357)# Why Will fix #17795. # How `cornerPoints` wasn't implemented in the barcode scanner in `expo-camera` on Android. I i
[android][camera] Add cornerPoints to barcode scanning result (#19357)# Why Will fix #17795. # How `cornerPoints` wasn't implemented in the barcode scanner in `expo-camera` on Android. I implemented it with `expo-barcode-scanner` as a reference. # Test Plan I don't think there is a way to write an automated unit test for this kind of feature. I modified the `bare-expo` app to show a bounding box instead of an Alert, like in BarCodeScanner screen. You can test it by turning on the barcode scanner in the Camera screen. Then point at some QR codes and check if the green bounding box matches the QR code on the camera. Repeat the test for both front and back camera and all orientations. I tested it on Samsung Galaxy S20 5G (Android 12) and it works. I don't have any other working Android devices right now so I would appreciate more testing on different devices. # Checklist - [x] Make it API-compatible - group number[] into {x: number, y: number}[] - [x] Scale the values to view coordinates - [Reference](https://github.com/expo/expo/blob/main/android/versioned-abis/expoview-abi46_0_0/src/main/java/abi46_0_0/expo/modules/barcodescanner/BarCodeScannerView.kt#L71) - [x] Make `cornerPoints` nullable and don't crash when `cornerPoints` are really not available. - [x] Lint and format code with Expo rules - [x] Update `bare-expo` - [x] Documentation is up to date to reflect these changes (eg: https://docs.expo.dev and README.md). - [x] Conforms with the [Documentation Writing Style Guide](https://github.com/expo/expo/blob/main/guides/Expo%20Documentation%20Writing%20Style%20Guide.md) - [ ] This diff will work correctly for `expo prebuild` & EAS Build (eg: updated a module plugin). ^ I don't know. I can't get `expo prebuild` to complete without an error even on the main branch and this branch is no different. - [x] Update Changelog
[camera][Android] Combine `CameraModule` with `CameraViewManager` (#19049)# Why A follow-up to the https://github.com/expo/expo/pull/18946. Combines the `CameraModule` with the `CameraViewMan
[camera][Android] Combine `CameraModule` with `CameraViewManager` (#19049)# Why A follow-up to the https://github.com/expo/expo/pull/18946. Combines the `CameraModule` with the `CameraViewManager` on Android. Makes sure that we use the same set of module names on both platforms. Fixes: ``` Cannot read property 'back' of undefined ``` # How - Copied content of the `CameraModule` into the `CameraViewManager`. - Adjusted the js layer. # Test Plan - NCL ✅
[camera] Fix native module exports (#18946)# Why on ios expo go, there is a js error where to [access null property](https://github.com/expo/expo/blob/41b1a02f64d01176c459a265ced165e452b10141/pa
[camera] Fix native module exports (#18946)# Why on ios expo go, there is a js error where to [access null property](https://github.com/expo/expo/blob/41b1a02f64d01176c459a265ced165e452b10141/packages/expo-camera/src/utils/props.ts#L20) and the native module is actually undefined. this is a regression from #18703 and #18864. on ios, the original camera view manager name is `ExponentCameraManager` and now being `ExponentCamera`. # How i checked there're no usage of `ExponentCameraManager`. we use `ExponentCamera` both on ios and android. i just replace remove the old name and use the new name. # Test Plan - ios bare-expo - ios expo go with local home
[docs][packages] update typos and links in doc comments (#18922)
[expo-camera][ios][android] Support additional EXIF tags when taking photos (#18469)# Why Due to system limitations, the photos taken from the Camera api do not have certain EXIF tags, such as G
[expo-camera][ios][android] Support additional EXIF tags when taking photos (#18469)# Why Due to system limitations, the photos taken from the Camera api do not have certain EXIF tags, such as GPS coordinates. For simplicity and privacy purposes, we do not want to get the user's location at the background each time a photo is taken. However, some enterprise apps do have a legal requirement to attach GPS coordinates to the photos taken from the app. This is used for compliance purpose to check that the photos are taken at certain locations. Similar requirements are found in [#12077](https://github.com/expo/expo/issues/12077) and [#6399](https://github.com/expo/expo/issues/6399). # How Similar to the approach in another plugin react-native-camera [PR#1](https://github.com/react-native-camera/react-native-camera/pull/2402) and [PR#2](https://github.com/react-native-camera/react-native-camera/pull/2577), I've added a new parameter `additionalExif` for the method `takePictureAsync()` alongside the existing `exif` parameter. The `additionalExif` can contain key value pairs of additional exif tags to be written to the image. It will only be written when the `exif` parameter is also set to `true`. There is some special handling of GPS coordinates data to ensure that it meets the standard format. The current implementation only supports iOS and Android platform. Example usage: ```typescript await takePictureAsync({ exif: true, additionalExif: { GPSLatitude: 30.82123, GPSLongitude: 150.25582, GPSAltitude: 80.808, } }); ``` # Test Plan I've added a test case in the test-suite to cover this new parameter. I've also tested the change locally using an iPad Mini 6 for iOS and Galaxy Tab A7 Lite for Android. I've taken the photo with each device, and then use the exif viewer to read the EXIF tags of the photos taken. I've hard-coded a dummy GPS coordinates in the EXIF tags as shown in the example usage above in my testing code, and below are the photos. You can download them and view the GPS coordinates in an EXIF viewer.
[packages] update problematic doc comments, regenerate files (#18128)
[Web][camera] Prevent immediate QR worker clean up (#17833)
[camera][docs] Fix typo
[docs][tsdoc] Update the usage of old Camera.Constants (#17522)
[lint] Add "caughtErrors: 'all'" to linter config (#16591)Why --- ES2019 added "optional catch bindings" so that `e`/`error`/etc. don't need to be specified in catch clauses if the thrown value i
[lint] Add "caughtErrors: 'all'" to linter config (#16591)Why --- ES2019 added "optional catch bindings" so that `e`/`error`/etc. don't need to be specified in catch clauses if the thrown value isn't used. This changes our lint rules to warn if unnecessary error variables are declared. https://2ality.com/2017/08/optional-catch-binding.html. In JS, as opposed to TS, we allow unused catch bindings if the variable names are prefixed with an underscore. This is so that JS targeting older JS interpreters can write `catch (_) {}` if needed. With TS we disallow unused catch bindings since tsc can compile code to its target JS version. How --- Added `caughtErrors: 'all'` to the no-unused-vars rule's configuration. As part of this change, I made the TypeScript linting rules apply only to .ts/.tsx/.ts.d files and updated the unit test snapshots. Test Plan --- Added unit tests to the linter. Ran linter over all modules in this repo with expotools.
[expo-camera] Allow detection of inverted QR codes on web (#16106)Co-authored-by: Bartosz Kaszubowski <[email protected]>
Fix SDK tests after upgrading RN to 0.66
[camera] add doc comments in source, APISection tweaks (#15936)
[lint] Add support for ESLint 8.x, bump to 10.0.0 (#15810)Why --- ESLint v8 came out awhile ago. This PR updates eslint-config-universe to support ESLint v8. How --- Most of the work was upd
[lint] Add support for ESLint 8.x, bump to 10.0.0 (#15810)Why --- ESLint v8 came out awhile ago. This PR updates eslint-config-universe to support ESLint v8. How --- Most of the work was updating dependencies and switching our tests to use `eslint.ESLint` instead of `eslint.CLIEngine`. Read through the changelog of each dependency and confirmed the breaking changes don't affect us (dropping Node 10 was the most common one). Updated some deprecated ESLint rules that had been moved to eslint-plugin-node, a new dependency. This is pretty much a drop-in change but I bumped the major version since several dependencies were upgraded and there was a slightly higher peer dep requirement for `@babel/core`. Test Plan --------- `yarn test` in the plugin directory `et cp --no-uniformity-check --all --fix-lint`
[camera] remove type codec string from record async return (#15791)
[multiple packages] Fix broken typings causing `check-packages` failures (#14912)
[eslint-config] remove `arrowParens` overwrite, reformat files (#14232)
123