How to Implement Web Push Notification for incoming calls - javascript

I am creating a video/audio calling web app and want to show users an incoming call notification just like it would show in a native calling app
So, is there a way to implement it?
I know I can implement simple push notifications but that is different from what a notification for an incoming call would look like.
when an incoming call comes in a native app, the phone's ringtone starts playing and the notification stays there until the call timeout happens or the user makes an action.
so I need something like that.
I have a nodejs server with a client app

Related

React-Native - How is it possible that when I close an app like messenger I can still receive incoming call notifications from others

I am building an app like Messenger, everything works normally like sending messages, receiving messages, video calling. the technologies i use are react-native, reactJS, socket.io, nodeJS, react-native-webrtc
I wonder how can when I close an app like the messenger I can still receive incoming call notifications from other people. I'm studying firebase notification and react-native-background-timer but it doesn't seem to work the way I want it to
Has anyone had a problem like this and have an answer, please let me know
Have a nice day guys <3
In react native firebase there are two types of notifications "background" and "foreground".
Foreground Notifications:
A foreground service performs some operation that is noticeable to the user. For example, an audio app would use a foreground service to play an audio track. Foreground services must display a Notification. Foreground services continue running even when the user isn't interacting with the app.
When you use a foreground service, you must display a notification so that users are actively aware that the service is running. This notification cannot be dismissed unless the service is either stopped or removed from the foreground.
Background Notification:
A background service performs an operation that isn't directly noticed by the user. For example, if an app used a service to compact its storage, that would usually be a background service.
You want to follow there Documentation to apply push notifications in react native.

How to cancel local push notification when user is on screen chat?

Someone know how can I cancel local push notifications when user is on a particular screen?
I'm using react-native-push-notification that should stop getting notifications when the user is in the chat screen and resume this action when he lives...
Try putting PushNotification.cancelAllLocalNotifications(); in the component's ComponentDidMount method.
As I understand you are trying to implement push notification sending only when the user's app is in background mode.
Why don't you just use offline push notifications for this case?
Many backend providers like ConnectyCube have this option. So, you just need to manage app states to handle background mode via AppState.currentState and make sure that the device is subscribed to pushes.
Or do you mean you need to send pushes when the user is in the app, but on another chat screen too?

Persisting a JavaScript setTimeout function call across postbacks as user browses application

I believe I can use utilize the following functions to create delayed JavaScript alerts:
setTimeout(), clearTimeout(), setInterval() and clearInterval()
But how can I use them accross postbacks. For example:
A user has a list of reminders stored in the database. When user logs into site I can access those reminders and call something like:
setTimeout(function() { alert("Reminder 1"); }, 10000);
Depending on when the reminder due date/time is.
However as the user switches pages before the alert notification happens I believe the setTimeout call won't persist.
Is the only way to get this to work to look up the users reminders on every single postback and do a setTimeout on every page or in some sort of master page?
This is not really the way to do this. If your trying to build some sort of notification system then ideally it should be driven server side.
In a normal multi-page site every time you render a page the server would check for notifications and then in your template render an alert or some UI feature that tells the user they have notifications.
That set-up won't be active, IE if a new notification is posted on the server the client page won't know about it. Unless you use a notification message api for example pubnub.
Something like pubnub would let you send the message to your page, and in your JS code get a callback, so you can render it in your dom.
Since you have a multi-page app you would need to fetch / request for the notifications on every page render. Running a timeout to trigger for an ahead of time moment is not an ideal solution.
Another way to do it is to poll your server from your js code say every 5 mins and ask for notifications.
That has a price tag on all those repeated calls to your server. The best bet is to use something like pubnub but that comes at an extra laden of code server side to make it work.

Pubnub: Background Processes for an Auction App Development

Hello I am developing an auction app like tophatter.com. I want to implement an application that has background process in it. I want this process to run forever until I stop it
http://eoction.com thatss our current site. The problem on our site when we refresh the page the auction also restart. We need something like a continuous process like tophatter.com if you refresh the page it will load the updated auction process.
I found this great service called pubnub. I am thinking we need a background process for this? This will process the auction on the pubnub blocks and then when we visit the site we will just need to query on its updated process?
Does pubnub support something like this?
PubNub Web Page Best Practices
When user refreshes your web app page or navigates to another page there are things you need to consider as a web app developer no matter what technologies you may be using. I will address, at a high level, the things you need to do when PubNub is integrated into your web page.
Restore Parameter
Whether the user interrupts your connection to PubNub or it is a network failure, you will want PubNub to reconnect and continue where it left off as much as possible. The PubNub JavaScript SDK has a initialization parameter called restore that when set to true, will reconnect to PubNub and get missed messages after the connection is dropped and reestablished.
var pubnub = new PubNub({
subscribeKey: "mySubscribeKey",
publishKey: "myPublishKey",
ssl: true,
uuid: getUUID();
restore: true
});
Reuse UUID
It is important to reuse the same UUID for each end user as this will allow PubNub to identify that user uniquely when it comes to Presence so that it doesn't produce new join events for the same end user. The PubNub JavaScript SDK actually generates a UUID and stores it in localStrorage and reuses it by default but very likely you have your own UUID that you would like to use for each of your end users.
Last Message Received Timetoken
If the network disruption is brief as is the case with a page refresh or page navigation, then missed messages are retrieved when restore:true is implemented in the init as stated above. But when the user is offline for more than say 5 minutes, you may want to retrieve missed messages on one or more channels. The best way to do this is to keep track of the timetoken of the last received message by storing it in localStorage every time a message is received via subscribe callback. When the user comes back online and it is has been more than 5 minutes since they were last online, call history using this last received message timetoken on each channel that you need to get missed message from.
Subscribe to Channels
Finally, you'll want to make sure that the user is subscribed to the channel they expect to be based on what their state prior to the connection disruption. If it is a page refresh, you likely just want to resubscribe them to the same list of channels. To do this, you just need to keep a list of channels they are currently subscribed to, once again, in localStorage. If the user navigates to a new page and this causes a full page reload (modern web apps should not require this, but...) then you may want to unsubscribe from some channel(s) and subscribe to new channel(s), it just depends on what that page navigation means to your app. Modern web app frameworks do not require full page reload for page navigation since the web app acts more like a desktop app than older web apps. And again, if the the user was offline for quite some time (more than 5 minutes) then it may not make sense to subscribe them to the same channels that they were subscribed to before. Really depends on your use case.
And by the way, Tophatter uses PubNub ;) but all of the above are generic best practice guidelines and recommendations and is not referencing any one app in particular.
EDIT: To address you question specifically, as pointed out in comments below...
You can't implement long-running process in PubNub BLOCKS (not currently, anyways), so you will need a server process for this. When the user refreshes the page, you just need to hit your server for current state. If using PubNub to keep this progress bar updated in realtime, you just subscribe to that channel that is sending the state of that progress bar and update your client. Using the same best practices I provided above are still necessary.

Appcelerator app Timers for checking server api response

I am developing Appcelerator Titanium Alloy mobile app for Android and iOS. I have a user case where a certain action is performed by other app user which trigger change of object state on server. App is connected with REST api. Then other users should be notified by this change and their app should sync and update app state.
I believed I should be using timers to continuously check the api which inform other users that change has happen on server for state. Once this change is update I shall remove timers...
Is this good approach to use Timers?
thanks
No timers. Should use sockets. I.e. when a change is made on the server, send a message via a web socket to all other users...
If you use timers you will always have to check because you're client will never know when a change happened... And you will waste many trips to the server asking 'anything new?' you can never remove your timer because you don't know when something changed.

Categories