I have a chat app and I am stuck while initiating the chat. According to pubnub, anytime I message to a new channel "A", that channel is created. My problem is that I want to subscribe to that channel and show the message but I cannot subscribe before the channel is created.
"Creating" PubNub Channels
Channels are not really "created", channels are just string tokens for routing messages. So there is no notion of creating a channel in PubNub (not officially, anyway).
The phrase "create a channel" is more of a concept than a real thing in PubNub. Within your app, creating a channel (a chat room) is a real thing. So you can subscribe to a channel that hasn't yet been "created".
So when your app "creates" a channel (starts a new chat room), your participating clients can subscribe to the channel and messages can be published later.
Or, clients can subscribe after messages are published and use fetchMessages to get any messages that were sent before the client subscribed.
Related
I'm working on this chat type scenario and the need is to track presence -
Note: every client in this scenario will subscribe with option withPresence set to true.
Pubnub cofig-
Max announce is set to 1, so i rely on interval event type.
phoneA will ask server for a channel name, Server will generate a unique channel name (lets say ch-chat) and return to PhoneA.
Now both phoneA and server will add the channel to their own channel groups (cg-phoneA and cg-server)and subscribe to their own channel groups.
PhoneA shares the channel name with phoneB and phoneC and they both add the channel to their own channel groups, cg-phoneB and cg-phoneC. Bkth B and C are also subscribed to their own channel group.
Now,
When phoneA removes channel (ch-chat) from its own channel group (cg-phoneA), server does not gets phobeA in leave uuids list of interval event. But after ~5mins server gets timeout event for phoneA.
What i want -
phoneA should present in the leave list of the interval event since phoneA removed the channel from its own channel group, theres no way it should be subscribed anymore to it.
Presence Modes: Announce vs Interval
One issue is that your Announce Max setting of 1 will mute all presence events except for state-change. In other words, you are in Interval mode all the time for every channel. Read more about Presence Event Modes here.
When channels are added to a channel group, you should receive the join event (if in Announce mode and not Interval), if you are subscribed to the channel group withPresence: true. Be sure you want to receive presence events for all channels in that channel group though. You can create a second channel group for channels you do not need to receive presence events.
Managing Channel Groups
As for managing Channels in your Channel Groups, be sure that only your Server is the one adding/removing channels for all channel groups. This has to do with security when you enable Access Manager (and everyone should be enabled/implementing Access Manager to protect your keys and your users).
Presence Webhooks
As for Presence Webhooks, this is the best way for your Server to monitor presence events. It is not recommended that you subscribe from your server. It will be difficult/complex to scale to multiple server instances. This is why the Presence Webhooks exist. And your clients and POST directly to the Server for any requests it needs, like your "generate new channel" request. And your server and reply to those posts and then publish all further updates to the channel the client is subscribed to.
Channel Naming Conventions
It is great that you are using "generated channel names" (like a UUID pattern) but prefix your channels to identity them to provide a means to group them with pattern match through regex. I would recommend using a "dot" so that you can also potentially take advantage of PubNub wildcarding features:
PubNub Functions channel binding
Presence ACLs (custom presence channel behavior configuration)
Access Manager wildcard granting
Wildcard Subscribe
For example:
chat.4849-ut83-83jd...
notify.tuy7-87er-27fn...
NOTE: Channel Groups do not allow "dots" in the name and do not have any wildcarding features.
Android - Huawei with HMS push plugin, HmsPushEvent.onRemoteMessageReceived this event was not triggered when app is in killed state. This event only getting called while app is in foreground and background state. Can you please tell which event will be called when app is in killed state.
Push Kit supports two types of messages: notification messages and data messages. After a device receives a data message, the device transfers it to your app instead of directly displaying the message. Your app then parses the message and triggers the corresponding action. Push Kit only functions as a channel, and the delivery of data messages depends on the resident status of your app. However, notification messages can still be delivered even if your app is not launched.
For the sake of saving power and not disturbing users, your app will not be launched by Push Kit after being stopped, and no data messages can be delivered to your app. In this case, you can determine whether to use notification messages based on your services.
To allow users to open a specified page of your app after they tap a notification message, proceed as follows:
Generate Intent parameters
Set intent in the message body on your app server
Register the Activity class to be started in the AndroidManifest.xml file of the app
Receive data in the customized Activity class
From: https://stackoverflow.com/a/64100678/14006527
Alternatively, you can set high-priority data messages to forcibly launch your stopped app to receive and process the messages. To do so, you need to apply for special permission by referring to the related description in FAQs.
we are building chat application similar to messenger. There is required behavior:
User log in
User should see last N messages, and he should be able to load older messages
New messages should be appended as well
My solution:
I would like to use websockets for this purpose with combination of REST. My idea was that client application decide by message id which messages need. So REST will be used for initial fetching of messages and fetching older messages.
New messages will received by websockets
Possible issue which I should handle:
Application starts subscribing websocket channel for new messages and send request for old messages without initial message id
There is chance that after calling GET request new message come, and will be stored in DB
Client application started subscribing websocket channel so message will received by websockets.
GET request didn't know about this message and fetch last N messages where this new messages will occured and client application will have duplicate record and have to filtered this messages
Can you give me advice if there is some elegant way how to handle this case? Thank you.
I would resolve your task having in mind the following:
The client application should know only about the topic to which to listen. And not the ID of the message starting from which to listen.
It is up to the server to decide what to return (even time should always be tracked server-side).
The WebSocket is used as a transport for STOMP (simply to not reinvent the wheel). The WebSocket connection could be opened once the client application is loaded and not when it is entering the "listen for messages" state. But topic subscription should be performed when necessary.
You can always send GET request and initiate a STOMP subscription simultaneously (almost simultaneously, well with a delay of 1-2 nano-second). And those always should be processed in different promises. But I would align those in the following way: first, the STOMP subscription is initiated, And a specific message on subscription with the initial timestamp of the start of subscription is delivered; second, REST request to get previous 10-100 messages for the TOPIC prior to a specific timestamp (received from STOMP) is performed.
Getting the last 10 messages (which are prior to subscription moment) could be delivered as by REST as by STOMP approach: you can always react to a subscription event on your server-side, and deliver client-specific messages.
Regarding the problem of multiple identical messages from different "data channels", it is easily resolvable: your client (hope that is not jquery, but rather Angular or React or Vue or anything else) will be storing all the data in a single collection in a controller, and filtering and checking by message-id that only unique entries are stored is easy.
BUT if your system will produce hundreds of thousands of messages per second: I guess HTTP-based protocols are not your choice in this case.
Is there any google chat module to send alerts via sensu's google chat handler to more than one room (chat room)?
Ex: As like in Slack we have multi-slack-handler.rb handler is there to trigger alerts on multiple channels via subscriptions which we defined./
Is this same kind of thing Possible with google chat??
In my case, I have created two channels in Sensu (sensu-core open source edition) but I am getting alerts in only one channel after few minutes I am getting alerts on another channel as well but it sends alerts in only one channel at a time. How can we get alerts in all the channels on sensu with google hangout handler?
I think you should check this module: https://github.com/anandtripathi5/google-chat-handler. It is a simple handler which you can add to your logger and configure the level of chat as required. Adding it multiple times with different Gchat room webhooks will push logs to multiple Gchat rooms simultaneously.
When building a social application it's common to follow other users or topics as an indication of interest in updates by the user or topic. For example, following other users on Twitter, Friending other people on Facebook or liking a product or brand on Facebook.
Pusher has the concept of channels that you subscribe to. Channels are a human readable string that provide a logical identifier to information (e.g. "some-channel-name") and therefore seems to naturally suggest that in a social application any updates on a user or topic should be sent on a channel specific to that item (e.g. "userX-status-updates" or "myBrand-status-updates").
However, this raises concerns about how efficient it is to subscribe to multiple channels if a user is following a high number of other users or topic.
Therefore, what are the appropriate strategies for structuring channels in an social status update style application that uses Pusher?
The first thing to clarify is that you need a mapping of who you are following so for the purposes of this answer I'm going to assume that it's stored in a DB on the server. It also assumed that status updates are triggered as follows:
Client (userX posts status update) -> Your Server (sanitize & validate)
Your Server -> Pusher
Pusher -> Clients (users interested in updates from UserX)
There are two possible solutions to the channel information architecture problem:
Channel Per User Status: A user subscribes to a userX-status-updates channel for all the users that they follow and users trigger update events on their own status update channel.
Users I'm Following Channel: When a user posts a status update you look up who is following that user and publish the update on a users-you-follow-updates channel.
Strategy 1. is the most optimal solution as it keeps interactions with your own infrastructure an Pusher to a minimum.
Here's the detail on these two strategies:
1. Channel Per User Status
The assumption here is that subscribing to channels is costly but that not entirely correct. Channels are simply a way of routing events. However, if you are using authenticated channels (private & presence) you need to authenticate the subscription via your own server. If you use the Pusher WebSocket libraries "out of the box" each subscription will result in a request to your server. So, a user is following 1,000 users that's 1,000 requests to your server.
But, for the pusher-js library there is a multi-auth plugin that can batch the authentication requests into a single call.
There is also a BatchAuthorizer for the Pusher WebSocket Java library, but it's only a sample solution to this scenario.
2. Users I'm Following Channel
Note: although this is an option it's probably only appropriate for smaller numbers of users
In this scenario a user sends their status update to the server, the server performs a lookup of which users are interested in the update and triggers and update even on a channel for each interested user.
For example, give users UserA, UserB and UserC each of those users will subscribe to their own update channel; UserA-followers-updates, UserB-followers-updates, and UserC-followers-updates respectively. If each of these users follows UserZ then when UserZ makes as status update that update is published on each of those channels.
This may also sound inefficient, however it is possible to trigger the same event on 10 channels at a time. So in the above example it would only require one call to the Pusher HTTP API to send the status update to all interested users. More information on multi-channel event publishing here.