Why does Glass/GDK based VoiceListener only catch VoiceCommand once in XE16?

Question

In search for a way to implement contextual voice commands with Google's GDK i came across this post. Yet, the example code seems to work only in XE12 not in XE16+. I tested this code recently, but the onVoiceCommand(...) method is only called once in the lifetime of a related Activity. My expectation would be that a user's voice command can be obtained multiple times, i.e., if a user returns to a certain Activity from another one.

I even tried to remove and reattach the Activity and/or Listener to the GDKs built-in VoiceInputHelper when the Activity is backgrounded via the onPause(...) and onResume(...) method, yet no success. Any helpful ideas why VoiceCommands are "gone" after one event and how they can be "reenabled"?

I can test your ideas/solutions as I have a Glass device at hand, and I verify any input rapidly.

Rustle

You should post more code. Have you tried studying the Android lifecycle and managing the listening resource through it. I am thinking if you kill the item in an onPause, and re-initialize it onResume, things might work for you. Your problem sounds like someone who has put code in onCreate and doesn't know that onCreate does not get called when an Activity is resumed. – Warnke

As linked in my original post, the code can be found here: stackoverflow.com/questions/21168267. As you can see, the methods "onResume(...)" is used... and it is called. I checked on that using a Debugger ;) – Rustle

Answer 1

The original example in at stackoverflow.com/questions/21168267 needs a small change: to work continously null needs to be returned in onVoiceCommand().

Pentagon

Thanks for your reply! This helps out here: a tested and confirmed solution on XE16.x - maybe it might be changed by the Google guys in the next releases, so keep in mind that return null might change in the future. – Rustle

It still works in XE18.11 - Just tested the solution; the only adaptation needed was to fetch the internal GlassVoice.apk in its current version from the device itself, again. The rest of the code-example seems to be working fine at runtime. – Rustle