I have question, i.e., what is the case or device that doesn't have speech to text feature?

I have question, i.e., what is the case or device that doesn't have speech to text feature?

Just try uninstalling / disabling Google's speech-to-text app and other similar apps from your device. Your device would no longer have any of those services.

I got it, thanks :)

I guess these two ways can be helpful:-

1. Change visibility to none after checking if services are available or not.
2. When tapped on the icon and service is unavailable, then we can ask user to enable or install speech to text services.

@rohit9625 How about changing the color of the icon (may be to a Gray) if service is not available, unclicking the icon we can show the Toast to indicate the status of service.

@rohit9625 How about changing the color of the icon (may be to a Gray) if service is not available, unclicking the icon we can show the Toast to indicate the status of service.

That's a great idea :)

Let's see @sivaraam's thoughts also.

For now the important thing is probably: How to find out in advance whether service is available or not.

Hey @nicolas-raoul, I ran this code (https://stackoverflow.com/a/32596376) I was able to get the engines available

Here are the results

These are the same I got on going to settings of my phone

@rohit9625 How about changing the color of the icon (may be to a Gray) if service is not available, unclicking the icon we can show the Toast to indicate the status of service.

I think it might be ideal to just hide the icon altogether when no speech-to-text services are available. I don't see any point with bothering the user about it when their device doesn't have speech-to-text services. If I'm right, the Wikipedia app does the same.

I ran this code (https://stackoverflow.com/a/32596376) I was able to get the engines available

This is good. If it's helpful, this seems like the snippet that the Wikipedia app uses in order to recognize if speech-to-text services are available. We could consider using the same too. if it seems better 🙂

We have two options here:

1. Reactively update the visibility state for voice input buttons by querying if input service is available or not. In this we have to :

• query and update while binding views in adapter.
• query and update in onResume() callback. This is because there's a chance that user might enable/disable service and come back to this screen and would expect updated state of buttons visibility.

The only doubt I have about this approach is how resource intensive it going to be? So in order to query if we a service available or not. We call this method below and this is what it does internally. Call to queryIntentServices is my concern cause it query all the services and filters the one with matching intent passed to it.

   public static boolean isRecognitionAvailable(@NonNull final Context context) {
        // TODO(b/176578753): make sure this works well with system speech recognizers.
        final List<ResolveInfo> list = context.getPackageManager().queryIntentServices(
                new Intent(RecognitionService.SERVICE_INTERFACE), 0);
        return list != null && list.size() != 0;
    }

• Also, if user have service disabled or not supported on the device, with this approach user might not even know that we have this voice input feature.
• Not much of a problem but handling state is also another overhead for this. Can lead to bugs too.

2. Keep the buttons as is, check for the availability just-in-time when clicked and if not available just notify user using Toast or Snackbar.

• With this user will know that app has this feature, it's just their device does not support or it has been disabled.
• No need to manage state, we always check just-in-time.

Let me know what solution you think would be best and I will create a PR for that.
@nicolas-raoul @sivaraam

I think that checking service availability only once is fine.

If the user enables the service, the user must restart the app.

So it won't be resource-intensive.

I am in favor of not showing anything if the service is not available.

Okay, just to make sure we're on the same page, this is how it's gonna be ->

• I'll have a flag lazily initialized based on if the service is available or not, on the startup (in the application class)

• Let's take a scenario where service was enabled and user disables (probably very few cases) it. But, mic would still show since state doesn't update until next start. In that case does showing Toast/Snackbar make sense, if user try to use it?

Now, for lazy initialization, I can write it in java, since our application class CommonsApplication is in java. But we can use kotlin's lazy {} delegate to keep the code simple.

So, if there's no reason not to, can I migrate application class to kotlin first?

Let me know if my solution is okay. @nicolas-raoul

P.S: I'm sorry if you find it bothering that I'm asking too many question. I try my best not to and figure out stuff on my own :)

I'll have a flag lazily initialized based on if the service is available or not, on the startup (in the application class)

Great idea! :-)

Let's take a scenario where service was enabled and user disables (probably very few cases) it.

No need to consider this case, other than not crashing. Users can understand that if they disable it, it becomes unusable even if the icon is still present.

can I migrate application class to kotlin first?

Sure! Would you mind making it a different pull request? Thanks!

I wasn't sure whether this has been tested and merged, can someone confirm?

Thanks,

Chris.

@chrisdebian You can see the green "Open" label at the right of the referenced pull request, it means it is not merged. :-)

Thanks, I wasn't sure whether that meant it was merged :-). Can this be merged? Just trying to understand what needs to be done, next.

Thanks,

Chris