I am trying to get push notifications working in a ios React Native app and am half way there. The one problem im having is that my logic for displaying a Notification while the app is in the background doesn't execute until the app becomes active again. I am using Socket.io and listening for events, but the code to handle (say onChat event) doesn't run until the app is active. I have verified that the socket is still connected.
The one things thats weird is that is works in the simulator but not on my device. Maybe there is performance optimizations that halt JS execution while the app is put in the background.
How can i get my JS to execute while the appstate is in the background?
What im doing is calling a function when the event is recieved over the socket and it runs:
PushNotificationIOS.presentLocalNotification({
alertBody: `New Chat: ${chat.message}`,
});
Thanks to this stack overflow question and answers I was able to find out that code is not executed in the background state to prepare it for the suspended state. The background mode is a transition state to prepare the app to be "screen shotted". The socket will stay connected only for a short time there after, but would eventually get terminated.
In the case with doing a push notifications, I would need to turn that over to Parse or some other service to push a notification to my app while the app is in the background.
Also see http://zeroheroblog.com/ios/what-to-do-when-your-iphone-app-moves-to-the-background
Related
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.
Apologies for the somewhat general question - I'm not really sure what direction to take this in.
I'm working on a chat feature in a mobile app (React Native is that is relevant), and handling push notifications with OneSignal. I'm currently updating the chat interface with an indicator for unread messages, which is updated when a new push notification comes in for a chat. However, this functionality doesn't run when the app is closed.
Anyone have experience with a similar functionality, or have any guidance on how to handle this feature? I'm at kind of a loss on how to proceed.
You can know that application is opened via manually(by pressing app icon) or via notification. Depending on the opening of application and parameters from push notification you can change the UI.
PS : If your application is chat app, isn't real time (like firebase realtime database)? I think you don't even need push notification to update UI if it is realtime?
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)
I want to save the state of my app when the system decides to kill it randomly (when for example it was in the background for a long time). How do I intercept the OS's request to shutdown before my state is lost?
React-native provides an API called AppStateIOS which allows you to get notified when your app switches states. It doesn't provide notifications for all of the app lifecycle state changes, but it does let you know when your app goes to background.
The background state should be enough. When your app goes to the background it gets suspended (assuming you are not using background tasks or background services), and in this state, the OS can terminate your app at any moment if it needs more resources. You won't be able to know when your app gets terminated, so when it goes to the background - this is the point where you should save your state in case your apps gets terminated later.