I am creating an app for android to support google cast for video with interaction using CastCompanionLibrary library.
On the video VideoCastManager use and for the part of the exchange of messages (data) DataManagerCast use.
I want to implement a control who can connect to a particular session. My idea is that the first sender to connect on chromecast be the "owner of the session" and other senders need to ask permission to him to connect. I created a namespace for communication between the receiver and the sender session owner for the connection process occurs.
If the sender is not authorized then it should disconnect.
I took a look at receiver reference searching for a method to the receiver disconnect a particular sende, but it still fails. Does anyone know if it is possible to implement this my idea?
First, why are you using DataCastManager? VideoCastManager can add a data channel and that is all you'd need to communicate so only use the VideoCastManager.
As far as memory serves, receiver cannot disconnect individual senders, so an alternative to your approach would be:
Each sender, after connecting to the receiver, will send a message to receiver to register itself.
Receiver looks at the number of connected devices, if that is the first one, it considers that the owner an sends back a message to the sender letting it know that it is the owner. If it is not the first one, it sends back a message to that sender, informing it that it needs to get authorization from the owner (so the new sender knows that it should wait for an authorization). At the same time, it sends a message to the owner asking for permission to allow the second one in.
The owner will send back a message to the receiver to allow or prohibit the new sender to connect. Receiver then sends a message to the new sender to let it know if its request was granted or not.
If permission was granted, then your code in your sender would allow the user to move forward in the app. If it is not granted, then the logic in your sender app can either stop the user from going forward, or can disconnect the sender, or can just limit the stuff that teh user can do.
Related
As we know we send and receive message in json form from send app to receiver app. what is the proper channel for sending and receiving message and what role ChromeCast play in whole picture?
Senders and receivers are establishing a socket connection and communicate via IPC. While it's true that this communication is in JSON format, you will likely neither generate that data yourself nor care about the 'how' or 'channels' of it - in fact, you are not even allowed to following the terms of service by Google.
Instead, you have the SDK handle that for you one both the sender and receiver site.
Communication is done in the form of defined Messages that implement a schema and contain objects - most notably for media playback that is MediaInformation.
Most of those objects that are passed between sender and receiver have a customData property that you can use to add self-defined payload in JSON format.
If you want to implement your own features you can implement custom messages.
I am using an Azure Function to send a Proactive message to the client. How do i "reset" a conversation when a Proactive message is sent.
Within the bot, a user might be prompted for something (ex. time of day). A proactive message may get sent to them before they respond. In this scenario, I would like to reset/cancel the previous dialog and start fresh.
I am already able to reset the dialog using CancelAllDialogsAsync which works fine for user-driven messages.
I am sending my proactive message using ConnectorClient, which bypasses the framework, and sends directly to the client, thus never hitting my middleware to reset the dialog.
How can I get the proactive message sent to the framework (i can send the response from the bot no problem)
I would highly recommend you solve this by having your function send your bot a backchannel event under the context of the ConversationReference via the ConnectorClient. This way the bot maintains ownership for all the details about state and what should happen when this event occurs rather than that responsibility leaking to the function. The bot then watches for this custom event and responds to it however it sees fit.
If you need any more details let me know and I'll update my answer.
I have a Slack command bot that posts ephemeral messages and lets the user decide whether they want to make the message visible to everyone else in the channel ('Send') or delete the message ('Cancel'). Since Slack API doesn't provide the original message when user interacts with an ephemeral message, I have to store original messages in Redis, retrieve them when user interacts with the posted message and delete the key from Redis afterwards. The one thing I'm worried about is clogging up Redis with keys that will never be deleted because user never interacts with the message (in other words, doesn't tap on any of the buttons, just leaves the message as is and walks away).
Does Slack API provide any way of knowing when ephemeral messages get deleted so I can clean up Redis? Or is there a better way to solve this problem in general?
No - Slack has no mechanism to inform your app when an ephemeral message vanished. In general they will live until the user refreshes the page on his browser (in the web version).
But I can offer an alternative solution to storing all messages on redis:
Since you created the initial ephemeral message you should be able to always recreate that same message later if you know the exact functional context (e.g. User ID).
All you need to do is to store an ID linking to its context in the buttons of your first message. If the user clicks on the buttons the Slack request will include those IDs, which allows you to identify its context, e.g. take the proper action or recreate the same message for sending to the whole channel.
You can use the name or value field of an action for storing IDs. (See also this answer.)
That ID can either represent the instance of an object (e.g. a customer), so you can fetch that object from your DB again or it can be the ID of your server session, which enables you to work with server session and keep all the context data in the server session. (see also this answer).
I'm using Quickblox in Ionic (Angular), with Parse for my database. Whenever I send friend requests, it only sends one, and the receiver only receives one, but the listener goes off some random number of times (3-10), Consequently, if I send a chat, it will send the same number as there are friend requests. However, if I hard-code in the user who sends and receives chats, it the chat receiver still does the same thing.
I'm using Parse to manage Quickblox accounts. So I'm fairly theres some issue with session management and connections to Quickblox.
I'm using a simple receiver based on the Google CastHelloText sample app. When the sender disconnects, I'd like to allow the receiver to continue display.
I thought this could be accomplished by modifying the receiver's onSenderDisconnect function to skip the window.close call but when I disconnect my sender by calling session.stop, the receiver is shutdown withou a call to onSenderDisconnect. I see a "Dispatching shutdown event" in the receiver log.
How can I get the receiver to continue without the sender connection?
If you want to allow receiver to continue, do not call stop in your sender; that call sends a message to the receiver that would result in stoping the application on receiver; here is what the documentation for that method says: "Stops the running receiver application associated with the session.". On chrome senders, you can simply close the tab if you want to let the receiver continue . Note that the onSenderDisconnect now has an argument that shows whether disconnect was explicit (intentional) or not, in case you want to handle explicit disconnects differently. Other platforms, e.g. Android SDK, also have similar stopApplication methods that should not be called if you do not want to stop the running application on the receiver. On Android and iOS, you have more APIs to provide a more fine-tuned "disconnect" experience.