I want to test my application which share messages between two users using google channel api, but I manage to see messages going only from one side to the other.
is it because I'm opening 2 channels on the same machine? I am running the application on different browsers (Chrome and IE) and each one logged in with a different user name? shouldn't that be enough?
Any suggestion on how to test my application on a single PC, or must I connect another PC for such application?
Thanks
Muky.
You surely can test Google Channel API on a single machine. (I've done it, it works). Note that, when I run it on my local machine, I see the browser makes continuous requests (polling) although, when I upload it to Google App Engine, I only see push notifications. (You can check out the requests using Firebug in Firefox - in the NET tab). As far as I understand, Channel API is simulated in local mode using polling whereas, when uploaded to Google App Engine, they make use of Comet (not polling, rather long-lived requests).
I don't think your case was a browser issue. Each logged in user should open one channel. Then when you want to send a message to every users, you should send a message to each id that's logged in.
Related
I am making a Flutter application using Agora.
The app has the ability to make a video call through Agora. To connect to Video Call, rtcToken, appId and ChannelName are used from the console of Agora from the server (Generate comes from the server.). For now, 2 users can make a video call with each other through these 3 fields.
Question: is it possible to know the users who joined and left videoCall without sending a request to our server from mobile?
If this is not possible, then how can I tell the server from the mobile that users have joined or left?
Of course, it can be done via Rest api or socket. but the request to the Rest API may not go through (For example, the phone may be turned off). I wonder if the socket will hurt the server. It would be nice to have other solutions.
Thanks a lot for the answer
How did I solve the problem?
Agora itself could not solve the problem. Had to use web-socket. To know if the user is in the channel:
client.sessionController.value.isInChannel
This is what I used in web-socket.
check this agora documentation.
it shows channel methods for joining and leaving channel by the user.
https://api-ref.agora.io/en/video-sdk/flutter/6.x/API/rtc_api_overview_ng.html
I am creating an app for google assistant which will collect data while a user plays a game and then send that data to a project database. The API I am using to sent the data (synapse) requires it to be in file format, however, I can't find a way to create a file for the data due to the nature of google assistant apps. Am I overlooking a way to do this/is there a way to get around this and send the data somewhere else to make it into file format? The data is stored in a JSON object.
The conversation that your users have with your Action will be relayed from their Assistant device (such as Google Home) to Google's servers, which do a little processing, and then to your server. Your server is then responsible for sending back a reply to Google's servers, which sends it on to the Assistant device. This is very similar to how a web browser and server work, and for good reason - your server accepts commands via a "webhook", which is just a fancy way of saying that Google's servers contact your server via HTTPS, and you're sending back a reply via HTTPS.
Your webhook can do anything - as long as it does it fast enough. You can store what command the person has issued and either aggregate a number of them into a file format to send, or send each one.
Your Action does not, itself, run on the user's device any more than a web page with a form "runs" on the user's device. It displays there, just like your Action is read out loud... but almost all interaction is sent back to you with minimal processing on the device itself.
My company was using a third party tool to download print jobs from Google. This has developed problems so we've written our own. We can register a printer, get notifications via XMPP and download jobs. All good. We'd like to download jobs from the printers already registered via the the third party tool.
We have successfully got the permission of the google account that owns the printer to manage its printers and subsequently downloaded jobs from the printer. This was achieved using a solution that issued /fetch api calls every minute. Of course, Google wants the XMPP method used so we tried to do that. After getting over an authentication issue by adding googletalk to the scope in the oAuth request we fail to get any notifications.
In summary, with our own printer we can fetch, download and get XMPP notifications but with the printer registered with the third party tool (where we don't know the client id and secret but do know the google account) we can fetch and download but not get XMPP notifications. Is there any way round this?
The XMPP messages go to the robot account that owns the printer, so I don't think you should expect to receive XMPP messages without that robot account (and corresponding XMPP JID).
Rather than work around the intentions of the API, I suggest you work with the third party. Maybe they can provide hooks into their notification queue?
I am trying to figure out how to auto-reconnect a ejabberd socket connection. Like whatsapp, Facebookmessenger etc
For example, when the app is closed, and i receive a push notification to wake the app up and that calls to connect the connection, or if i put the app to the background for an hour, and the connection has been idle too long and get disconnected,then i put the app back to the foreground.
I can only think of 2 ways to automatically connect to the ejabberd server.
1.) To have the JID and Password stored(but this is not good for safety reason)
2.) To have the ejabberd idle connection set to never disconnect a connection(But this uses quite a lot of resources)
Is there any other possibility to automatically re-connect a user to the server?
You cannot stay connected all the time on mobile. This is the case today on iOS and is going to be the same on Android with Android Marshmallow.
So, you need to authenticate and store some form of credentials. It does not have to be a password. If you have a custom auth module in ejabberd for example, it can be a token.
Please, note that you can also store sensitive data encrypted on mobile. Both Apple and Google provide a keychain API that is design to protect the credential. It is not accessible in cleartext from a backup for example.
We are developing an iPhone application that allow users to send messages to others via Apple Push Notification Service when the target user have installed our application or SMS when haven't.
We want to get notified immediately when our app is uninstalled so that we can decide how to send the message to the target user.
We find the APNS feedback server have a long time delay that doesn't agree with our requirement. So we use another way: when our server recorded the target user have installed our application, we send him message via APNS, if he haven't read the message in 30 minutes, we believe that he has uninstalled the application, so we send the message via SMS.
Is there any way better?
As Oleg said, there is no way to accurately detect if your app was uninstalled.
The APNS feedback service returns a timestamp and a push token for messages it was not able to deliver. Sometimes, this indicates an uninstallation but it can also simply indicate a user that was simply offline at that moment. The Feedback service does have some lag so can not be used for time-sensitive intel gathering.
Based on your requirements, I'd say you're doing it right.
One suggestion that may or may not work for you would be to include a link (via url handler) to your app when you resort to sending an SMS. If it makes sense for the user to return to your app, clicking on that link should launch the app and you'll have a trace on your server if you make a simple call. If, however, after sending the SMS the user is not detected as coming back into the app, chances are highly likely that the app was indeed uninstalled or that the user is offline for an unusually long amount of time which may require some other type of action on your part.