gluonhq / attach

GNU General Public License v3.0
49 stars 26 forks source link

iOS Barcodescan Service sends 'nil' results #306

Closed molbertz closed 2 years ago

molbertz commented 2 years ago

I have some iPads where the scan window simply closes and returns an empty value.

I've looked at the code and I've noticed that BarcodeScan.m sometimes sends 'nil' results to the IOSBarcodeScanService.java mid scan. This leads me to believe the call public Optional<String> scan(String title, String legend, String resultText) returns prematurely. That seems to be some kind of race condition, though. Because apparently the scan window only closes once a valid value is detected. And yet the service call returns with nothing.

The logs support my theory as they show multiple AttachLog(@"String: none"); but also lots of valid results via AttachLog(@"String: %@", detectionString);.

If I understand correctly once a call to: sendScanResult() is made, the service call (IOSBarcodeScanService.java) returns the given value to the user's code. So why would the code in BarcodeScan.m essentially end the service call if one AVMetadataObject contains no valid string result? The other objects in the metadataObjects array might contain valid results. Also, as far as I know the entire captureOutput method gets called multiple times by the OS. So many more chances for valid results.

Conclusion: I suggest simply removing the lines 283 and 284 in BarcodeScan.m as they seem to cause problems on some devices. Also, I don't see the value in sending an empty result mid scan. I tested this already by building the service myself and it now works on all my devices.

So. Have I made some mistakes in my research? Are the lines 283 and 284 there for a reason?

jperedadnr commented 2 years ago

Thanks for your report. Your conclusion seems accurate.

Which iOS versions or iPhone/iPad devices are you using?

molbertz commented 2 years ago

Hi,

Thanks for reviewing my findings. So the issue occurred over a number of devices with different iOS versions. So, I'm not sure how helpful this info will be. The issue happened using:

The following device however did not show the issue at all:

jperedadnr commented 2 years ago

Thanks, that is helpful. We have already merged a possible fix with your suggestion, so if you are able to test again with the 4.0.15-SNAPSHOT, that would be great. Just add this plugin repository to your pom:

    <pluginRepositories>
        <pluginRepository>
            <id>Snapshots</id>
            <url>http://oss.sonatype.org/content/repositories/snapshots/</url>
        </pluginRepository>
    </pluginRepositories>
molbertz commented 2 years ago

Thanks. I'll give this a try. I can't exactly say when I'll get to it, though. I hope to fit this into my schedule for the next couple of days.

molbertz commented 2 years ago

I didn't have the time to check the snapshot yet. But I looked at the merge request. It's quite literally the same thing I changed when I compiled the service locally. So, I guess unless other things changed it should be alright.