Microsoft.Maui.Devices.Flashlight: Check if supported

[vividos]

Description

The Microsoft.Maui.Devices.Flashlight (and IFlashlight) API is useful for turning on/off the flashlight on the device's back. Unfortunately, there's no way to check if a flashlight is available in the device at all. When displaying an UI element like a switch, there's no way to hide the UI element when the hardware doesn't support turning on/off.

Public API Changes

My suggestion: A new property in Flashlight and Flashlight:

public interface IFlashlight
{
    bool IsSupported { get; }
}
public static class Flashlight
{
    public static bool IsSupported { get; }
}

The implementation should be fairly easy, since the platform implementations already check if the flashlight is available, and some even have a private IsSupported property.

Intended Use-Case

The use case would be to check if a flashlight is available before offering the user a way to switch on/off the flashlight.

[Ghostbird]

Excellent idea. I'm currently using this workaround:

  static bool? hasFlashlight = null;
  public static async Task<bool> HasFlashlight()
  {
    if (hasFlashlight is null)
    {
      try
      {
        // Trying to turn off the flashlight wil throw if there is no flashlight. I haven't found a better way yet.
        await Flashlight.TurnOffAsync();
        hasFlashlight = true;
      }
      catch
      {
        hasFlashlight = false;
      }
    }
    return (bool)hasFlashlight;
  }

Of course this has the issue that if someone is using the torch while this code runs, it will be turned off. The chance of that happening in my app is extremely slim.

[jfversluis]

Interesting that we don't have this yet because we have it for most other things 😄

Does every platform offer this detection?

Are you by any chance offering taking this up yourself @vividos? If you are, feel free to do so, small but valuable addition I would say!

[ghost]

We've moved this issue to the Backlog milestone. This means that it is not going to be worked on for the coming release. We will reassess the backlog following the current release and consider this item at that time. To learn more about our issue management process and to have better expectation regarding different types of issues you can read our Triage Process.

[vividos]

Yes, I'll do a spec ticket if you want and can also provide a PR.

[vividos]

I checked the source code and I think it's possible to get an answer of IsSupported for every platform

[vividos]

@jfversluis I think I found out why Essentials didn't have an IsSupported property: On Windows you can only find out about Lamp objects using async. I think the API must therefore look like this:

public static async Task<bool> GetIsSupported()

Alternative method names could be GetSupported(), CheckSupported() or IsSupportedAsync(). I didn't find a similar method call in Essentials, so I guess you have to suggest something. Should I write a Spec ticket here?

[jfversluis]

I would imagine there are other places within Essentials where this was the case. Are there? How did we deal with those?

[vividos]

I checked every Essentials class; most have a bool IsSupported or bool IsXxxSupported property, and the nearest I could find was the ILauncher method Task<bool> CanOpenAsync(Uri uri); Another alternative method name I suggest: Task<bool> CheckIsSupported().

[Ghostbird]

I personally use Task<bool> IsSupported() for this for all¹ such features, including ones that could be synchronous, using the interface I've called IMaybeSupported. Because IIsSupported just looks weird. My reasoning is:

• It's convenient to have a single interface for all such things.
• Checks for supported functionality are relatively rare. I have not yet encountered any situation that where performance could be improved significantly by optimising these kind of calls.
• I haven't yet run into a situation where I had to make a calling method async specifically because this interface was asynchronous. In my case these kind of calls always ran in contexts that were asynchronous already.

1. My HasFlashlight example above proves that this is a lie. It doesn't implement that interface yet, but I'll refactor that soon.