Implementing the new camera interface in android

[hkparker]

Description:

More to be filled out here soon

Checklist:

• Tests included.
• Lint and formatter run with no errors.
• Tests all pass.

Where applicable:

• Public APIs match existing style and have Since: line.
• Any breaking changes have a deprecation path or have been discussed.
• Check for binary size increases when importing new modules.

[dweymouth]

Rather than a channel I think this should be a callback - e.g. Preview(cb func(image.Image)). With the Fyne 2.6+ threading model moving to single threaded we want to make it easier for apps to be single-threaded and avoid goroutines, which listening on a channel requires.

[dweymouth]

Or maybe int StartPreview(cb func(image.Image)) and StopPreview(int) where the int returned by StartPreview is a subscription ID used to stop the preview later (the preview only actually shuts down when there are no more subscribers.

[hkparker]

The original reason for the channel is that I have a non-blocking write into it. That way if the client reads off the channel slower than frames are coming in from android, nothing gets backed up. I suppose this behavior could be preserved just as easily with a callback; we'd just read off the channel ourselves and call the callback in a loop. I'm not strongly opinionated here, if there's a preference for the callback I'll make it so.

I don't think we should support multiple subscriptions to the same preview feed as part of Fyne however. If someone does want that behavior they could implement it themselves without too much difficulty, and I also just don't think there will be many use cases. I plan on doing multiple things with frames, for example (displaying and scanning a barcode), and it makes more sense to me to consume one feed of frames for this, and handle both use cases myself, rather than have each use case be a separate subscription.

[coveralls]

coverage: 60.169% (-0.009%) from 60.178% — bounce-chat:hkparker-camerax into fyne-io:develop

[hkparker]

Something we might want to consider for the API: a function to tell is the camera is currently streaming. I'm using this in my app now and I'm trying to make sure I stop the camera when I leave views that use it. It would be nice, in my back button handler, if I could do something like if cameraDevice.IsActive() { cameraDevice.StopPreview() }. Could be as simple as a bool we keep track of in that package.

[andydotxyz]

Something we might want to consider for the API: a function to tell is the camera is currently streaming. I'm using this in my app now and I'm trying to make sure I stop the camera when I leave views that use it. It would be nice, in my back button handler, if I could do something like if cameraDevice.IsActive() { cameraDevice.StopPreview() }. Could be as simple as a bool we keep track of in that package.

Won't the developer know that they activated the camera, and therefore that they need to clean it up?