Essentials: Screenshot API

Created on 28 Mar 2018  路  11Comments  路  Source: xamarin/Essentials

Would we want a Screenshot of the current window/screen?

VS bug #735683

feature-request needs-more-discussion needs-specifications proposal up-for-grabs

Most helpful comment

This would be an awesome, very useful, addition. Question - the UWP implementation would just capture the application window, not the entire desktop, right?

All 11 comments

I would like to implement this API. Can you assign this to me?

This one needs some more discussion and specifications before it can be implemented.

  1. What is the native API like in Android, iOS, and UWP ?
  2. Do we need to make the method async?
  3. What should this return? byte[] or the filename?
  4. What format of image can this be which all platforms support?

In the past I did a PR for this API. Using this as a reference....

1. What is the native API like in Android, iOS, and UWP ?

When I implemented I did not make use of the native APIs, to ensure that the implementation was similar on all platforms.

2. Do we need to make the method async?

Yes, because in all 3 platforms we use async methods. To get the byte[] or to save the sreenshot image.

3. What should this return? byte[] or the filename?
The both. Like this:

 public static Task<string> CaptureAsync(ScreenOutputType type = ScreenOutputType.PNG, string fileName = null) =>
            PlataformCaptureAsync(type, fileName);
         public static Task<byte[]> GetImageBytesAsync(ScreenOutputType type = ScreenOutputType.PNG) =>
            PlataformGetImageBytesAsync(type);

The developer can use the byte[]when he wants to do some other image processing, such as sending to a service. And we go back the path, when developer just wants to save the image on the device.

  1. What format of image can this be which all platforms support?
    On all 3 platforms, we can convert the image to .png or .jpg .

I think if we can reasonably get a PNG back on each platform, we should just use that and not have an option for JPG (unless there's a compelling reason for needing both).

I also don't think we should have two methods returning different results. If anything we maybe need to return a ScreenshotFile type or something similar and provide the filename and helper ReadStreamAsync and ReadBytesAsync type methods. It might be worth considering if we can use the same return type we will eventually be using for the photo picker.

First, I have 2 questions:

  1. How Photo Picker works?
  2. Will the screen capture API be in which folder?

How about we return a struct containing the information of the media types, can be used in Photo Picker and other APIs that handle media files. Like that:

Task<MediaFile> CaptureAsync(string fileName)
Task<Stream>  ReadStreamAsync(MediaFile file)
Task<byte[]> ReadBytesAsync(MediaFile file)
struct  MediaFile
{
   string FileName;
   string Path;
//Add other stuffs if necessary
}

Yeah I think this is the general idea. We are planning on working on the Photo Picker as one of the next features, so I'd like to see how that one gets spec'd out before we settle on a spec for this in case we can reuse the struct from it (like a common MediaFile struct).

Saving Screenshot should be an option, develop should have both option:

  1. View the screenshot on image control
  2. Save the screenshot

Sometimes you don't want to save the screenshot but just share it then why you need to save it

If you use Google Analytics app, you'll see that screenshot for some screen is not just the screenshot but the whole page shot which means the image will be vertically saving the whole page even the place which is not shown on the screen size.

It will be great if you add this so Xamarin Essentials will have a boolean value like this:

CaptureAsync(string filename, bool fullpage)

fullpage default is false

This would be an awesome, very useful, addition. Question - the UWP implementation would just capture the application window, not the entire desktop, right?

Can be closed

Thanks!

Was this page helpful?
0 / 5 - 0 ratings