-
Notifications
You must be signed in to change notification settings - Fork 309
Open camera to take and share a photo #61
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
As Alex points out in discussion: https://chat.zulip.org/#narrow/stream/243-mobile-team/topic/flutter.3A.20http.20.60Client.60/near/1545511 > Looks like doing so will allow connection reuse, which is a great > performance boost, particularly with HTTP/2. So that seems good. This will also help with file uploads (zulip#56, zulip#57, and zulip#61) because http.Client has a `send` method -- https://pub.dev/documentation/http/latest/http/Client/send.html -- that we can use for requests we want more control over (in particular, a file-upload request), and a counterpart toplevel convenience function like `http.send` isn't offered. See doc: https://pub.dev/documentation/http/latest/http/Client-class.html
As Alex points out in discussion: https://chat.zulip.org/#narrow/stream/243-mobile-team/topic/flutter.3A.20http.20.60Client.60/near/1545511 > Looks like doing so will allow connection reuse, which is a great > performance boost, particularly with HTTP/2. So that seems good. This will also help with file uploads (zulip#56, zulip#57, and zulip#61) because http.Client has a `send` method -- https://pub.dev/documentation/http/latest/http/Client/send.html -- that we can use for requests we want more control over (in particular, a file-upload request), and a counterpart toplevel convenience function like `http.send` isn't offered. See doc: https://pub.dev/documentation/http/latest/http/Client-class.html
As Alex points out in discussion: https://chat.zulip.org/#narrow/stream/243-mobile-team/topic/flutter.3A.20http.20.60Client.60/near/1545511 > Looks like doing so will allow connection reuse, which is a great > performance boost, particularly with HTTP/2. So that seems good. This will also help with file uploads (zulip#56, zulip#57, and zulip#61) because http.Client has a `send` method -- https://pub.dev/documentation/http/latest/http/Client/send.html -- that we can use for requests we want more control over (in particular, a file-upload request), and a counterpart toplevel convenience function like `http.send` isn't offered. See doc: https://pub.dev/documentation/http/latest/http/Client-class.html
For this feature, a convenient API will let us take the user to a native camera UI, then take them back to the app with a picture or video so we can upload it. I'm not finding an API like that in the At a glance, it looks like Flutter's first-party plugin |
Hmm, ideally we'd open a platform interface that lets you choose between taking a photo and a video. Would it be clunky to have two buttons for camera capture: one for photos, and one for videos? Also, |
Hmm, I see. Yeah, that's not the kind of API we want here. I guess I think it's fine to not support taking a video. |
Toward zulip#61, "Open camera to take and share a photo".
Toward zulip#61, "Open camera to take and share a photo".
Toward zulip#61, "Open camera to take and share a photo".
This is the feature indicated by a "camera" icon below the compose box in the zulip-mobile RN app. It's a standard, expected feature for a messaging application on a mobile device.
Flutter has a first-party plugin for this: https://pub.dev/packages/camera and that's probably what we want to use.
Further notes on the
camera
plugin:The plugin's Android implementation is being rewritten to use Android's new CameraX API.
Design doc gives some background:
Android upstream has invested in solving that problem (see the photo of an automated physical-phone-with-camera test lab in the CameraX doc), and CameraX is the result.
Tracked as a GitHub project board; see as issue search.
So at present the plugin is less reliable on Android than one would like. But probably our best path to solve that is to just go ahead and use the first-party plugin, and wait for it to improve with the switch to CameraX.
Meanwhile on the iOS side:
The text was updated successfully, but these errors were encountered: