That can't happen automatically anymore since there's now a setting
to automatically put the barcode contents into the clipboard. If that
is enabled, it'd interfere with this.
Also, it's probably better to make it explict anyway.
Not everybody wants to have passwords in the clipboard.
Automatically, always, in the background.
This setting should come with a warning that, if enabled, all your
scans may leak into other apps through the clipboard.
You know, there are apps that continously probe the cliboard in the
background to send any data they find to their server. Nasty stuff.
Sometimes, on some devices, the soft keyboard takes a bit too long
to vanish and `onLayout()` seems to run while the keyboard's height
is still taken into account. Then, the crop handle may sometime end
up being in the wrong position.
I suppose it's either because `onLayout()` is somehow not invoked
again after the soft keyboard is gone, or because the `changed`
parameter is `false` (despite `bottom` has changed).
This may be because the view itself isn't resized by the soft
keyboard (because of View.SYSTEM_UI_FLAG_LAYOUT_FULLSCREEN) but only
gets bottom padding from `WindowInsets` when the soft keyboard is
visible.
So, because this is quite hard to provoke, I will simply remove
doing nothing when `changed` is `true` and simply (re-)calculate
the position of the crop handle for every `onLayout()`.
CameraView.previewRect may be larger than the screen (and thus as
the DetectorView which is at most as big as the screen).
If previewRect is larger, its left and/or top coordinate will be
negative which must then be clamped to the screen/DetectorView.
This is quite a hack to ensure this app builds *without* the NDK
because using the NDK will produce broken builds for Android 6.
For details see:
https://github.com/markusfisch/BinaryEye/issues/111
Unfortunately, it's (currently) not possible to configure Gradle
to simply ignore the NDK. `nkd.dir` cannot be set to nothing or
an invalid value.
Because the TRY_HARDER flag is always set when scanning still
images, ZXing may take quite some time on slow devices. So it's
better to run it in a background thread.
Because they're always discrete values and can never be inbetween.
Also, calling `drawBitmap()` with float values can lead to slightly
distorted renderings because the image is interpolated between
pixels then.
So let's just avoid this by using integers.
It's probably better to restore the original situation than
having the button stay where it is.
Also clean up DetectorView a bit and refactor some variables.