I am developing a Xamarin Forms app for Android where in i need to receive events from server using Azure SignalR function. This is working fine in few phones, however on few I get strange errors.
Redmi 4 running Android 7.1 I see that the connection is successful, it it does not receive any messages.
Redmi 1s running Android 4.4 KitKat, it gets connected and I can receive messages, however soon it gets disconnected stating that remote party closed the websocket connection without completing the close handshake or 30000 ms elapsed without receiving a message from server
BTW I have a background Service where I am creating this SignalR Hub and connecting so that even if my app goes to sleep, I can still receive the server events.
it works fine on some of the other newer phones in my home. so my question is what is the best way to debug these kind of issues. I don't see any logs in the Device Log that can help me understand what is going on.
Related
I had a local bot which I wanted to test in WebChat client instead of Emulator. After researching for a while and failing to connect normally, I stumbled upon a package called offline-directline which helped me connect my local bot successfully. My directline runs on 4000, webchat runs on 3000 and local bot runs on 3979.
I took a peak in the network tab later and I see my client keeps making GET requests to /directline/conversations/ endpoint. At first I thought it happens when I am sending messages in my WebChat client but it keeps sending them repeatedly. Around 50 GET requests in a minute.
I am not sure if this is a normal behavior. Would really appreciate an input. Thank you.
We are not able to detect subscribers'/clients' disconnected signal or poor network connection with Android/iOS SDK, however, we are able to detect with OpenTok web (JS).
The below link suggested for the web which is working fine our end too, but we need the same for OpenTok Android and iOS SDK.
Determining if a remote subscriber is temporarily disconnected.
we need sample code to detect poor connection or network disconnected at subscribers end for both Android and iOS. if anybody faced a similar problem and has a workaround then please suggest.
our aim to show messages on the mobile phone if subscribers have poor connection issues or trying to reconnect.
There are analogous re-connection callbacks for Android and iOS as well. Reconnection callbacks get triggered when a client tries to automatically reconnect after losing its connection to an OpenTok session. Otherwise, if a client cannot reconnect, the SessionListener's "disconnected" method gets triggered.
To verify if session reconnect APIs are working fine at your end, we recommend you to implement the necessary callbacks and manually check if the registered callbacks gets triggered or not by disconnecting network and then reconnecting it again.
Please checkout the below link for implementing callback APIs:
Android:
https://tokbox.com/developer/sdks/android/reference/com/opentok/android/Session.ReconnectionListener.html
iOS: https://tokbox.com/developer/sdks/ios/reference/Protocols/OTSessionDelegate.html#//api/name/sessionDidBeginReconnecting
Hope it helps!
We have embedded a Bot on a web page through the web chat channel, if the Bot is idle for 10 minutes or so and then a question is asked, the Bot does not respond to it, however when the same question is asked again immediately it responds as expected.
On investigating the network capture, we observed the response received when the question was asked for the first time was 500: Internal Server Error with message as "failed to send message"
Are you running the bot in Azure? If so, make sure you have "AlwaysOn" enabled; otherwise the web app will be unloaded if it's idle for a period of time. Check this for a similar problem.
Always On. By default, web apps are unloaded if they are idle for some period of time. This lets the system conserve resources. In Basic or Standard mode, you can enable Always On to keep the app loaded all the time. If your app runs continuous web jobs, you should enable Always On, or the web jobs may not run reliably.
You can read more about the web sites configuration here.
After the latest update of Whatsapp on Widows Phone Store, I have noticed that now, once they show the toast of message on my device, then they mark the message as delivered (notify the sender that the message has reached my device).
After I let the toast notification go away, I switched off all my data connection and opened Whatsapp and found that that particular message in my app. This is happening consistently on both wp7 and wp8 device. This was happening even when I had disabled background agent! Beside background agent of an app does not run all the time.
So my questions is, on windows phone platform, where the app is not allowed to run in background all the time, how is Whatsapp application getting those messages? Is it using any particular api/hack to get(in app) those messages when it's not on foreground.
The question you have asked has two parts: one for wp7 and the other for wp8. I will anser each one by one.
Windows phone 7
Based on my research, I have found that whatsapp is still using audio streaming api on wp7 devices to stream messages in the background i.e. when the app is not running. Whatsapp was criticized of using this API as constantly using this causes battery drainage as well as hampers the music experience of the user.
Windows Phone 8
Once whatsapp moved to wp8 they stopped using the Audio API and moved to VOIP API. Note that whatsapp doesn't use VOIP for any purpose but their manifest shows usage of VOIP api, and after reading many articles I have come to the conclusion that they are using this API to activate background agent and pool messages in the background.
While sending raw push of type 4, the background agent for VOIP is activated in which you can practically do anything from reading the payload to establishing a new socket connection subjected to restriction on usage of certain APIs
I have also found out that even if a user disables bg agents for an app some essential bg agent still continue to run for eg bg agents in audio stream API and VOIP API.
I hope this answers your question.
Go through this link
Push notification for Windows Phone
What will help you to understand is
The server maintains a maximum of 30 notifications (regardless of type) for each URI. Once the limit of 30 is reached, all new messages sent to the server are discarded until the device reconnects and the queue can be flushed.
In windows phone there is something called raw notifications, these are different from push notifications, push notifications display a notification, but raw notifications triggers a background task that can run under certain api restrictions for about 15 seconds. (I think, I'm not sure about the time duration), I think what whatsapp does is that it downloads the message and saves it in a local database which is maintained in the device. When whatsapp is opened it will read the local database and also sync with the server.
Please correct me if I am wrong.
I've been using SignalR successfully for some time using serverSentEvents transport. I've just installed my application on Windows Server 2012 RC and now when I connect SignalR is using websockets (as you'd expect).
It appears to work OK except there is a continuous stream of websocket traffic between server and browser - about once a second it's sending about 90 bytes.
From the debugger window in Chrome, it looks like it's sending a connection upgrade request each time.
I am successfully receiving messages sent by the server, but I seem to be worse off than when using long polling.
The browser is Chrome version 19.0.1084.52.
Any idea why this is happening?
This was down to my own stupidity - but I thought I'd answer in case anyone else has the same problem.
I had built the solution SignalR.Hosting.AspNet instead of SignalR.Hosting.AspNet45
So the method AcceptWebSocketRequest was throwing a NotSupportedException; because the client websocket upgrade failed, it just tried again about a second later.
I guess the client could show an error or something in this case to aid debugging.