Best push service option for React Native Android/IOS? - react-native

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.

Related

Where can I find the SONOS Cloud Queue server sample the docs are talking about?

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

Firebase Cloud Messaging Reliability

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.

VoIP App development in xamarin with Xmpp Server

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...

Open standard for native RTC with no plugins

Recently I have worked using WebRTC and I'm wondering if it would make more sense to implement a Real Time Communication open standard at a native level.
Let's say that instead of a web browser API we have a native API that any native app, including the browser can leverage.
Part of the promise of WebRTC is to have RTC on the browser without plugins but why stop there, why not have RTC on any device with media capabilities without plugins. There are many devices with media capabilities that will not run a web browser, e.g., wearables. It seems to me that the browser itself has become the plugin and I think we need to get rid of it as far as RTC is concerned.
It sounds like OpenWebRTC is going in a similar direction but so far they are only working inside the browser.
Are there open standards for native RTC? So far it looks like RTCWeb is only concerned about the browser.
Are there any projects/initiatives for native implementations of an open standard for RTC?
webrtc definition. webrtc is stuck into two parts, complementary but separated. the W3C consortium is standardizing a JS API for browsers named webRTC. The IETF is standardizing the underlying protocols and what happen on the wire for interoperability, it is named rtcweb.
the IETF's rtcweb group defines everything you need to interoperate with a browser, without being a browser yourself, i.e. for gateways, devices, .... It has been made explicit at the latest meeting in hawaii last november, and there is for example a corresponding draft.
On the client side, the implementation of webRTC JS API is done on top of c/C++ implementations. Those "native" (as in non-browser, C/C++) APIs can be use directly for servers, embeddable devices, gateway, ect, or can also be wrapped in different languages (obj-c, java) to provide "native" (as in mobile native) APIs.
Note that BOTH openWebrtc.io and webrtc.org have a full implementation of webRTC in C/C++ that you can use. openWebrtc provides iOS wrappers, and webkit wrappers (for safari), but do not provide data channel support, ORTC API support, nor compile under windows. webrtc.org supports all desktop OSes, and provide wrappers for both iOS and Android. The build tools are specific to google's chrome though, unlike openWebRTC which uses standard auto tools, github, ...
HTH
Currently there is no effort in this direction. The guys in the webrtc standardization committee have their hands full standardizing just the javascript API. As you know the current spec is not final and is currently still worked on. And now ORTC will generate even more work.
There are many reasons why no one is currently trying to standardize any form of native RTC. Here are some that come to my mind:
What exactly is native? Javascript is native for the browsers. The chrome version of webrtc is in C++ but the OpnWebRTC one is in C. Android developers use mostedly Java, iOS developers use ObjectiveC. Should there be standards for all these languages? That's going to take forever.
As I said standardization committee already have their hands full.
There is still quite a lot of experimentation that goes on with WebRTC. Standardization may prevent this.
The API of the native libraries tend to be very similar to the JS API.

iPhone App Submission - Bluetooth BLE Enable

Can anyone tell me how apple handle submissions for bluetooth BLE enabled app. Actually, i have created a bluetooth iphone app which connects to third party device. And, I am not sure how apple is testing apps which connects to third party devices.
Object Lab has recently launched their first iOS app using iBeacon. It took them 3 attempts to get it approved. I would recommend you to create a video which demonstrates how your app works and send it to them.
Generally they ask for hardware as well but mostly it's not feasible for us to provide them with one. Object Lab had to send them instructions to setup hardware at their end and to test the app. THEY WILL NOT APPROVE UNLESS THEY KNOW ITS WORKING. So I would recommend to send a video and step by step instruction of how to setup hardware at their end to test it out.
My experience has been that a video demonstrating the use of the app while connected to your third party device is enough. Sending the device to them is not necessary (at least for all cases). I know there is another thread on stackoverflow.com concerning this very thing, but it's been months since I had found it and I can't find it now. Anyways, it has worked for me as well as acquaintances of mine who have an app on the store.