I know the flutter_local_notifications_plugin allows an app to display notifications.
I want to access the data of notifications that is received, regardless of whether the app is running in the foreground, in the background, or not running.
Essentially the app needs to
- Add that notification to a persistent storage, and
- Depending on the notification, make a call to an API (eg an HTTP GET), and
- Depending on user preference settings, display a local notification
Note the question is not about the detail of implementing these three things as those would each be worthy of a whole article. But how to "receive" these events in each of the three possible app states, on both Android and iOS?
Broadly I expect some kind of broadcast receiver would need to be registered and a call-back needs to be created for when the event is triggered. I imagine this callbackmay want to be in a special Isolate perhaps since it can't depend on the app being in any particular state.
For Android devices, you can use the Notification package. For iOS I'm afraid there's no solution yet.
void onData(NotificationEvent event) => print(event.toString());
Related
For implementing notifications on Android TV below points needs clarification
As I have gone through SO and other articles, Android TV doesn't have notification tray,
Hence Notification has to be handled in a custom way. Therefore, please clarify:
Can we use Notification Manager.
Proper method to implementation Android TV notification.
Can we set the Notification priority
Possible way to find out whether the user has seen/interacted with notification or not
Handling list of notification messages by Local Database or any other method.
Any help would be much appreciated.
Notifications on Android TV OS are significantly different than mobile Android. There is an area to display notifications within the launcher, but it is limited to system-level notifications that are important for the user (e.g., issues with your account or info about OS updates). General app notifications do not show up, which means you need to display any kind of notification within your own app UI and not with the regular NotificationManager and related APIs.
Can we use Notification Manager. / Can we set the Notification priority
Yes, but it won't result in a notification being visible to the user and shouldn't be done on Android TV OS.
Proper method to implementation Android TV notification.
This should be handled within app UI. Most apps have a reserved space to show these on the main screen so that users see them as soon as they open the app.
Possible way to find out whether the user has seen/interacted with notification or not
Since you'll have to display it in your own UI, you can use regular View methods. For example, if you want to know if the user clicked the message, you can add that code to the OnClickListener.
Handling list of notification messages by Local Database or any other method.
This is a bit vague to give a specific answer, so you may want to post a separate question with more details about what you're trying to accomplish. One general way to go about it is that you have a server endpoint that understands the state of notifications for a given user and you sync that with your local database (easiest is probably Sqlite using Room). Your UI needs to be told if there's a relevant notification to display within the app, but the details of that depend on your app architecture.
My project is based on jitsi meet for android. I'm planning to go with react-native and firebase. The requirement is if one person calls the other person they will receive a call screen with ringtone. How can I achieve this if the app is not running in background?
This is a very tricky solution that you're trying to implement, especially it's working will vary a lot when it comes to deploying the application on Chinese OEM apps.
The process that you could instead follow is, Listen for FCM notifications along with that attach a payload to validate what kind of push notification is it. Based on that if it's a push notification for an incoming call, you can launch a foreground service which will allow your app to stay active and at the same time use a custom Broadcast Receiver. The Broadcast Receiver will receiver a trigger from your FCM Service and that will be used to open an activity that has your call screen UI.
Feel free to connect for a any help needed.
Using FCM, if there's a push notification, app automatically opens even if its not in background. But i believe you need to pass url on click of push notification of which triggers Deeplinking to actually trigger that page when the app opens, so directly it would navigate to the jitsi call page.
Check this link rn - deep link
Hope it helps. feel free for doubts
I have an app with different notification types it can receive (for example News and Podcast). Currently it has two simple switches where the user can enable and disable those different notification types. It works by just subscribing and unsubscribing from the corresponding Firebase Topic for the type. The clear advantage is that the device only receives the notification the user wants and does not have to filter them locally => battery and data efficient.
Problem is, I want to combine it with the new android O notification channels. Am I right to assume that the only way is to just subscribe to all topics in Firebase and have the user manually disable unwanted ones in the android settings?
Is there a better way that saves more battery life (by not receiving all notifications)?
The Notification Channel (a feature only needed for Android O -- presumably onwards) is (like) a parameter that you would (typically) use to sort/manage the notifications you build locally. --
Android O introduces notification channels to provide a unified system to help users manage notifications.
It doesn't necessarily disable receiving the notifications that you don't want to receive, but (AFAIK) notifications built without the Notification Channel won't show up/display in Android O (not received != not displayed). i.e. Your device may actually still be receiving the notifications, but just isn't displayed.
For Notifications sent through topics, so long as the corresponding registration token is subscribed, it is the expected behavior that the client would handle it accordingly.
With all that said, what you already have implemented (if I understand your post correctly -- subscribe and unsubscribe to topics based on a switch of some sort) is already the simplest as it could get.
If you want to totally disable notifications completely, you could call deleteInstanceId(). See my answers here and here for some additional info.
We have a back-end server that sends FCM push notifications with a data payload to Android and iOS devices. I am working on the Android app. When the app is in the foreground, onMessageReceived is called and the data is retrievable from RemoteMessage. When the app is in the background, a system notification is posted. A user clicks this and the data is retrievable from the Intent extras. All is well.
I am trying to figure out how to handle the case of multiple notifications coming in while the app is backgrounded or dead. The desired behavior is to "suck in" any active notifications and be able to retrieve their data payloads. I can get and clear (cancel) the active notifications using the NotificationManager (API >= 23), or implementing a NotificationListenerService. I have not been able to figure out a way to get the data payloads associated with them. The StatusBarNotification.getNotification().extras seemed promising but did not contain the data. I have even used the Android Studio debugger to inspect the notifications returned from getActiveNotifications() and have not found anything.
I think the "correct" answer, from my research, is to send the "notification" portion for iOS pushes, but omit it for Android pushes (ie. data only), and then post my own notifications locally on the device when my app is not in the foreground. Then onMessageReceived should always get called and I can save away the data payloads and have complete control. However, I am not sure we can change the back-end server to support a split Android/iOS path at this point. And from I've read, I have concerns about the service not being called on certain devices if the app is killed.
So, does anyone know of a way to retrieve the data payload of other active notifications? Or have alternative methods of going about this without requiring back-end server changes?
Thanks!
I think the "correct" answer, from my research, is to send the
"notification" portion for iOS pushes, but omit it for Android pushes
(ie. data only), and then post my own notifications locally on the
device when my app is not in the foreground. Then onMessageReceived
should always get called and I can save away the data payloads and
have complete control.
this is the correct approach. (currently the only available)
However, I am not sure we can change the back-end server to support a
split Android/iOS path at this point.
We are working on improving the API to better support your use case.
Unfortunately I cannot share an ETA for that work.
And from I've read, I have concerns about the service not being called
on certain devices if the app is killed.
Those devices would not receive notification-messages neither :( .
Those devices don't even receive AlarmManager events, and neither system broadcast.
If you encounter such device please contact the manufacturer and let them know that their behavior is not standard and it's breaking your app.
I'm implementing an app with an internal calendar, fetched from a remote web service. I want to send a local notification to the user when an event of interest is scheduled in the calendar, at a specific time chosen by him. Just like the iOS calendar app, when you can create an event and ask to be notified X hours/days before it happens. The main difference is that you can't create events: they are downloaded from a pre-populated remote calendar.
In Android I've solved the problem by using AlarmManager, while in iOS with Swift 3 the closest I've got to porting the same solution was via opportunistic background data fetch. The main difference between the two solutions is that background data fetch doesn't work when the app has been killed.
It would be really important for me that local notifications worked even when the app is killed. I think users expect apps notifications to work even when the app is closed, like it happens with WhatsApp or Facebook. I know that those notifications are triggered by someone writing something and therefore they are Push Notifications, but the average user just expects notifications to keep working even when the app is closed.
What would be the most elegant solution to "emulate" the behaviour of Android's AlarmManager in iOS?
Scheduling a bunch of notifications in advance hoping that the user will eventually open the app before all of them are dequeued looks a badly designed solution.
Also, delegating all the work to the server and push the notifications to the subscribed devices looks quite bad too as it requires much more work on the server side. Plus it requires a server which is able to awake itself to send push notifications, which is something that I don't have. I only have a simple webserver which answers to HTTP requests.
EDIT : The ideal solution I'm looking for isn't any of the previous 2 options, since I find them more like workarounds than actual elegant solutions to what I perceive being a fairly common problem. There has to be a third option...
In iOS there is no way to achieve this. Looking at the documentation of application(_:didReceiveRemoteNotification:fetchCompletionHandler:), it states that
the system does not automatically launch your app if the user has force-quit it. In that situation, the user must relaunch your app or restart the device before the system attempts to launch your app automatically again.
You can receive push notifications, but no code will be executed until the user launches your app. So unless you are sending remote push notifications from a server, you cannot set up new local notifications until the user opens your app.