How is it possible to have React Native trigger some kind of message on the device at a certain time, even if the app is currently not selected or closed down altogether?
I would simply use a push notification. This is something you will need to setup server side but it sounds like you have a good use case. You will need to setup permissions etc for this.
Maybe also a good use case for local notifications take a look at React Native Docs
A small completion to #JamesWatling's answer. You'll need at least:
AppState (https://facebook.github.io/react-native/docs/appstate.html#content) to post the timestamp to server, when app is moved to background
Push Notifications (e.g. https://onesignal.com/ or for iOS: https://facebook.github.io/react-native/docs/pushnotificationios.html#content) to send a notification after certain amount of time
You might want to have a look at this part of the react native documentation and focus on local notifications. You don't need a server or anything to schedule a notification at a given time, a local notification is scheduled without a server interfering.
I do believe your app is going to need to have permissions for push notifications though (so the app is allowed to display a message on a homescreen for instance)
Related
I would like to create simple forum where users would be able to add/delete/modify posts stored in database. I have simple auth app: client(react app) - server(express). Is it possible to force client side to rerender for one user when there is a change made by another user while both are loggedIn?
It should be simple enough. When a logged in user is on a page that you want to keep synced, open a websocket to the server. Then, when any user makes a change, the server can update its database, and then once that's finished, it can send a websocket message to all users with connected sockets on that page, containing the new data to render.
In the client-side React, create the socket and subscribe to its message event. When a message is sent from the server, call the state setter with the new data.
This mechanism is somewhat similar to how Stack Overflow pushes "An edit has been made to this post" notifications when a post gets edited - anyone looking at the page will see such server-sent notifications through the websocket connection to Stack Exchange.
Websockets is one approach you can follow. If you think this will be complex to implement, you can poll for the data every minute or so.
This is very useful library tailored for React:
useQuery- https://tanstack.com/query/v4/docs/reference/useQuery?from=reactQueryV3&original=https://react-query-v3.tanstack.com/reference/useQuery
You can use it for polling/caching and making regular network calls as well. Lots of utility is provided that you can leverage; especially, considering the use case you seem to be tackling.
There is a slight learning curve, but its worth it if you're a react developer.
Let's say that there is an update in certain collection and it triggers function that "exports" notification for certain user (token). I have implemented Firebase Functions in JavaScript for Firestore Triggers (onCreate, onUpdate,...) and it works if app is in background.
I want to send a notification whether the application is running or not...
Can user receive notification (lets say onUpdate) if app is in foreground or that feature is not ready yet (since triggers are in beta version)?
Thanks in advance
If depends on whether your message contains a data property, a notification property, or both.
If the message only contains a notification property, it'll delivered to your application code if the app is in the foreground, but handled by the system when the app is in the background.
If your message contains a data property, it'll always be delivered to your application code. If it also contains a notification property, that part will be handled by the system when the app is in the background.
For more on this, see the Firebase documentation on message types.
I am currently using SocketIO and NodeJS to handle messages. However the problem is that when the user becomes offline there's no way that the other user will receive the message.
The solution I came up with was to store the message in the database.
But a new problem arise, when fetching the message and push notification.
If I do fetch for "n" minutes in the server when the app is in background/inactive. There will be a lot of request in the server, and I personally think that it is inefficient. and also it drains the battery.
What is the proper way how to handle fetching the messages from database or pushing notification in app without making too much request in "n" minutes and draining too much power?
You need to save the last sync time in the App. And whenever app comes from background/Inactive state. You need to call an API with this time. This API will give you all the messages and the Push notification which has comes after the last sync time. In this way, With one API call, you will be able to get all the messages and push notifications. I had used this approach to syncing my data in one of my app.
My suggestion is to implement a system of background jobs in the API, checking when there is a new notification to be launched, or with the notification already ready waiting to be launched in the queue. You can search for queue manager like Bull, Bee-Queue.
To launch push notification in the closed/inactive app, you can use a service like OneSignal or Firebase.
I implemented this a few weeks ago and did it this way.
API = Node.js, Bull Queue
App = React Native, OneSignal
Going back to this question if somebody stumbled upon this question.
The best way to handle offline messages regardless if you are using NodeJS/MongoDB, etc. is to store it on server's database. Then call an API that fetches the the messages which is equal to user's ID whenever the mobile app comes to foreground.
If your problem is that you needed notification and you are using
react-native-push-notifications / react-native-push-notification-ios
Then you should use the data notification to include the message on notification parameter on the server's side(Assuming that you are using Firebase Cloud Messaging). With this way you can directly save the message on the mobile's database.
I am building a messaging app that updates in realtime. So far I can log in with google and post a message and then that message displays on screen. however, if I log in via another google account (the app is hosted on heroku) and post a message as userB then userA won't see this message on their screen until they refresh the page. what is the best way to update all screens in real time so people can actually have a conversation in real time.
every message is posted and stored in the firebase. my only solution so far requires using the javascript setInterval method and pulling from the database every 3-5 seconds. this worked however it caused the app to become very slow and laggy and a poor experience. any pointers/tips are welcomed
You are using the Firebase and its one of the main feature is the real-time database. Firebase will automatically let you know if there is any change in your JSON database. You no need to send the request in interval basic.
You can refer Zero to App: Develop with Firebase - Google I/O 2016 It is also a messaging app demo by the Google Guys.
You can find the sample source code in Github to send and receive the message in real-time.
There are a lot of ways to do this. Generally, you will want to be notified by the server once a new message has come in and not have to ping the server every X seconds.
You could look at these:
socket.io and learn about websockets in general
A nice list of existing chat apps that utilize react
Google's cloud messaging, as you already use firebase, this might be the way to go for you here.
This should lead you in the right direction.
I'm working on a Win 8 javascript app that has rss-reader-like capabilities. It should repeatedly check a server for new posts and display a toast, if a new post was found.
My question is, if I should use a background job with a time trigger (that is limited to an interval of 15 minutes) or if a setTimeout / setInterval wouldn't be the better way.
As far as I understand the app lifecycle, my app can be suspended by Windows at any time it is not focussed and Windows decides that timepoint on itself. And if the app is suspended once, neither background jobs will work, nor will the setTimeout / setInterval fire.
If I may, I'd suggest rethinking the notification mechanism here.
If you want to use a toast notification, I'd suggest a push notification. It does require a require a cloud service that does the polling of articles for you and then pushes the notification to subscribing clients; however, it won't tax the battery life of the client nearly as much as a polling trigger.
An issue with toast notifications is that they can be easily missed, so if you want to inform the user of unread articles, you may want to consider a badge notification that will persist on the application tile (like you see on the Mail application). Then at a glance the user will know there are unread articles, versus knowing that only if they happened to see the incoming toast.
Tile and badge notifications can also be updated periodically, which is similar to what you wanted to do with toast, but the mechanism for doing so is much easier. The challenge here though is that periodic notifications aren't generally personalized, that is every user of your app would see the same badge/tile unless you did a bit more work on the server side.