[Camera] Made CameraController.isDisposed publicly accessible. Added unit Tests for the new implementation.

[Sempakonka]

Description

Currently when you call CameraController.Dispose() there is no way of knowing whether you disposed that CameraController.
With this PR, the user can check if that CameraController has been disposed, by getting CameraController.isDisposed.

Since the current test/camera_test.dart file contains test for the CameraController class located in the lib/new/src/camera_controller.dart I have moved it into the test/new/camera_test.dart sub folder.

I have added a new test/camera_test.dart file which contains the unit tests covering the new isDisposed property which was added to the CameraController class located in the current lib/camera.dart implementation.

Additionally I have added unit tests to the test/new/camera_test.dart file to ensure the isDisposed property (already) implemented in the CameraController class located in the lib/new/src/camera_controller.dart file is working properly.

Related Issues

Fixes flutter/flutter#51630

Checklist

Before you create this PR confirm that it meets all requirements listed below by checking the relevant checkboxes ([x]). This will ensure a smooth and quick review process.

• I read the Contributor Guide and followed the process outlined there for submitting PRs.
• My PR includes unit or integration tests for all changed/updated/fixed behaviors (See Contributor Guide).
• All existing and new tests are passing.
• I updated/added relevant documentation (doc comments with ///).
• The analyzer (flutter analyze) does not report any problems on my PR.
• I read and followed the Flutter Style Guide.
• The title of the PR starts with the name of the plugin surrounded by square brackets, e.g. [shared_preferences]
• I updated pubspec.yaml with an appropriate new version according to the pub versioning philosophy.
• I updated CHANGELOG.md to add a description of the change.
• I signed the CLA.
• I am willing to follow-up on review comments in a timely manner.

Breaking Change

Does your PR require plugin users to manually update their apps to accommodate your change?

• Yes, this is a breaking change (please indicate a breaking change in CHANGELOG.md and increment major revision).
• No, this is not a breaking change.

[google-cla]

All (the pull request submitter and all commit authors) CLAs are signed, but one or more commits were authored or co-authored by someone other than the pull request submitter.

We need to confirm that all authors are ok with their commits being contributed to this project. Please have them confirm that by leaving a comment that contains only @googlebot I consent. in this pull request.

Note to project maintainer: There may be cases where the author cannot leave a comment, or the comment is not properly detected as consent. In those cases, you can manually confirm consent of the commit author(s), and set the cla label to yes (if enabled on your project).

ℹ️ Googlers: Go here for more info.

[google-cla]

All (the pull request submitter and all commit authors) CLAs are signed, but one or more commits were authored or co-authored by someone other than the pull request submitter.

We need to confirm that all authors are ok with their commits being contributed to this project. Please have them confirm that by leaving a comment that contains only @googlebot I consent. in this pull request.

Note to project maintainer: There may be cases where the author cannot leave a comment, or the comment is not properly detected as consent. In those cases, you can manually confirm consent of the commit author(s), and set the cla label to yes (if enabled on your project).

ℹ️ Googlers: Go here for more info.

[google-cla]

All (the pull request submitter and all commit authors) CLAs are signed, but one or more commits were authored or co-authored by someone other than the pull request submitter.

We need to confirm that all authors are ok with their commits being contributed to this project. Please have them confirm that by leaving a comment that contains only @googlebot I consent. in this pull request.

Note to project maintainer: There may be cases where the author cannot leave a comment, or the comment is not properly detected as consent. In those cases, you can manually confirm consent of the commit author(s), and set the cla label to yes (if enabled on your project).

ℹ️ Googlers: Go here for more info.

[mvanbeusekom]

@googlebot I consent.

[dnfield]

we typically expose things like this guarded by asserts, so they're only valid in debug mode.

This is to discourage people from adding checks like this to release mode code, where it should never really be necessary.

IOW, making it easier to assert program correctness is great. Allowing someone to bog down code with 1000s of small checks that really should only be done during development is not as preferable.

[mvanbeusekom]

thank you for providing feedback. I agree with the idea on only allowing this during during development. However I am not really sure how to "expose things like this guarded by asserts"?

Does this imply we don't expose a property but rather add assert statements to the methods? I feel a bit stupid here :P, but I just cannot wrap my head around it.

[dnfield]

Suggested change

	/// True after [CameraController.dispose] has completed successfully.
	bool get isDisposed => _isDisposed;
	/// Checks whether [CameraController.dispose] has completed successfully.
	///
	/// This is a no-op when asserts are disabled.
	void debugDisposed() => assert(_isDisposed);

[dnfield]

Or maybe debugCheckDisposed or something.

[mvanbeusekom]

@bparrishMines what do you think?

In general it would be bad to have any code that can potentially access the CameraController when it is already disposed. This means having the debugCheckIsDisposed around should be helpful for developers trying to debug their application, but should not be used in production. This will also prevent code constructs like this, which has high risk on state conflicts:

var cameraController = CameraController();

// do stuff with the camera controller
...

if (cameraController.isDisposed) {
  cameraController = CameraController();
}

// continue doing stuff with the camera controller

[bparrishMines]

Yea, that makes sense to avoid that type of pattern. I'm fine with going with a debugCheckIsDisposed instead.

[mvanbeusekom]

@dnfield thank you for clarifying the coding structure that was very helpful. I took your recommendations and updates the pull request.

Note that I had to change:

void debugCheckIsDisposed() => assert(_isDisposed);

to:

void debugCheckIsDisposed() {
  assert(_isDisposed);
}

otherwise we would receive a compile error.

I would appreciate it if you could have another look.

[dnfield]

This should be guarded by asserts to discourage use in release mode.

[dnfield]

LGTM if LG to @bparrishMines

[bparrishMines]

Everything looks good! Just one small comment on the test.

[bparrishMines]

I believe returnsNormally is the standard way to make sure no Exception is thrown.

expect(() => controller.debugCheckIsDisposed(), returnsNormally);

[bparrishMines]

LGTM

I can merge for you once tests pass again.

[mvanbeusekom]

Noticed that flutter format failed. I pushed a fix and will monitor the CI and merge when it is all green. Thank you for reviewing so quickly!