Configuration and Runtime
SpeechTiles Andamento separates the declarative conversation from the Swift application that hosts it. JSON configuration defines conversation flow and reusable prompt behavior; STConversationRunner loads those definitions, provides runtime data, and controls execution. STMediaRunner provides direct media operations.
What belongs where?
- Swift API: initialization, permission requests, callbacks, resource setup, loading, execution and control; see STConversationRunner.
- Conversation JSON: modules, prompts, transitions, recording and recognition behavior; see Conversation Configuration.
- Prompt Modules: reusable prompt definitions; see Prompt Modules.
- Resource mapping: associations between audio resources and text; see Audio Resource to Text Mapping.
Loading configurations and resources
For in-memory JSON, use the relevant (JSON) loading overloads, such as loadConversation (JSON) and loadAudioPromptModules (JSON). These do not require a resource-directory lookup for the supplied JSON data.
For file-based loading, use the (URL) overloads, such as loadConversation (URL) and loadAudioPromptModules (URL). Where appropriate, configure setResourceLocation and setLanguageFolder. The default language folder is en-US; applicable file lookups check that language-specific directory first and fall back to the parent resource directory if the file is not found.
Conversation definitions may refer to supporting audio files, speech synthesis resources, and other files. Make these resources available in the appropriate configured locations before execution. Not every conversation needs every optional resource format.
Runtime values and decisions
Set a field using setRuntimeField and read it using runtimeField. In configuration, refer to a field as $[FieldName]. Application intent decisions are supplied through setUserIntent, often inside a speech-recognition callback. When the current runtime step depends on the decision, supply it synchronously before the callback returns.
Result handling
Configuration loading is synchronous: inspect its result before calling runConversation. By contrast, successful returns from asynchronous run/control requests should not be interpreted as completion of the conversation. Use callbacks for execution progress and outcomes.
Next steps
Follow Your First Conversation for a working integration sequence, and use the Integration Checklist before shipping.