Skip to content
This repository was archived by the owner on Feb 22, 2023. It is now read-only.

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

Merged
merged 8 commits into from
Nov 10, 2020

Conversation

Sempakonka
Copy link
Contributor

@Sempakonka Sempakonka commented Oct 23, 2020

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
Copy link

google-cla bot commented Nov 5, 2020

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
Copy link

google-cla bot commented Nov 5, 2020

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.

1 similar comment
@google-cla
Copy link

google-cla bot commented Nov 5, 2020

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
Copy link
Contributor

@googlebot I consent.

@google-cla google-cla bot added cla: yes and removed cla: no labels Nov 5, 2020
Comment on lines 310 to 311
/// True after [CameraController.dispose] has completed successfully.
bool get isDisposed => _isDisposed;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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);

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Or maybe debugCheckDisposed or something.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@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

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@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.

Copy link
Contributor

@dnfield dnfield left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor

@dnfield dnfield left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM if LG to @bparrishMines

Copy link
Contributor

@bparrishMines bparrishMines left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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


controller.dispose();

try {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

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

Copy link
Contributor

@bparrishMines bparrishMines left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

I can merge for you once tests pass again.

@mvanbeusekom
Copy link
Contributor

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!

@mvanbeusekom mvanbeusekom merged commit ee1dbfa into flutter:master Nov 10, 2020
@mvanbeusekom mvanbeusekom deleted the issue-51630 branch November 10, 2020 06:50
fesp pushed a commit to fesp/plugins that referenced this pull request Nov 11, 2020
…unit Tests for the new implementation. (flutter#3193)

* Update feedback from Flutter team

* Removed obsolete dependency on mockito

* Apply feedback on pull request

* Bump version number

* Update CHANGELOG description to reflect changes

* Fix formatting

* Refactor try..catch to returnsNormally

* Fix formatting issues

Co-authored-by: Maurits van Beusekom <[email protected]>
FlutterSu pushed a commit to FlutterSu/flutter-plugins that referenced this pull request Nov 20, 2020
…unit Tests for the new implementation. (flutter#3193)

* Update feedback from Flutter team

* Removed obsolete dependency on mockito

* Apply feedback on pull request

* Bump version number

* Update CHANGELOG description to reflect changes

* Fix formatting

* Refactor try..catch to returnsNormally

* Fix formatting issues

Co-authored-by: Maurits van Beusekom <[email protected]>
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Camera Plugin doesn't dispose the controller by .dispose()
4 participants