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.
Related
I'm trying to get started with SONOS programmed radio feature, but I can't seem to find their Cloud Queue server sample referenced in the docs. Namely, the docs (this link) says the following:
A cloud queue to serve the list of tracks to Sonos players. See our cloud queue sample server for a sample implementation and Play audio for details about cloud queues.
with cloud queue sample server receiving 403 File Not Found
I noticed the same thing happens in the case of another sample code of theirs, also referenced in the docs (this link) here:
For example, we handle this on our Android cloud queue sample app by moving music playback to the local device so that it continues playing on the local device and stops playing on Sonos.
with Android cloud queue sample app receiving same HTTP error.
How can I access this needed samples?
Thank you in advance
Just received this email from developer-feedback#sonos.com
Hello,
You should find the links to these samples restored. Let us know if
you encounter further issues. Disclaimer: we are not actively
maintaining these samples and they are provided as-is.
Best, Sonos Sound Platform Team
I verified the links and they're working
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.
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.
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.
I want to develop a VoIP app with Xamarin and Xmpp server.
So far the only things that I have found is the openfire and "jitsi meet" for the server side and matrix for the client side. But the matrix has nothing to do with voice streaming and is just for text messaging and "jitsi meet" doesn’t have any sdk for .net client side.
I also have found the red5pro but this has client sdks just for native android and ios development platform and has nothing for Mono.
So what Should I look for?!
First, let's clarify some basics:
openfire is a XMPP server. Basically, this is all you need on the server side for basic VoIP support.
Alternatives include ejabberd and Prosody.
jitsi meet essentialy already is a VoIP app, so if you want to develop your own, you don't really need that.
"Jitsi Videobridge" on the other hand can be used to provide a relay server for video conferences. For your first steps with a simple VoIP app, you wont need that either, but if you want your users to be able to create video conferences with many participants, then this helps.
(Explanation: Normally, when you create a P2P-Video conference, you
have two options: First, all users send their video data to all
participants (everybody needs lots of bandwidth), or you pick one
participant ("host") that receives the video streams of every
participant end sends them to every other participant. In the second
case, a normal participant only has to upload his stream once and
download n streams, whereas the host does most of the work - so only
that one user needs high bandwidth.
Jitsi Videobridge can run on a server and act as this conference host (usually a server has a much better bandwidth than a home user), so that none of the participants has to act as a host.
In simple VoIP applications (without video), this may not be neccessary, as audio streams are usually much smaller than video streams.)
Now, as I said above, in order to write a VoIP app, you basically only need a XMPP server (openfire, prosody and ejabberd should all be sufficient for this use case), a client library that supports Jingle and client libraries for the RTP media streams (transfer and display).
Jingle is the name of a XMPP protocol extension that enables the negotiation of P2P data streams as they are needed for a VoIP call.
The relevant protocol specifications:
XEP 0166: Jingle
XEP-0167: Jingle RTP Sessions
So what you need to find is a XMPP library with support for the jingle protocol. The C# Matrix XMPP SDK (not to be confused with the "Matrix protocol", which is a different protocol and has nothing to do with XMPP except for having a common goal) is one example of such a library. According to their web site, there is support for Jingle, but I couldn't find any documentation about it.
However, as I mentioned above, Jingle is only about how to negotiate data streams, not the data streams and VoIP itself.
So what that library probably helps you with is parsing of the Jingle XMPP messages that are needed to set up a RTP data stream.
For displaying and transfering the RTP stream, however, you need additional libraries. For that, have a look at the following SO questions and answers:
Open Source .net C# library for Real Time transport Protocol
Streaming Avi files from C# using RTP
I hope I could give you some useful hints...