I am developing a mobile app using react native. My backend application is developed using springboot. My app talks to backend using REST.
I want to send some notification to the user of the app from my backend (via one of the options mentioned below). This cannot be a Push Notification as user can disable push notification for my app.
On recieveing this notification the app will communicate with backend using rest api's to fetch more details and complete the transaction.
I want to know what would be a better strategy to send a notification for the user.
Websockets
Using Firestore event listener(since I am already using Firebase to send Push Notitification for users who have enabled it)
SSE(server sent events)
Periodic polling from the app to backend (I do not like this approach)
I know this is a bit broad topic. I just need some pointers as to which option is better in terms of fault tolerance, performance and scalability.
I want to know how this is generally implemented. I am new to app development.
In my opinion Firebase is the best option for mobile apps, websocket can be be closed by android and are not always controllable. They also consume a lot of energy which can drain phone battery.
I have the same requirements for a project where need to send notification regardless of using a third party application like Firebase. How I achieve this I will share with you may be it will help you.
Backend -> ASP.NET Core
Real time communication -> SignalR Core
Protocols -> Websocket, Server sent events, Long Pooling
RN Package -> react-native-push-notification
It was completely fine except for one drawback that it will only communicate and send push notification when app is running (background/foreground) I think it depend on your situation and your requirement if your app is continuously will in the main app this will work for you otherwise you need to use the third-party service like Firebase and it will also work when your app is not running just need to be connected with the internet.
I have spent hours trying to find out anything about consuming browser notifications, but I literally couldn't find anything at all. Is there a way, from a CLI application, to subscribe to a service that pushes web notifications? I have looked into the browser API and everything, but I can't figure out or find any resources on how to, or whether it is possible to consume these notifications.
My goal is to write a Telegram bot that will subscribe to one of those services that pushes notifications, read the notifications, evaluate them and potentially message me.
The reason I want to do this is because the website does support sending me a certain amount of information, but I only want to be notified of some of that.
I'm planning to add push notifications to my web app.
As far as I understand it, to push notifications to my users, I can either use a web push library and deliver the notifications directly, or use a push notification service such as OneSignal, Firebase Cloud Messaging, or Batch.com.
From what I understand, these services offer a one-stop solution to deliver notifications not only as Web Push, but also to iOS and Android apps.
If I'm focusing only on Web Push for now, is there any advantage I should be aware of, to use one of these services over a web push library directly?
Web Push is a standard which is still under development and subject to change. Also browser support is quite limited at the moment (see https://caniuse.com/#feat=push-api).
The advantage is: you have one API to rule all the supporting platforms (including desktop).
Disadvantage is: You have to be aware that not all platforms support the standard.
Using a notification SaaS solution to handle notifications enables you to handle all platforms. Sending out a notification from your backend will be a single call to your notification SaaS service, but you still have to be aware, when you want to have native notifications on Android, iOS and the browser, you will have to handle the integration of those platforms differently in your client apps (see example here using Google Cloud Message integration in an Android App: https://firebase.google.com/docs/cloud-messaging/android/client).
So your decision should be based on which platforms you have to support.
- If you get away with supporting Chrome, Firefox and Edge browsers on non-iOS-Devices (or handle iOS Notifications differently), you can use Web Push.
- Otherwise i would choose a Notification SaaS Solution.
The most important point for me personally when doing your own implementation is that you control everything. This means that your notifications don't fail when AWS loses a region or pricing changes and you can't afford it any more. Not any provider can ban you because of the content you distribute or the complaints from users. You can implement your own logic for showing the notifications on the front-end, like stacking them or having your own segmentation rules (paying users versus free tier, for instance). I'm not even speaking of the custom subscription UI. No weird copyright in your messages.
From what I understand, these services offer a one-stop solution to deliver notifications not only as Web Push, but also to iOS and Android apps.
When you've got the server logic to process the app events and send notifications in place, it shouldn't be really hard to extent it do work with mobile push notifications. The only thing that changes is the way you subscribe devices.
And the last, but not the least - it's fun to develop. This is more of a personal matter, I guess, but I like learning new thing :)
Hope that helps you to make a decision.
you can implement push notification to your website without using third-party libraries. You have required to get subscription token from the client and store this subscription token onto the server (Inside database). After when you want to send a push notification to the user then you have to just call endpoint (endpoint is mentioned in subscription token). That's it.
Due to security risk and managing subscription tokens, developers prefer to use firebase, AWS push notification or onesignal.com services. These services are optional you don't need at all.
Read links introduction to push notification and also the same lab code examples. Later I will update with simple working code for further reference to your question.
It depends on what you want. It‘s not possible to use iOS Safari for Web-Push. For notifications to iOS you have to use a service or build your own app.
I use Pushover for notifying myself from Scripts and Software. That may or may not be a solution depending on how much users you have, how many notifications you send and how willing your users are to use a web app like Pushover (or an app on iOS).
A service will keep notifications going when things change. So it should be less maintenance for you.
If you want to target iOS visitors also, this is not possible, as web push notifications are not supported by iOS.
To circumvent this, you need to use a third party service like Wise Notifications.
The alternative is to build an iOS app and send native push notifications.
I basically want to read and write Skype messages. I am not having Skype for business and it seems that Skype desktop Apis is ceased. Is there any way to push and read messages in Skype programmatically.
Send message to a user and receive messages from a user programmatically via APIs from their desktop application. Say a script runs in the background and push messages at a given time to a certain user.
You can take a look at these:
Documentation
and this Gnoe Extension
What is the difference between the newly release ASP.NET WebHooks and Signal-R? What are the advantages or disadvantages? What are the use cases for each technology?
SignalR is for notification within an ASP.NET app using WebSockets. You can exchange event notifications through WebSockets, however it requires a constant network connection.
WebHooks are for event notification across other web applications and other external services. (Think B2B communication). For instance, you can receive a WebHook when someone sends you money to your PayPal account. PayPal fires off a POST request to your predefined URL handler and then your app does something with that notification. You pre-configure everything on the PayPal side first. You also set up an application to handle the incoming POST request. The event notification is "pushed" to you in (near) real-time. No need to hold open a network connection while waiting for events.
The two can be complementary. For example, when you receive the WebHook from PayPal, you can notify a logged in user on your webapp (using SignalR/WebSockets) that money has been received successfully.
TLDR: Event notification across different web applications
It really depends on service you want to integrate with and how. WebHooks is a simple pattern for integrating event notifications across different SaaS services. If the service you want to integrate with supports WebHooks then you can use that. If it supports SignalR then you can use that. In that sense the two are quite complementary.
Check Henrik F Nielsen post at
http://blogs.msdn.com/b/webdev/archive/2015/09/04/introducing-microsoft-asp-net-webhooks-preview.aspx