We are building a messaging app and we are facing issues with messages delivery.
We are currently using socket.io to send messages on a running app but it's been proven highly unreliable. (Problem with slow network, late timeout, problem when app is in Doze mode,...)
We are thinking about switching to FCM but we have questions regarding reliability and speed. We don't want to change everything to see afterwards that it's not as reliable as wanted.
Have you already used FCM on a production app for every message ? Even when the app is running ?
It's hard to provide a concrete answer for this. Reliability wise, I would say FCM is pretty good.
Expected behavior is, if you successfully sent your payload to the FCM servers, it will send the message(s) as soon as feasible. When in doze, a low priority message is stored by FCM until the device is out of doze mode.
The documentation pretty much describes how the messages are handled in the FCM servers and all other related behaviors.
Related
I built a VoIP calling app which maintains a persistent connection with the server to listen to any incoming calls. I implemented a background service to do this.
But since Oreo, this running code is now broken because of the introduction of Background Execution Limits
After looking into forums, I found that some people are suggesting
Convert Service to JobService and let android schedule it
Doing so, my app won't be able to receive calls when it is stopped
Run your operations in foreground services
It is annoying for some users to see a constant notification in the notification bar. So these above-mentioned options aren't working for me to fix my code for Oreo.
How does WhatsApp get the incoming (VOIP) call in Android (Oreo onwards) working around the Background Execution Limits?
(Sticky) foreground services are not affected by the restrictions. So you could use one those as replacement for background services on Oreo.
But foreground services have two disadvantages: They are less likely killed by the system in order to reclaim resources compared to background services, and hence affects the Android system's self-healing capability. And they require you to display a permanent notification. But Users are able to suppress the notification, somewhat mitigating this disadvantage.
I am assuming that you are using SIP to establish the connection and initiate calls. Without a service constantly re-sending REGISTERs, the app doesn't receive INVITEs when the server sends them.
A workaround for this problem is what is called the "push notification strategy". It works as follows, when the server sends a INVITE, it also sends an FCM notification to your app, This wakes up your app which then sends a REGISTER to your server, which in return forks the call to your app. Here is a video that better explains this strategy
There are two options:
use platform push services (APNS or FCM)
maintain persistent socket connection and exclude application from battery optimisations.
I have been following many projects which demonstrate the push service.
But there are many problems specially when the app is closed/kill (IOS too).
My first preference would be using FCM with react-native and followed This project on git. But it too have issues with notifications.
Is there any full proof source showing the push with android/IOS even when closed/kill?Anything is deeply appreciated :)
I have tried Firebase Notification:
https://firebase.google.com/docs/notifications/
- Easy Implementation
- Works really well
- No inbox messaging (as far as i saw - correct me if I am wrong)
At the moment I am using Urban Airship. Wich is not free to use but has a larger SDK to use.
https://www.urbanairship.com/products/mobile-app-engagement/pricing
- Also has Inbox messaging
- Deep Linking
Both are working fine if the app is closed.
I wrote a pretty long chapter in my book on Android push messaging. Here is the flowchart I present on choosing a technology:
You should be able to get a good implemention using GCM/FCM with respect to power off and app close, but the bottom line is, GCM/FCM does not provide quaranteed delivery Quality of Serivce. They also will not quarantee order of message delivery. If you use MQTT, you can get this by setting QOS mode = 2.
MQTT is not hard to implement for Android. You can use the open source Mosquitto broker on the server side. It only take me 15 minutes to set this up on AWS or any unix server.
In your Android app, you then implement your own long lived service, and the Paho Android library is very stable and supports the 3 QoS levels, including QoS=2 which is the guananteed delievery mode.
Anyway, something else to think about. I use MQTT a lot. FCM is great, and it even supports topic messaging now, which is how the MQTT pub/sub model works. You just will never get guanarteed delivery QoS level with FCM.
Is WebRTC going to be free for web developers to set up video calls on web pages?
why does Twilio having pricing 25c per mins for video calls,
is it going to be too expensive for the small guy to mange video calls on web hosting servers?
any advice from anyone deep into WebRTC already?
Some of the comments above are not well informed.
Someone wrote, since the bandwidth needed in case of media relay is higher as well. This is not entirely true, transmission happens between Peers(Browsers), servers are used just for signalling(relaying IP addresses of connecting peers and some more info), you can ROUTE your transmission from central server(for fail overs), but can surely do without it for free.
WebRTC is Free and you can setup the whole thing on your own without having to shell out even a penny. It is a bit hard and mitigating fail-overs is really difficult, but you can certainly do it for free.
Tokbox or Twilio charge money because these tools abstract some very rigid complexities of setting up, running and managing fail-overs in a WebRTC application.
In TokBox's Case:
You don't need to setup STUN, TURN servers, you don't have to worry
about integration with android or IOS clients, they provide a plugin
for IE too, so out of box you get everything and you just have to
concentrate on your application logic rather than WebRTC nuances.
This is a big plus.
Both RELAY and ROUTED schemes came in the box hence you can write
fail-over scenarios if RELAY communication fails. Although there are
some good JavaScript based frameworks that do this in a much cleaner
manner.
It adds slew of other goodies which help in building android and IOS
clients without any pain.
STUN or TURN Servers are used only for Signalling Purpose, and this signalling happens before any actual transmission. This signal is very small and carries the IP address of both the browsers(machines running browsers). For Transmission the communication is done between Browsers(Peer to Peer) themselves, so no server is involved.
Your relay is not happening from a central server so you don't have
to pay for the outgoing bandwidth cost.
To Setup Turn Server,
Use this server, build it and put it into a Rackspace/Amazon Web
Services instance and you are Good with your TURN
Server. That is It, setup your application and have fun with WebRTC
for FREE.
rfc5766-turn-server
If you wish to Use some more free framework to ease yourself more, check out: EasyRTC and PeerJS
Enjoy Developing with WebRTC....
Twilio developer evangelist here.
Your link at the end of your question points to our WebRTC page, which currently talks about the product Twilio Client. Twilio Client briefly is a way that, using WebRTC within browsers and mobile applications you can make phone calls to real phone numbers. This product does not allow you to conduct video calls.
Twilio Client has a cost because of the ability to call out from a browser to a telephone number. The cost is not in the WebRTC portion, but delivering those minutes to the other leg of the call.
Notably, it's not 25 cents ($0.25) a minute, instead it is just a quarter of a cent ($0.0025) a minute.
With regards to video calls with WebRTC, you can now access the public beta of Twilio Video, a platform to make setting up WebRTC calls much easier.
Twilio Video costs for the signalling infrastructure and you can see the prices here. If a WebRTC connection requires a TURN server to relay the media, that also costs per gigabyte of transfer. Usage of the STUN server is free, the costs for the TURN relay are available here.
Please get in touch with me at philnash#twilio.com if you have any other questions about WebRTC.
WebRTC is a technology placed in a browser. It requires backend infrastructure to support it - specifically, STUN and TURN servers as well as signaling servers.
This boils down to the fact that you pay for WebRTC - same as you pay for hosting your website on a server. The price is higher, since the bandwidth needed in case of media relay is higher as well.
To understand more about WebRTC and how it works (as well as why there's a price tag associated with services such as Twilio for it), you can check this free report: https://bloggeek.me/webrtc-business-people/
WebRTC is already free for developers to use. When we added WebRTC to our product, we used this example code, which made it very simple to build a WebRTC client:
https://shanetully.com/2014/09/a-dead-simple-webrtc-example/
Google and Mozilla provide free STUN servers, and it is easy to set up a TURN server. Most clients will be able to connect via STUN, so you won't end up using too much bandwidth on your TURN server.
To set up your own TURN server, coturn seems to be the easiest to set up:
https://github.com/coturn/coturn
Make sure you read the "WEBRTC USAGE" section in the README.turnserver file.
"STUN or TURN Servers are used only for Signalling Purpose, and this signalling happens before any actual transmission. This signal is very small and carries the IP address of both the browsers(machines running browsers). For Transmission the communication is done between Browsers(Peer to Peer) themselves, so no server is involved."
if that is the case, then you should be able to do this on a standard web server using Java/php. PHP will get the IP address of the guys connected to it. Then its just a matter of storing them in MySQL, then making a javascript that would run when the user go to that page in the site.
I've been looking for a solution around using a VPS because running a dedicated server for signaling is like golfing with a Ferrari instead of a golf cart. I still don't think node is efficient. Its single threaded. so node's fararri can only go 5mph.
Since they went to the web site, the php service already can get their ip address what else does it need? All of the above solutions so far require you to pay for a dedicated app to run on a server connected to the web separately for what 5k of data? What a waste of electrons.
But I'm going to start a new thread that is going to be based on getting webrtc without the buy a "VPS" because we want a VPS-less solution.
I just created an Android application using GCM to receive Topic messages. Everything works fine but I have some questions on the mechanism.
How secure is the GCM Topics workflow? Since anyone can subscribe to my topics using the sender ID (which is embedded in the Android APK), seems to me that it is possible to launch a DoS attack by over-subscribing my topics (as there is a 1M limit for each app).
Also, is there any tool to monitor the number of subscriber? Couldn't find it on Developers Console. I would like to monitor the status before it reaches the 1M limit.
I'm developing an app which relies on C2DM to be notified of some new data to be fetched from a REST service. I have successfully implemented the C2DM android feature, but the behavior over Wifi is different from the connection over 3G. The messages are received instantly over 3G, but I have to manually turn Wifi off and on to have a "grace period" of ~1 min in which I receive them instantly.
My question is: Is there any way I can programmatically restart the connection, or trigger the notification fetch?
EDIT:
I've implemented an AsyncTask that periodically "reassociates" the connection to the access point (using WifiManager.reassociate()) every minute and a half. Not so sure about the correctness of this solution, though.
I've seen similar issues. It seems that under some circumstances C2DM messages are not delivered over wifi connections, when they are over 3G. On a related note I've also seen Android devices "drop" the push connection, so messages are not delivered (in my case the solution can be to put the device in airplane mode and then turn the network back on).
This reinforces the fact that all applications that use C2DM should be built so that even if push messaging fails, the app still works (even if messages/updates are slower because there's occasional polling to the server)
I wouldn't personally want to mess with the wifi connection as that's something that may cause problems for the user.