I have a pool of device tokens (iOS and Android) and in the docs, I find only one parameter sound for both platforms and obviously I have 2 different notification sound, one for Android and one for iOS.
Do I have to split device tokens by device type for sending to 2 separate device types? Or did I just miss something ?
Thanks.
Solution 1
You could name the same both audio files, like 'your_app.mp3'.
Same name, but different music file on each app. This not allow the user choose the notification sound, but at least allow each app to have a different sound.
Solution 2
Migrate to the new Firebase HTTP v1 API which allows you to customize notifications across platforms
Personal experience
Solution proposed by #daniel-raouf to send Data Messages is great; but in my experience, some Data Messages could not be delivered to your users when:
An user has a power save mode on his phone (by default on Huawei, Xiaomi, One Plus...)
When iOS users clear your app from recent apps (multitask).
So, in my opinion, Data Messages are not a reliable solution for notifications.
You had missed something,
A- If you want to allow the user to select his preferred notification sound at any device so
don't send notification
send only data to force the received content to pass by the onReceive event
In on receive add the sound the icon and data you want to the notification builder.
B- If you want the app to use the default sound
so in the notification body set sound:'default' and it would work for all types of devices
Related
There are several ways to send FCM messages and I don't understand which one to use even if I read the documents over and over.
My use case:
I have a user that is logged into the app on her iPhone, iPad and Android tablet. I want to make sure the push notifications are sent to all of her devices.
There are three ways to do this (I'm using the admin to send the push notifications):
Topic messaging (messaging().sendToTopic): My understanding this is for sending the same notification to larger groups. For example a topic could be all users that want weather notifications for New York. Not for my use case.
Send Multicast (messaging().sendMulticast([array of tokens]): My understanding this will send the same message to all device tokens in the array (up to 100). This seems perfect for my use case, right?
Device group messaging (messaging().sendToDeviceGroup): I don't really understand this one. Why use this instead of multicast or topics?
For my use case it seems the best way is to each time a FCM token is updated I add this token to the user in the database. I then send the notification using the admin.messaging().sendMulticast([array of tokens]). Is this what you would recommend? Why or why not?
You probably want to use multicast if you're targeting an individual user's specific devices. You probably don't want to use device groups. I suggest reading the documentation to understand how device groups work:
Device group messaging allows you to add multiple devices to a single group. This is similar to topic messaging, but includes authentication to ensure that group membership is managed only by your servers. For example, if you want to send different messages to different phone models, your servers can add/remove registrations to the appropriate groups and send the appropriate message to each group. Device group messaging differs from topic messaging in that it involves managing device groups from your servers instead of directly within your application.
Device groups are basically just topics whose membership is fully managed by your server code, not by client code.
With GCM, when user expresses their preference whether they are willing to get notifications, we could mark their preference as active or inactive
How can I achieve similar effect with FCM?
When user says they don't want to receive pushes, we'd have to unsubscribe the user from all the topics we have?
Are there better approaches?
Depending on the scenario, unsubscribing from the topics is the way to go.
However, if your goal is to simply prevent the user from seeing any push notifications appearing on their screen, a workaround I could think of is have a setting (e.g. enable/disable notifications) that identifies if you should/shouldn't display a notification every time the user receives one.
For example, user installs the app. Initially, the setting defaults to enabled. Push notifications are displayed normally. If user disables it, when the device receives the message, you do not create a notification display.
For this to work, I'm thinking the checking should be done inside the method where you create the notification (e.g. sendNotification).
So the scenario now is that the device is still technically receiving the notification, it's just that you're not showing/displaying it to the user.
Note: I haven't tried to go with this scenario myself, so I'm not sure if this is breaking any best practices. I would still go with the unsubscribing if it were me though. It's easier.
I just have a general question. Can you send a url from a button on the band. I have a home automation system that you can trigger events by sending a RESTful url (endpoint) to. Basically I can put the url in any web browser and trigger the event. It would be great if this could be done through the Band. I don't really need a response from the Url, just to send it.
Does that make sense?
Thanks,
Scott
No, the Band communicates only via Bluetooth to (applications on) its paired device. On Windows (Phone), the application must be running, with a connection to the Band, and subscribed to the Tile button pressed event in order to receive such notifications. This generally rules out scenarios that require ad-hoc input from the Band unless you're willing to use voice commands via Cortana.
But i think its possible by creating custom tile and handling custom tile events. Haven't tried it in my project but can see from sdk documentation.
For android you can implement broadcast receiver and listen to tile events. Check: sdk doc
Chap 9, page 51
In short, yes it is possible.
However, the problem would be that the button would be single use to only send that ONE URL command and it actually wouldn't be done via the Band.
You can create custom layouts for your applications with the Microsoft Band SDK which will allow you to create a button. You'll then need to register to the click event from the Band which then would get fired on the device the app is running on. From there, you'd be able to send the URL but it would be sent from the Windows Phone or Windows PC rather than the Band so you'd need to be connected. The documentation covers how you can do this here: http://developer.microsoftband.com/Content/docs/Microsoft%20Band%20SDK.pdf
A downside to doing this with WinRT is that as soon as the app is closed and the connection to the Band is lost, your button click won't have any action. The best way to get around this is to create the connection to the Band in a background task but unfortunately, you can't keep hold of the connection to the Band for an infinite amount of time and you'd have to live with the possibilities that you may have times where it doesn't work. I have a GitHub sample which shows you how to connect to the Band in a background task for an indefinite amount of time.
The Microsoft Band has really been developed for the Health aspect and collecting data rather than interactions with other apps which it does in some way support.
I am sending a XML with the "Count" parameter for tile update, and the tile is updating with that value, no problem here.
But I don't know how many pending notifications the user actually has, to increment. I see WhatsApp increments the counter immediately after I got a message. The only way to do this is to store the "unread" count in the server? I wouldn't like to do this because the user can: receive the notifications, disconnect, open the app (that will reset the counter), close, and connect to internet. When it happens, the "unread" count will be incorrect after a new notification.
(I'm using a standard tile for WP 7 compatibility)
Maybe this is a hint from the design gurus -- you might not need to show the user exactly how many unread notifications s/he has. Instead, you could make the push notification simply set a visual flag that there are some unread notifications. When the user opens the app, it displays all the queued notifications and resets the visual flag. Like a knock at the door: once you go to the door, you're going to let in however many dwarves you find waiting there.
Alternatively, you could use raw push notifications sent directly to the app, and let the app locally update the count on the tile.
Does anyone know of an AIR Native Extension (ANE) that allows you to access the device's notification sound(s)? OR, a method to query if the device is in "silent" or "vibrate" mode?
I've set up Push Notifications, but no sound plays on my (Android) device.
I know I can play my own sounds, but I want to use the native notification sound (the same as an SMS or email alert sound) and I don't want the sound to play if it shouldn't (viz. silent mode / vibrate mode).
I've been looking for hours and there's a "Vibrate ANE," and others looking for the same type of capability, but I haven't found anything usable for native sound notifications.
I believe that iOS automatically will play a notification sound when it receives a push notification (I think), but Android just flashes the "shade title" & shows the app's icon for the notification.
Maybe someone else has stumbled across a solution??? =)
Many Thanks!
Todd =D
I think you might have to be careful attempt to access the built in sounds on iOS.
We definitely could write an extension that played any of the system sounds. However I believe these sounds are copyrighted, and my understanding of the Apple ToS is that your application may get rejected from the AppStore if you use them directly.
This is why things like a notifications extension only use a "default notification" value to access system sounds that are set by the user. These sounds are played on certain system events.
The sounds are all accessed via undocumented IDs: http://iphonedevwiki.net/index.php/AudioServices
So yeah we’ve been very cautious of writing anything that could put developers in trouble with the AppStore. You have enough problems getting apps through as is. But if you read otherwise let me know.