Speech recognition activity life cycle

Make sure you're aware of the differences between the life cycle of the session object and your speech-enabled activities; they have important implications for the correct places to call various API methods.

Session object lifetime

The shared session object has a lifetime equal to that of your Android app. It can be in one of the following states: open, closed or disabled.

In the disabled state, any API method calls are ignored with no effect or error indication. Speech recognition will be disabled if an empty or a null string is passed as either the license or the partner GUID in the open() method call and this state is retained while the app is running.

The session object is initially in the closed state. You must first call open() with the appropriate arguments to open the session, then you can call other API methods, such as startRecording() or stopRecording(). You can close the session with the close() call and then reopen it.

Android activity life cycle

• The life cycle of an Android activity is significantly different from the entire Android app's life cycle (for more information, see: https://developer.android.com/guide/components/activities.html).

• An activity can be destroyed and recreated at any time, possibly quite often (for example, when the user rotates the device).

• The entire app can be killed (for example, due to errors or resource limitations); it will be restarted with the last visible activity displayed.

Considerations when integrating Dragon Medical SpeechKit

• Don't call any API methods from the onCreate() method of your activity. In particular, don't open your session here as this method might be called very often. This could result in impaired speech recognition functionality due to the session being frequently closed and reopened.

• Provide a separate, non-speech-enabled logon activity in your app and open the session from here; for example, from the event handler method that's invoked when the user has entered their user name.

• If your app needs to reopen the session, make sure it closes it first at the proper place, for example, on return to the logon activity.

• It might (rarely) happen that your app is killed and later restarted when a speech-enabled activity has the focus. As the session object has the same life cycle as your app, it'll be recreated in a closed state. In this case, most API calls, including startRecording() and stopRecording(), are ignored silently. The user needs to leave the speech-enabled activity, go back to the logon dialog box and log on again to be able to use speech recognition functionality (however they can continue to work with your app without speech recognition).