New mayor version (v4)

[MarcoScabbiolo]

react-native-camera as we all know it is being re-written to provide much needed future-proofing, stability, and extensibility.

In this repository you will find the work in progress of the new version. We could use your contribution! Head over to the project to know what needs to be done.

[cristianoccazinsp]

Is this going to be a full re-write? For Android, if the underlying camera API (Camera1) will be removed/replaced, please make sure it can be as solid as the current Camera 1 implementation (even if deprecated). For example, Camera2 is still extremely bugged, is much slower than Camera1, has rotation issues, has a variety of random crashes and ANRs due to race conditions and poor implementation, and has a much higher crash rate.

[MarcoScabbiolo]

@cristianoccazinsp It will be a full re-write but the native parts will be changed to Kotlin/Swift first, then changed as needed, so we minimize the breaking changes.

About Android, we're moving to CameraX. Camera 1 will be around as a legacy implementation (API version < 21), and Camera 2 might be used but only for use cases not covered by Camera X if any arises. We can follow up on this on the linked issue.

[cristianoccazinsp]

I don't know if CameraX works like Camera2, but if it does, there's more than just API version < 21 requirement. For instance, when I first started testing this library, I did some effort to try to use Camera2, but even on some Android 8.1 devices (Motorola G5, API 27), Camera2 was not supported, and it always had to fall back to Camera1. In the end, Camera1 was always the option that had more device support, so it was (and probably is) vital for many android devices.

[MarcoScabbiolo]

That's one of the promises: https://developer.android.com/training/camerax . Please let's move the CameraN discussion to react-native-camera/react-native-camera-v4#4

[scarlac]

Yes it uses camera2 under the hood. Google is writing it. We also use CameraX for react-native-canera-kit. I'm happy to hear this lib is switching as well.

[fabOnReact]

@cristianoccazinsp

what about forking expo-camera? what are the expo-camera and barcodescanner disadvantages? we should avoid having too many projects...

https://github.com/expo/expo/issues?q=is%3Aopen+is%3Aissue+label%3AAndroid+label%3ABarCodeScanner
https://github.com/expo/expo/issues?q=is%3Aopen+is%3Aissue+label%3AAndroid++label%3ACamera+

For example, react-native developers just need one Camera API and one Barcode API etc... having many mantainers working on many different projects may cost us lots of effort and also make it very difficult for react-native developers to learn the APIs

I think is a good idea having a separate expo-camera were developers tests new functionalities and then are merged in expo-camera once they are reliable

In the end we just need 1 well written and well mantained package ☮️ 🙏 Thanks a lot and good luck!

[MarcoScabbiolo]

@fabriziobertoglio1987 expo is built on top of react-native so expo camera is way above this package in the stack, that's why it requires additional setup like installing react-native-unimodules that is a burden for many react native developers.

In an ideal scenario and to minimize duplicated efforts expo-camera should depend on a pure react-native implementation, and react-native-camera and react-native-camera-kit are the only candidates afaik.

Why have

react-native -> expo -> expo-camera -> react-native-camera

When you can have

react-native -> react-native-camera |-> expo -> expo-camera

At the end expo is an opinionated pseudo-framework on top of RN.

[cristianoccazinsp]

@cristianoccazinsp

what about forking expo-camera? what are the expo-camera and barcodescanner disadvantages? we should avoid having too many projects...

https://github.com/expo/expo/issues?q=is%3Aopen+is%3Aissue+label%3AAndroid+label%3ABarCodeScanner
https://github.com/expo/expo/issues?q=is%3Aopen+is%3Aissue+label%3AAndroid++label%3ACamera+

For example, react-native developers just need one Camera API and one Barcode API etc... having many mantainers working on many different projects may cost us lots of effort and also make it very difficult for react-native developers to learn the APIs

I think is a good idea having a separate expo-camera were developers tests new functionalities and then are merged in expo-camera once they are reliable

In the end we just need 1 well written and well mantained package ☮️ 🙏 Thanks a lot and good luck!

The problem is for non-expo projects, no one really wants yet another dependency (a big one, that basically locks you in a specific RN version) just for the camera. If anything, expo should be using react-native-camera internally!

Also, wasn't this package created from the original expo camera package? And it was extremely bugged, slow, and full of crashes. It was definitely not a camera library for an app that has intensive use of the camera.

[mishsom]

I am facing problems with setting up react-native-unimodules since it moved to expo, the reason is they assume folder structure for the project, I think expo libs are not usable for many react-native-projects out there who have different project structuring.

The project structuring example is here.

[cristianoccazinsp]

Looks promising indeed!

…

On Fri, Mar 5, 2021 at 7:27 PM SimonErm ***@***.***> wrote: In an ideal scenario and to minimize duplicated efforts expo-camera should depend on a pure react-native implementation, and react-native-camera and react-native-camera-kit are the only candidates afaik. https://github.com/cuvent/react-native-vision-camera looks very promising, too. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#3100 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ALU263CXHI3HT7ABKFBIWOLTCFLGTANCNFSM4XIJKOOQ> .

[fabOnReact]

I'm no expert in expo.

I'm talking about forking expo-camera again and building on top of that project.

Currently expo-camera has 70 open issues, expo-barcode has maybe 20 issues

additionally libraries like tensorflow react native are build to top of expo-camera and expo-gl

https://blog.tensorflow.org/2020/02/tensorflowjs-for-react-native-is-here.html
https://github.com/tensorflow/tfjs/tree/master/tfjs-react-native

for me expo-camera or any project built on top of expo-camera are (personally) more interesting.

[cristianoccazinsp]

@fabriziobertoglio1987 in my opinion, expo camera should build on top of a pure react-native camera library, and not the other way around. Truth is, for people not using expo, setting up unimodules or any of the expo boilerplate is not an option.

[fabOnReact]

@MarcoScabbiolo @cristianoccazinsp

SUMMARY

React Native needs an objective/target.

Expo Objective is not to compete with Native/Android Sdk Mobile Development, but an alternative to Native Mobile Dev and I believe they will be successfull.

https://youtu.be/7-t6deIO1JE?t=1096

LONG VERSION

I'm trying/imagine the future of the React Native.

I believe a possible future for React Native could be Expo Managed workflow (not ejecting).

https://youtu.be/ykBxY01j_rA

Some reasons the Expo project may become successfull in the future:

• The expo documentation is excellent (for ex. like rails docs https://guides.rubyonrails.org/)
  The Developer has clear step by steps instructions on how to implement the functionalities (for ex. MapView from the basic component to the API keys)
• React Native needs to grow in popularity https://youtu.be/7-t6deIO1JE?t=1096 (targeting entry level developers that would use tools like Expo)
• Expo is more stable and reliable
• I don't think it is a big issue using unimodules and being behind with the React Native releases. React Native will allways have some limitations compared to Native Development and should not be used as replacement, but alternative. For ex. for projects that don't really need separate Android/iOS app and can adapt their app to the limitations of Expo.

Some reasons may be interesting to contribute to the Expo project:

• The Expo Projects is already setup with Javascript and Java (Android) tests, so it is easy to add new tests in .js or .java the same way like with ReactNative. I started learning Android Testing with Buck while writing my pr compute correct Keyboard Height with Notch facebook/react-native#30919. Contributing to React Native and/or Expo is for me a great learning opportunity.
• The Libraries are writted very well both in TypeScript and Java, so we can learn while reading the codebase
• I would like to be more involved in Expo Managed projects with Clients instead of React Native projects

☮️ 🙏

[MarcoScabbiolo]

@fabriziobertoglio1987 Architecture is what matters here, not "Expo vs React Native". Expo is built on top of React Native so Expo depends on React Native. Anything that works for React Native will work for Expo and native access to the camera is a core feature of native development that will be needed on many projects, implementing it only for expo would be a waste of resources since implementing it for React Native would make it available for both React Native and Expo.

If you're interested in how we can make it easier for the expo comunnity to make use of this package please create an issue about that.

[fabOnReact]

1. Identify the functionalities that are not well written in react-native-camera
2. Delete the functionalities
3. Improve the Docs
4. Open Issues - give just quick solution to each reported issue to facilitate new contributions/prs
5. Re-Open Closed Issues that are still affecting developers
6. Move the project to manteinance mode, meaning, changes are driven by contributed patches. Only bug fixes and minor enhancements will be considered.
7. Optional - Copy the functionality from expo-camera

[452MJ]

Can we support scan QR code from local image?

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. You may also mark this issue as a "discussion" and i will leave this open.

[stale]

Closing this issue after a prolonged period of inactivity. Fell free to reopen this issue, if this still affecting you.