OK, I have a question. First, look at this code fr...
# getting-started
OK, I have a question. First, look at this code from Android Studio from the cameraxBasic app I am working on.
Copy code
imageCapture.takePicture(cameraExecutor,  object : ImageCapture.OnImageCapturedCallback() {
                        override fun onError(exc: ImageCaptureException) {
                            Log.e(TAG, "Mem Photo capture failed: ${exc.message}", exc)
                        override fun onCaptureSuccess(image : ImageProxy) {
                            Log.i(TAG, "Mem Photo capture succeeded")
                            var info = image.imageInfo
                            var x = 1
So WTF is happening here:
Copy code
object : ImageCapture.OnImageCapturedCallback() {}
Here's what I think is happening: 1. an ImageCapture object is being created and named object 2. The onImageCapturedCallback is being set to the blog of code between the {} (more or less) Is this correct? It works, but the semantics of this are not clear. oy. Or: Is it an object expression that is creating an anonymous ImageCapture object while replacing OnImageCapturedCallback ? My brain hurts.
object :
is creating an anonymous object inheriting from a supertype. Kotlin docs. You could equally extract this to a private class somewhere in scope
class MyCallBack : ImageCapture.OnImageCapturedCallback() { … }
. Within that object you are implementing/overriding the
Thanks. So its: 1. defining an anonymous class from supertype ImageCapture 2. instantiating it 3. over-riding 2 methods. In in that order, right? Why doesn't the constructor associate with ImageCapture? Why is it not ImageCapture().OnImageCapturedCallback {} ?
@Chris Lee Also, beer on me if we're ever in person.
the supertype is an inner class
inside of
. Its that class that is the supertype and requires the
. 🍻
it's the same as writing
Copy code
new ImageCapture.OnImageCapturedCallback() {}
in Java, but makes it more obvious that something other than an ordinary object instantiation is happening
(also Kotlin's syntax allows for implementing multiple interfaces at once, which Java's syntax doesn't have a way to express)
☝️ 2
thank you color 1
A final point worth noting is that this syntax is a little clunky and not so common because OnImageCapturedCallback is a Java style interface (technically abstract class but that doesn't matter here). It's much more common/ idiomatic in kotlin to use functional parameters or SAM interfaces
So if camerax didn't need to support (especially old versions of) Java it'd probably look something like
Copy code
executor : Executor,
onSuccess: (ImageProxy) -> Unit,
onError: (ImageCaptureException) -> Unit
So is this the whole point? I find Kotlin needless abstruse and opaque. I think it requires far to much mental scaffolding to be used by non-expert programmers.
that said, @Robert Williams this is super helpful as a way of conceptually thinking about it, so thanks.