After reading more on this subject I came to the conclusion that the zxing.cpp variant is actually a bit silly and as with zxing_cpp, it would be yet another new name. So zxingcpp it is. As simple as that. This name is unique enough for me and adding something like com. in front of it without actually owning that domain adds no value whatsoever.

I'll push something soonish.

I pushed the changes, added a publish-android action and here is the "2.1.0-SNAPSHOT" version uploaded: https://s01.oss.sonatype.org/content/repositories/snapshots/io/github/zxing-cpp/android/2.1.0-SNAPSHOT/

Can someone find out if this now actually "works"? Are any of these two lines an issue when one want's to have a 'properly' released android library?

Can someone find out if this now actually "works"?

Hm, unless I did something silly, it doesn't work (yet):

$ ./gradlew buildDebug 
> Task :app:mapDebugSourceSetPaths FAILED

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':app:mapDebugSourceSetPaths'.
> Could not resolve all files for configuration ':app:debugRuntimeClasspath'.
   > Could not find io.github.zxing-cpp:android:2.1.0-SNAPSHOT.
     Searched in the following locations:
       - https://repo.maven.apache.org/maven2/io/github/zxing-cpp/android/2.1.0-SNAPSHOT/maven-metadata.xml
       - https://repo.maven.apache.org/maven2/io/github/zxing-cpp/android/2.1.0-SNAPSHOT/android-2.1.0-SNAPSHOT.pom
       - https://dl.google.com/dl/android/maven2/io/github/zxing-cpp/android/2.1.0-SNAPSHOT/maven-metadata.xml
       - https://dl.google.com/dl/android/maven2/io/github/zxing-cpp/android/2.1.0-SNAPSHOT/android-2.1.0-SNAPSHOT.pom
       - https://s01.oss.sonatype.org/io/github/zxing-cpp/android/2.1.0-SNAPSHOT/maven-metadata.xml
       - https://s01.oss.sonatype.org/io/github/zxing-cpp/android/2.1.0-SNAPSHOT/android-2.1.0-SNAPSHOT.pom
     Required by:
         project :app

Maybe Sonatype hasn't published this officially?

Here's a patch file to make the sample app in wrappers/android use the dependency, in case you want to try it yourself:

include_zxing_from_sonatype.patch

abiFilters += "armeabi-v7a"

Depends. If you want to support (Android apps on) Chromebooks too, then the abiFilters would be a problem. Google recommends supporting Chromebooks, of course, but you can always add support in a later version.

arguments("-DCMAKE_BUILD_TYPE=RelWithDebInfo")

Including the debug info in the native library is actually recommended by Google Play.

Thanks for your input as always. As you can see in #655, I managed to make it work for me based on your patch with an updated maven URL.

Happy to help! And sorry for the wrong URL 🙈

Hi there, I am currently pretty busy, sry for the late reply (applies to other discussions as well)!

I guess most people will use read capabilities and not so much the write part. For me your suggestions are in sound with improving the overall library usability. If all three implementations are streamlined (Android to iOS to C++) and it is published on Maven for easier usage, more people will probably use this port instead of the original ZXing.

So, the breaking changes are worth it! Thanks @markusfisch for taking the initiative to push the Android wrapper and of course @axxel for the library as a whole! It makes our lives easier :)

I could create PRs for each of these 3 areas, and this is most probably the best thing to do.

But I think one of the biggest issues with the official wrapper is that it's not published on Maven (or any repository for that matter). This makes it a lot less approachable than the Java implemenation, which is available through Maven.

Also, distributing the AAR directly doesn't provide a user with any information regarding the identity, version, or dependencies of a library. Therefore, Google strongly recommends to publish libraries using repositories rather than manually distributing AAR files.

So, like @benjohnde, I think this is probably the most important thing to push ZXingCpp for Android.

That said, it would be wise to sort some things out before publishing, of course, and this includes the 3 areas you mentioned. But there are also a few (formal) things that I would suggest changing:

1. Rename BarcodeReader to ZXingCpp for two reasons:

• perspectively we are going to include write support and then, BarcodeReader wouldn't be a good fit. Of course, we could also add BarcodeWriter, but then there is BarcodeReader.Formats, which we also want to use when writing a barcode.
• reading ZXingCpp.read() (in client code) makes it immediately clear to anyone that this is a function of ZXingCpp, whereas BarcodeReader.read() could be something of the client too.

2. Make options an argument to read() instead of a field of BarcodeReader. options is it's own object anyway, and by separating it from the object, it's clear where and when it is used. This makes the API a little bit more "pure", meaning more clear about side effects. Also, there's already read(bitmap: Bitmap, options: Options, …) so this would make the API more consistent as well.

3. Make BarcodeReader an object instead of a public class. Using object is Kotlin's way of defining a Singleton. With options being an argument, BarcodeReader can be a Singleton. Again, this makes the API more clear to the user about possible side effects, and then the user would not have to instantiate BarcodeReader but only Options.

I currently would refrain from adding write support as long as the underling interface is still only an uncommited rough sketch on my hard drive and no one is demanding it yet.

Very well, but that would mean that the Android wrapper is not "equally strong/usable" 😉 If this library should be a drop-in replacement for the Java implemenation, it needs to have write support.

I know you're in the middle of refactoring this, but this is already in use in the native library, as well as in the iOS wrapper, and in my Android wrapper. So at least we are using it, and it's really important to us. There are a lot applications for recreating a scanned barcode, for example, and I think the current solution is good enough for that. Of course, there will be improvements, even breaking changes, but this is not a good reason to not make this available now.

About the term Options: I chose that one as I got the impression that this seemed like a standard pattern on Android for this kind of data class and wanted to make it feel 'native'.

I would be very much in favor of DecodeHints, as this is the native name and also the term we used in the iOS wrapper. Yes, there are things like BitmapFactory.Options, but Options is a very general term, and here we can name things more precisely. These aren't just any options, but decoding hints, so it's better to make clear what these options are.

Then, just to mention this again so that nobody can say that nobody said anything 😉: The Android wrapper should not use ImageProxy as this requires including CameraX just for the sole reason of making BarcoderReader.read() conveniently having fewer arguments at the cost of forcing everyone to use CameraX, no matter if the app is using it or not. In my opinion, this only creates unnecessary hurdles.

Thanks @markusfisch for your valuable input. I agree with you on everything except the write-support (I understand you rely on it but I have the feeling you would keep your own fork of the wrapper anyway?) and the removal of the CameraX dependency. I'd be happy to merge a PR (single one is fine for me) that deals with all the discussed improvements.

@markusfisch do you know of a way to have the ImageProxy variant of read be somehow dependent on whether CameraX is available or not? Something along the lines of the if (Build.VERSION.SDK_INT < Build.VERSION_CODES.R) { check? Wondering whether there was a way to not force the depency on CameraX but still provide the convenient read(ImageProxy) usage if the client uses CameraX.

@axxel Well, yes, this is possible, but we would have to change the argument type (from ImageProxy) to Object and use reflection to get the relevant fields from the given (ImageProxy) object.

ImageProxy can't be used in the library directly then, because it wouldn't be there at compile time without the CameraX library.

But this would probably be quite a hack 😉

Question to all the Android folks (@markusfisch @ccrowell-kr @ISNing): Any idea why the most recent 2.3.0 publishing seemed to have failed? Is this gradle warning the problem?

It looks like the latest one succeeded, is it possible the artifact was deployed but needs to be released to maven central?

What do you mean with "succeeded"? I can't find the 2.3.0 release anywhere. When I log into the Nexus managing console (https://s01.oss.sonatype.org) - which is highly unintuitive and slow by the way - I can't find a 2.3.0 artifact anywhere.

Sorry for being ambiguous, I was saying the pipeline job you linked indicates success, so I would expect it to be available in the nexus console.

When 2.2.0 was published was it automatically 'released'?

Sorry for being ambiguous, I was saying the pipeline job you linked indicates success, so I would expect it to be available in the nexus console.

So did I. ;)

When 2.2.0 was published was it automatically 'released'?

Frankly, I don't remember. But it anyway, it certainly showed up "somewhere", while I can't find any hint at the 2.3.0 release now.