[camera_avfoundation] Implementation swift migration - part 4 #9219
Conversation
packages/camera/camera_avfoundation/example/ios/RunnerTests/CameraTestUtils.swift
Outdated
Show resolved
Hide resolved
|
|
||
| // Import Objectice-C part of the implementation when SwiftPM is used. | ||
| #if canImport(camera_avfoundation_objc) | ||
| import camera_avfoundation_objc | ||
| @testable import camera_avfoundation_objc |
There was a problem hiding this comment.
curious does @testable import have any effect on objc modules?
There was a problem hiding this comment.
Probably not, TBH I haven't considered it. I will keep this one for consistency and we will be able to remove all of them shortly
| var getMaximumAvailableZoomFactorStub: (() -> CGFloat)? | ||
| final class MockFLTCam: NSObject, FLTCam { | ||
| var setDartApiStub: ((FCPCameraEventApi?) -> Void)? | ||
| var setOnFrameAvailableStub: (((() -> Void)?) -> Void)? |
There was a problem hiding this comment.
are these just re-ordered?
There was a problem hiding this comment.
Yes aside from some very minor renames e.g. lockCaptureStub -> lockCaptureOrientationStub because this method is finally is called properly in FLTCam
packages/camera/camera_avfoundation/example/ios/RunnerTests/PhotoCaptureTests.swift
Outdated
Show resolved
Hide resolved
packages/camera/camera_avfoundation/example/ios/RunnerTests/SampleBufferTests.swift
Outdated
Show resolved
Hide resolved
| camera?.close() | ||
| camera = newCamera | ||
|
|
||
| FLTEnsureToRunOnMainQueue { [weak self] in | ||
| guard let strongSelf = self else { return } | ||
| completion(NSNumber(value: strongSelf.registry.register(newCamera)), nil) | ||
| } | ||
| } catch let error as NSError { |
There was a problem hiding this comment.
Was the error originated from our own code or from AVFoundation?
There was a problem hiding this comment.
Both:
AVCaptureDeviceInput deviceInputWithDevice(AVFoundation)AVCaptureDevice lockForConfiguration(AVFoundation)FLTDefaultCam.setCaptureSessionPreset(our own code)
IMO the whole package deserves a clean up of errors in the future because there is absolutely no consistency in the error format
.../camera/camera_avfoundation/ios/camera_avfoundation/Sources/camera_avfoundation/FLTCam.swift
Outdated
Show resolved
Hide resolved
.../camera/camera_avfoundation/ios/camera_avfoundation/Sources/camera_avfoundation/FLTCam.swift
Outdated
Show resolved
Hide resolved
.../camera/camera_avfoundation/ios/camera_avfoundation/Sources/camera_avfoundation/FLTCam.swift
Outdated
Show resolved
Hide resolved
| import Flutter | ||
| import ObjectiveC | ||
|
|
||
| class FLTImageStreamHandler: NSObject, FlutterStreamHandler { |
There was a problem hiding this comment.
nit: final, and remove FLT
There was a problem hiding this comment.
It is extended in some tests so I'm leaving it as non-final
|
This is the main part but it's not the last. There will be a ~3 more PRs I think. ~2 with migration of all the protocols which is a formality and one with the switch to a Swift based pigeon which will include some more significant changes |
Migrates camera implementation as part of flutter/flutter#119109
This PR migrates the main
FLTCamclass to Swift. I know it's large, but I don't see any reasonable way to split it into smaller parts (MockFLTCamclean up could be separated but it won't make the review simpler in any meaningful way).Since the goal of the PR is migration to Swift the code is mostly translated close to verbatim including the known issues in
setDescriptionWhileRecordingmethod (flutter/flutter#162376 (comment))There are quite a few cases of
error as NSErrorcasting because I didn't want to introduce a breaking change so I had do keep the error message structure exactly the same as in ObjC. The errors in ObjC implementation were very closely related toNSError. I don't see a better way to handle it than castingErrorback toNSErrorbut I'm open to suggestions.Pre-Review Checklist
[shared_preferences]pubspec.yamlwith an appropriate new version according to the pub versioning philosophy, or I have commented below to indicate which version change exemption this PR falls under1.CHANGELOG.mdto add a description of the change, following repository CHANGELOG style, or I have commented below to indicate which CHANGELOG exemption this PR falls under1.///).If you need help, consider asking for advice on the #hackers-new channel on Discord.
Footnotes
Regular contributors who have demonstrated familiarity with the repository guidelines only need to comment if the PR is not auto-exempted by repo tooling. ↩ ↩2 ↩3