[camera] Add CameraSelector class to CameraX plugin

[camsim99]

Adds CameraSelector class wrapper to CameraX plugin.

Part of flutter/flutter#111124.

Pre-launch Checklist

• I read the Contributor Guide and followed the process outlined there for submitting PRs.
• I read the Tree Hygiene wiki page, which explains my responsibilities.
• I read and followed the relevant style guides and ran the auto-formatter. (Unlike the flutter/flutter repo, the flutter/plugins repo does use dart format.)
• I signed the CLA.
• The title of the PR starts with the name of the plugin surrounded by square brackets, e.g. [shared_preferences]
• I listed at least one issue that this PR fixes in the description above.
• I updated pubspec.yaml with an appropriate new version according to the pub versioning philosophy, or this PR is exempt from version changes.
• I updated CHANGELOG.md to add a description of the change, following repository CHANGELOG style.
• I updated/added relevant documentation (doc comments with ///).
• I added new tests to check the change I am making, or this PR is test-exempt.
• All existing and new tests are passing.

If you need help, consider asking for advice on the #hackers-new channel on Discord.

[bparrishMines]

Since this class is used in multiple methods, you could make it a private field in the constructor.

[camsim99]

The other method uses CameraSelectorFlutterApiImpl. I don't plan on implementing any other methods in this class for now (flutter/flutter#111124), so I'l leave them as local variables, but can definitely change that if I end up reusing either!

[bparrishMines]

I think a better pattern would be to change this to a create method with this value as a parameter. And then the Dart class would have an additional normal constructor that sets this field. e.g.

class CameraSelector extends JavaObject {
  CameraSelector({
    int lensFacing,
    super.binaryMessenger,
    super.instanceManager,
  })  : _api = CameraSelectorHostApiImpl(
          binaryMessenger: binaryMessenger,
          instanceManager: instanceManager,
        ),
        super.detached() {
    AndroidCameraXCameraFlutterApis.instance.ensureSetUp();
    _api.createFromInstances(this, lensFacing);
  }
}

[bparrishMines]

And the create method

1. Create the builder
2. set the lens facing.
3. Build the selector
4. add the selector to the instancemanager

[camsim99]

Is this the pattern you've typically followed for the builder pattern? I think this makes sense but just wondering about the context on moving away from the Android Api.

[bparrishMines]

So in most situations, we do want to follow the Java API because it makes our wrapper API more resistant to changes of the Java API. However, the pattern explained above is often considered, unofficially, as the "Dart equivalent" to the Java Builder Pattern. The main reason you never see the builder pattern in Dart is because Dart has language features that makes it obsolete.

So in situations like this, where a superior Dart equivalent pattern exists, we can go with the "Dartier" pattern. It should also probably be considered case by case. As far as I can tell, I don't see any downsides to doing it for CameraSelector.

[bparrishMines]

I don't know if this is guaranteed to be correct that the Java:

DEFAULT_BACK_CAMERA == new CameraSelector.Builder().requireLensFacing(LENS_FACING_BACK).build()

I think this method could use the attach pattern from the Wrapping Native Apis doc. It would also make it synchronous. e.g.

static CameraSelector defaultFrontCamera({
  BinaryMessenger? binaryMessenger,
  InstanceManager? instanceManager,
}) {
  final CameraSelector cameraSelector = CameraSelector.detached();
  CameraSelectorHostApiImpl(
    binaryMessenger: binaryMessenger,
    instanceManager: instanceManager,
  ).attachDefaultFrontCameraFromInstances(cameraSelector);
  return cameraSelector;
}

[camsim99]

I confirmed they are equivalent: https://android.googlesource.com/platform/frameworks/support/+/f2e05c341382db64d127118a13451dcaa554b702/camera/camera-core/src/main/java/androidx/camera/core/CameraSelector.java#47

[bparrishMines]

This method implementation is a good sign for me to make improvements to this design. Nothing needs to be done for this comment, I'm just letting you know that I'm going to work on helper methods for InstanceManager to improve working with Lists.

[camsim99]

Gotcha. I agree that would be super useful!

[bparrishMines]

LGTM

[bparrishMines]

Optional:

So having a settable parameter like this is pretty typical for testing the create methods in host apis. However, most classes don't use builders and you will have to test the constructor. It's worth considering using a proxy class to handle all your class instantiations and static methods. For example

class CameraXProxy {
  CameraSelector createCameraSelector(lensFacing) {
   // build and return
  }

  ACameraXClass createACameraXClass() {
    return new ACameraXClass();
  }

  void staticMethodForACameraXClass() {
    ACameraXClass.staticMethod();
  }
}

And then you can add this value to any HostApi that has a create method. And mock it in tests.

You could also create a separate proxy for each host api. (e.g. CameraSelectorProxy).