Publish Android Library #636

benjohnde · 2023-10-17T10:16:19Z

benjohnde
Oct 17, 2023

@axxel would it be okay if I invest some work to publish the Android library as well? I did so with a few of our little KMP libraries (cf. https://github.com/Liftric/KVault). We can automate all the things, so you won't have any additional work. For most people the release / artifact approach is probably working though but not super clean IMHO.

axxel · 2023-10-17T17:43:03Z

axxel
Oct 17, 2023
Maintainer

You mean Maven and/or Sonatype packages? Sounds like a good idea, judging how may people access the python wrapper via PyPi and how few seem to get the artifacts stuff or simply build themselves.

17 replies

axxel Dec 1, 2023
Maintainer

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.

axxel Dec 1, 2023
Maintainer

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?

markusfisch Dec 1, 2023

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.

axxel Dec 1, 2023
Maintainer

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.

markusfisch Dec 1, 2023

Happy to help! And sorry for the wrong URL 🙈

axxel · 2023-11-02T22:05:13Z

axxel
Nov 2, 2023
Maintainer

I'm hijacking this discussion a little bit for the sake of discussing other changes regarding the Android library in the context of a new release: I asked @markusfisch whether he would be interested in bringing some of his modifications from his own android wrapper flavor to upstream. My idea was to use this momentum we currently have regarding the iOS wrapper and bring the Android side along, trying to make them feel equally strong/usable. This will result in breaking changes but now seems to be the best time for that in my opinion. There are 3 areas that I'd like to adjust:

make the read call return a list of codes instead of just one
extend the Options struct with more DecodeHints (although not necessarily all of them)
extend the Result struct to carry more of the c++ Result members (no version and I'm not convinced of the GTIN substruct on the iOS side)

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. 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'. There is obviously an argument to be made to call it DecodeHints as well.

Comments welcome (e.g. from @benjohnde @markusfisch @okarmazin).

5 replies

benjohnde Nov 3, 2023
Author

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 :)

markusfisch Nov 3, 2023

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:

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.

Make options an argument to read() instead of a field of BarcodeReader 8000. 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.
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.

axxel Nov 6, 2023
Maintainer

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.

axxel Nov 22, 2023
Maintainer

@markusfisch do you kn 8000 ow 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.

markusfisch Nov 22, 2023

@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 😉

axxel · 2023-12-08T22:17:06Z

axxel
Dec 8, 2023
Maintainer

publishing on mavenCentral is . But there it is: https://central.sonatype.com/artifact/io.github.zxing-cpp/android Thanks for all your input and help! Lets hope this will attract new users and make all the effort worth it. ;).

5 replies

axxel Jan 6, 2025
Maintainer

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?

ccrowell-kr Jan 6, 2025

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

axxel Jan 6, 2025
Maintainer

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.

ccrowell-kr Jan 9, 2025

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'?

axxel Jan 10, 2025
Maintainer

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.

Uh oh!

Publish Android Library #636

Uh oh!

benjohnde Oct 17, 2023

Replies: 3 comments · 27 replies

Uh oh!

axxel Oct 17, 2023 Maintainer

Uh oh!

axxel Dec 1, 2023 Maintainer

Uh oh!

axxel Dec 1, 2023 Maintainer

Uh oh!

markusfisch Dec 1, 2023

Uh oh!

axxel Dec 1, 2023 Maintainer

Uh oh!

markusfisch Dec 1, 2023

Uh oh!

axxel Nov 2, 2023 Maintainer

Uh oh!

benjohnde Nov 3, 2023 Author

Uh oh!

markusfisch Nov 3, 2023

Uh oh!

axxel Nov 6, 2023 Maintainer

Uh oh!

axxel Nov 22, 2023 Maintainer

Uh oh!

markusfisch Nov 22, 2023

Uh oh!

axxel Dec 8, 2023 Maintainer

Uh oh!

axxel Jan 6, 2025 Maintainer

Uh oh!

ccrowell-kr Jan 6, 2025

Uh oh!

axxel Jan 6, 2025 Maintainer

Uh oh!

ccrowell-kr Jan 9, 2025

Uh oh!

axxel Jan 10, 2025 Maintainer

benjohnde
Oct 17, 2023

Replies: 3 comments 27 replies

axxel
Oct 17, 2023
Maintainer

axxel Dec 1, 2023
Maintainer

axxel Dec 1, 2023
Maintainer

axxel Dec 1, 2023
Maintainer

axxel
Nov 2, 2023
Maintainer

benjohnde Nov 3, 2023
Author

axxel Nov 6, 2023
Maintainer

axxel Nov 22, 2023
Maintainer

axxel
Dec 8, 2023
Maintainer

axxel Jan 6, 2025
Maintainer

axxel Jan 6, 2025
Maintainer

axxel Jan 10, 2025
Maintainer