With the new NotificationListenerService introduced in 4.3, it's possible to query all currenty active notifications using NotificationListenerService.getActiveNotifications(). Is something similar possible with the AccessibilityService? I wouldn't mind keeping track of them myself (store them temporarily once a new notification comes in), but it seems that there's no "onRemoved"-event for the AccessibilityService, so it's impossible to keep track of which notifications are still active and which have already been dismissed?
Apparently this isn't possible on pre-4.3. I've resorted to storing the notifications locally as they come in, but this isn't a very good approach since there's no way to tell when a notification was removed.
Related
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());
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.
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.
I'd like my android auto notification to not have any reply mechanism to it. I just want a notification that you can swipe to dismiss, but the only two options i see for android auto are messaging and audio. The messaging makes the notification have a reply to it like this:
notice how there is a microphone for user to reply. I dont want that on my notification. I only want to display info but no reply mechanism. I am not interested in reply, only to notify user of something. i want it to look like this instead but it seems only system has this kinds of notifications.
Android Auto has defined guidelines for Messaging Apps.
It didn't consider normal notifications as a scenario that needs to be addressed now in Auto environment.
We can hope it may be made more flexible on future along with measures to make sure that distraction is avoided by strict certification process.
So the answer to your question is - Not possible now.
I want to be able to programmatically check if there are any notifications present (preferably only non-permanent notifications) in the status bar. This should include all notifications and not just ones created by my app. I don't need information about the specific notifications or even the total number, I just want to know IF there are notifications being displayed in the status bar currently or not.
I have researched and found that I'm likely going to have to deal with the accessibility service. That's fine, but so far I haven't found a solution to check for current notifications, all solutions so far only show how to detect NEW notifications. I want to be able to query at any instant and check for presence of notifications.
One (ugly) option would be to constantly keep track of all new notifications and clearing of notifications, but I fear this may not be reliable. I want to know if there any simpler or cleaner methods.
Any guidance will be really helpful.