I have a bot working on Teams and I'm able to fetch the user's Identity using the TeamsInfo. Now I want to get the same bot running on a web site (via direct line) albeit with lesser functionality and a different method of identifying the user.
I'm using TeamsActivityHandler as teams specific features (task module, messaging extensions) are being used.
As I want the flow to be different so I understand that I would need separate dialogs. I'm confused on how to approach this with activity handlers? Do I need separate activity handlers or lots of if conditions in one?
PS. I have looked for sample and articles online but didn't find anything about one bot running on multiple channels supporting different features; I can share some code if needed.
Related
These days I am finding myself in the position of having to implement for one of my college courses a system that should act as a giant wrapper over many communications apps like Gmail , Facebook Messenger maybe even WhatsApp .To put it simply you should have a giant web interface where you can authorize Gmail , Messenger and use them at once when required. I am thinking of going with an REST API to manage the user's services authorized by OAuth2.Also I am thinking of using Node.JS and Express.js in the backend and React.js in the frontend. I found some sweet libraries in npm that should take care of interacting with the involved APIs(https://www.npmjs.com/package/node-gmail-api this one for instance), but I am also doubtful about this approach , for example I have no idea how to keep the use notified about its incoming mails or messages for example . I am in dire need of some expertise since I forgot to mention but I am quite the newbie in this field. To sum it up for once my question is how would you implement such an infrastructure ? Is it my approach viable or I am bound to hit some really hard to overcome obstacles?
As a college exercise, it would be a really fun experiment, so it definitely worth the time you want to put into it. However, once you want to add more features, the complexity will go up pretty fast.
Here are a couple of ideas you can think of:
It's pretty clear that your system can't do more things than the capabilities exposed by the APIs of communication apps (e.g. you can't have notifications in gmail if the API doesn't have this capability).
For that reason, you should carefully study the APIs and what functionalities they expose. They have public docs that you can check out: (Gmail API, Facebook Messanger API)
Some of the apps you want to communicate with may not have an official API (e.g. WhatsApp) - those kinds of details you definitely want to know from the start.
Based on the analysis of those APIs, you should lay out a list of requirements for your system, which can be extracted from all the APIs, for example: message notifications, file transfers, user profiles, etc.
In this way, you know exactly what capabilities your system should have, and you don't end up implementing a feature that is available only in 1 API out of 4.
Also, it would be a bit challenging to design your system from a user perspective, because the apps have different usage patterns - chat apps, where messages are coming in real-time, vs email, which is not real-time communication. That's just a detail anyway, the gist of your project is to play with those APIs.
Also, it may worth checking out the Gateway Aggergation Pattern, which is related to this project - you may want the user to send a message to multiple apps, by using a single request to your service.
I'm using Google Dialogflow (former API.ai) with one agent, and I would like to be able to handle queries for many different customers with one agent.
The reason behind this is that I simply can't create one new GCD project / agent for each customer, due to the overhead and the quota limits on GCD projects.
I am looking for suggestions on tackling this. I am afraid that Dialogflow's algorithm will be cluttered and start confusing intents if I add too many of them that are closely related. I would like the agent to only go through the customer's list of intents and not the whole list of intents.
At the same time, I have common Small Talk intents that should be shared between clients. This means that setting the context as the client's ID may not be a fully viable solution, because the common pool of intents will not be used then.
To sum up, there are:
Common intents, shared between all clients (small talk for instance)
Client-specific intents (for instance, "What is [client-specific acronym]?")
How can I identify my user's (attached to one client) intent (ideally in a single request) given this set-up?
Thank you.
What you're doing is probably sufficient for simple agents.
For more complicated agents, you might want to identify the client in the webhook for the first Intent (which you certainly have to do anyway) and then set a long-lived context for just that client. Then you can have other Intents which are tailored for the client and only get triggered if the context is present. To be clear, and quoting the documentation:
Input contexts limit intents to be matched only when certain contexts are set.
If you have components of the conversation that apply to all of them (small talk, common questions about using the service, etc) then you could make those versions not require a Context. If you have fulfillment for them, you'll still get any Contexts (and their parameters) that are active, so you can handle with client-specific information still.
Finally, however - you shouldn't worry too much about how many projects you have. If you get close to the limit, you can request a higher quota.
I apologize for the question but I don't have the resources to figure it out myself.
I'm looking for features my next iOS / android app should have and as you can imagine, I'm interested on a "pinch of social" that's why getsream seems to be my saver.
After reading the getting started section and the documentation, I found this warning http://getstream.io/docs/#mobile that confuses me.
I supposed getstream is a managed service that takes care of everything letting me use the REST API to build my mobile community within their phones.
Could you please tell me where I'm wrong?
Many thanks
There are two main reasons we do not recommend integrating Getstream client side (i.e. in the browser or on mobile). First, it is hard to guarantee security when you integrate from the client-side, you have to somehow provision tokens for each user's feed (and feeds they want to target with activities http://getstream.io/docs/#targetting), you could also generate an application wide (read/write) token and ship this to all clients but this is also a bad idea for obvious reasons. Second, we do not recommend using Getstream to store all your activity data, you store references to objects in your local database and enrich the activities from getstream at read time (have a look at our integration libraries for Django/Rails).
I am making a game with Google Hangout where I need to control which participant could communicate with others.
I want to be sure that players could not change the list of participant he could see by calling a javascript function. Because from what I understand each participant could change his visibility of other participants, and I want to block that.
So I wonder if it is possible to control the visibility between participants at server-side.
Short answer: No.
Medium answer: It really depends exactly what you need, but probably not.
Much longer answer:
It sounds like you want finer grained control over both visibility and message sending/state sharing than the Hangout API allows for. The Hangout API reflects what participants can see in the actual hangout today - everyone else who is in the hangout. The shared state is shared with all other members of the hangout running the same app, and the visibility is for all users in the hangout or the same app.
If you want to restrict or limit this (for example, if people are divided into teams and you want a "team chat"), you would need to use your own server to coordinate this communication, on at least some level. Your server would either need to actually do the communication between team members, or distribute a shared secret that each team would use as a cypher for their shared state.
One possible trickier solution might be to have each team run a different app. Since each app only shares state with the same app running on another participants machine, and can list only the other members who are running the same app, this might be a valid solution in some cases.
I am still a relative newcomer to Expression Engine as a developer and a user. I am faced with the problem that a lot of my knowledge is being passed to me by users who have found ways to accomplish tasks traditionally undertaken by developers (eg product libraries) by using the channels system.
What I wondered was what people's views are on when it is best to advise a client to use this and when not to.
Let me use an example, a client wants a system which had venues where events could take place. The previous developer had chosen to use the membership system for the venues and the channels system for the events and write some custom code to attempt to knit the two together, specifically because there are not enough hooks to accomplish some background automated tasks like looking up the long/lat of the address of a venue when it is created or updated.
I am picking up after someone else's work largely but its not their fault, it was the information they were given as they were also new to the system.
In any other project this would be a master-detail type setup, events belong to venues, i'd probably write 2 custom tables, editors in the admin area via modules and then use regular custom code in the pages to display and act upon the info - this way, I could control what's happening when a user hits submit.
However, the instigating party is a veteran user of Expression Engine and instructed the previous developer in the manner of "oh, just put it all in the channels and then there's this tag and that tag and so on".
So, am I missing the point or am I right that this does not fit the channels system and when should you use channels and when not?
Thanks friends.
This question is very hypothetical and every developer will give you a different answer as it all depends on the requirement and how that EE developer rolls.
Fundamentally ExpressionEngine allows you to approach builds in many ways, none are right and wrong, albeit some are easier, some harder, others just plain daft.
Basically Channels are groups of data "entries" - these can be anything. Using your example, venues could be one channel with fields created relevant to the subject (e.g. location, size, price, etc). And another channel for events with different fields (e.g. date, type, location).
Mostly anything can be slotted into a channel. But member details are best held within the native member functionality (although there is a commercial add-on that holds member data in a channel).
You reference the previous developers approach - this could be because they used a third-party add-on that required the data to be held separately to channels, or a lack of understanding on best approach. Or just because the developer decided to approach it that way! I suspect the last developer then associated a member (venue) to an entry (event) to link the event to the venue. Basic EE functionality allows for related entries which allows you to associate 1 entry with another (e.g. Event -> Venue), or using the excellent Playa add-on, so this approach is really not necessary.
Personally I would always store the data in channels, and people/members in the native membership functionality (e.g. admin, visitors to the site, customers, etc). I'd only build an add-on (utilising it's own tables/data) to store additional information if it was way outside what EE could store.
To answer your practical question (it's stretching the scope of what Stack Overflow questions are supposed be honestly): you should use a channel for Venues and channel for Events, and the Venue field in the Event entry is a "Related Entries" fieldtype linked to the Venues channel. That's the "standard" EE way, and the most similar to a traditional database schema.