Dialogflow NLP Engine Integration in Mobile Chatbot
Dialogflow CX and Dialogflow ES are different products with different SDKs. Starting with ES and later migrating to CX means rewriting intent logic from scratch: CX's State Machine architecture is incompatible with ES's linear Flow. Choosing the version early is critical.
Where Integration Breaks
Authentication in the mobile client. Google's official documentation suggests using a service account JSON directly in the app. This is unacceptable — the private key ends up in APK/IPA. The correct approach: the mobile app sends text to your backend, the backend talks to Dialogflow via the google-cloud-dialogflow library with a service account.
For a minimal Node.js proxy, it looks like this:
const { SessionsClient } = require('@google-cloud/dialogflow-cx');
const client = new SessionsClient();
async function detectIntent(projectId, location, agentId, sessionId, text, languageCode) {
const sessionPath = client.projectLocationAgentSessionPath(
projectId, location, agentId, sessionId
);
const request = {
session: sessionPath,
queryInput: {
text: { text },
languageCode,
},
};
const [response] = await client.detectIntent(request);
return response.queryResult;
}
Multi-language support. Dialogflow supports multiple languages on one agent, but training phrases for each language are added separately. languageCode in the request determines which language set is used. Passing ru for an agent without Russian training phrases returns a fallback intent with confidence: 0.5 — the user won't understand why the bot's answer is off-topic.
Context management. In Dialogflow ES, contexts live for N turns after being set. The most common mistake is not resetting context after a scenario completes. The user finishes ordering, then asks about promotions — but the bot still waits for a delivery address because the order-address context is still active.
In CX, this is solved by explicit transitions between pages and flows, but requires more careful scenario design.
Implementation on Mobile
On Android, use OkHttp or Retrofit to call the proxy server. Generate the session ID once at session start and keep it in memory — not in SharedPreferences; sessions shouldn't survive app restarts.
class DialogflowRepository(private val api: ChatApiService) {
private val sessionId = UUID.randomUUID().toString()
suspend fun sendMessage(text: String, locale: String): ChatResponse {
return api.detectIntent(
DetectIntentRequest(
sessionId = sessionId,
text = text,
languageCode = locale
)
)
}
}
On iOS, do the same via URLSession or Alamofire. Never call Google APIs directly from the client.
Rich responses. Dialogflow can return cards, quick reply buttons, and carousels. On the mobile client, these are parsed from fulfillmentMessages / responseMessages in the response. Each message type renders as a separate view component: TextBubbleCell, ButtonsRowCell, CardCell.
Agent Design
A Dialogflow agent isn't just a tree of intents. For a production bot, you need:
- Divide intents by domain (orders, support, FAQ) and group them
- Configure fallback intent with different response variants for unclear requests
- Add Small Talk as a separate flow — otherwise the bot rudely ignores informal utterances
- Webhook fulfillment for dynamic responses (order status, stock level)
Training phrases: at least 10–15 variants per intent, or confidence will be low on natural speech.
Development Process
Audit scenarios: what problems does the bot solve, what edge cases need handling.
Design the agent in Dialogflow Console: intents, entities, contexts / flows and pages for CX.
Develop the proxy server and mobile UI.
Train and test via Dialogflow Simulator before going to production.
Timeline Estimates
Integration with a ready-made agent — 3–4 days. Developing an agent from scratch for 5–10 scenarios plus mobile client — 1.5–2 weeks.