OneSignal sending to targeted users - android

I'm planning to send push notification to targeted users. I understand that this can be achieved by targeting by the player ids. But going for this approach would require my database to introduce dependency with OneSignal which is something that I'm trying to avoid.
I'm thinking is it possible to target players by username. What I mean when the app initializes it would update OneSignal saying that 'my username is user1' and when the server sends out notification it can target 'user1' (again, without using the player id approach).
The closest way that I could think of is tagging where the user could register themselves with username as the tag and server could target the user by using the tags. But from the documentation it seems like with this approach we can only target 200 users at once which is not feasible to me as well - I might be sending to thousands of users.
Any advice?

As you suggested, tags are the best way to achieve this without storing OneSignal IDs.
Although this is limited to 200 at a time, you can make multiple API calls to deliver to a larger number of total users. OneSignal's average API response time for this method is below 50 milliseconds, so this method will allow you to reach 4,000 users per second if you make the API calls in sequence.

OneSignal is a wrapper to Firebase Cloud Messaging or FCM (previously Google Cloud Messaging or GCM) on Android. If you don't want to rely on OneSignal internal device ID (or Player ID), you could still use FCM/GCM Registration IDs directly (also called push tokens) to target users with notifications. But in that case, you still have to store new IDs on your servers (instead of using your owns) and more importantly, you'll have to deal with FCM/GCM tokens complexity by yourself (managing errors, canonicals etc.)..
A better solution would be to use a third party like Batch.com (disclosure: I'm a co-founder). We allow developers to provide their own User ID (it's called a Custom User ID, you can set it from the app code) and then use it with our Transactional API to send push notification to one or more users (recipients can be push tokens, Batch installation IDs or your own User/Custom ID).

Related

how to send push notification via firebase cloud messaging (quickstart)?

I trying to understand how FCM (Push notifications) works... and that is very differ with Web applications...
What I did →
Register new project in Firebase
Added App com.google.firebase.quickstart.fcm and download google-services.json
Built App using google-services.json in Android Studio
Install APK on my device
Go to https://console.firebase.google.com/project/{PROJECT_NAME}/notification and sent new notification
And... nothing happens
So my questions are
As I know here is two ways to send notification: a) use device token and send direct notification, b) subscribe device to topic at client side.
But
a) When I try to create New notification in firebase console, here is no field where I will be able to insert device token. Here is Target → Target user if → App → com.google.firebase.quickstart.fcm. So do I need to know device token or I can send notifications to all clients that have my app installed on their devices?
b) When I trying to send message on weather topic nothing happens. Even if I pressed button Subscribe to weather (In manual you may find Subscribe to News, but actual version button is weather)
Is there any way to check (especially at server side) if my device registered in FCM or not?
What is the most effective way send same contents on big number of devices (for example 50000) with minimum time lag? Try to loop over device tokens (1000 tokens per request) or using topics? Is there any other ways?
Actually my backend is AWS SNS in pair with FCM, so if you can answer about most effective way in case of SNS + FCM that will be brilliant
I don't know... any suggestions? I'm a web developer (REST, etc...) and have zero experience with mobile apps
1- You will need to store the current device tokens in a database to then loop through each one to send a message.
Topics need to be subscribed to from the client side and have limited use
2 - you should be storing it in a database, sending an FCM will yield an error if it is expired, which you will have to remove and wait for the client to re-send a fresh token
3 - Topics is common practice, have every device listen to a 'global' topic but there is a native delay as FCM is designed for maximum output rather than time sensitivity. for that, you will need external services that specialize in high speed messages.
4 - you can invoke cloud functions to invoke other firebase services, even the rest API and onTrigger listeners on a database are valid
5 - FCM is great, but it's not the best as it was created as a general solution. a combination of different CM services is recommended, especially if you have time-sensitive needs. but they do come at a cost while FCM is free.

How is that FCM targeting for app package works from Console in Composer yet not in APIs?

How is that Google, in Firebase Console Notification composer, allows to set notification target to a specific app package name, yet I read there is no way to do it with API? How to send Firebase message to specific application in project?
Is there some hidden capability Google not exposing to devs?
I know about topics, but it takes extra work to set and subscribe to, plus they won't work right away and require some wait time.
The Notification Composer is an online tool hosted by Firebase.
Therefore it already knows the Server Key (required to send messages) associated to each of your projects.
By design (and for obvious security reasons), the Server Key is implicitely linked to a single app, and you can't use it to send a message to different apps.

Is it possible to target multiple apps with firebase, but only one will display the notification

I am new with FCM and I am still discovering its possibilities.
I wonder if it is the right tools to do what I want:
I would like to send a notification to all my users, to inform them about new informations for example.
The difficulty is that I want to target all the users of different apps (like 10 apps), and some of them may have more than one of my app installed.
So I do not want a user to have the same notification displayed multiple times (if he installed more than one of my app).
Is it something possible with Firebase?
Thank you
Yes you can! To achieve this, i recomand you using Google Cloud Messaging not FCM. which it's an earlier version. Here is a tutorial on how you can migrate from FCM to GCM.
To achieve this, all your 10 apps must use Firebase and all your users must be Firebase registered users. To send a notification to all devices, would mean then to select all the registration ids from that database, add them in an array and pass them further to GCM.
Note also, that strating with GCM 3.0 it's now possible to send a notification to all devices thanks to topics support. The app must suscribe to one or more topics and the server can send notifications to that topic without specifying individual devices. You can see here Topic Messaging.
Unfortunately, there is no way in which, with a single line of code, to send a notification to all of your users from all your apps. You can only send a notification to all your users that belong only to a single app. If you want that all of yours to get the same message, then you need to consider sending that particular message again, to all users that belong to each app. In this case, if a users is using more then one of your apps, will receieve that message for each app separately.

What is a good time between synchronizing jobs?

After discovering that WhatsApp probably updates notifications about every second I began to wonder what the best combination of battery life and keeping users up to date by notifications is.
The company where I work right now is really afraid of sucking the battery life. So they want the fastest sync to be around a quarter. Meanwhile WhatsApp updates every second. So is what our company doing the right thing? Or can we just like WhatsApp check for new updates every second because it doesn't suck that much battery life?
That extensive network usage will surely be very expensive for battery and even for data usage. If you need frequently updated data in your app, in most of the cases it's a bad practice to send HTTP request once per 1 (2 or even 5) seconds.
A good way to receive and update any kind of notification (wether it's Android system notification or some notification badge inside your app) is using Google Cloud Messaging. You'll have to implement it on both server and client side. You will need to register your app package name in Google Developer Console and retrieve an API key. After you do that, your app will be able to receive push notification from GCM server. The flow of receiving a push notification looks like this:
You register current device to GCM system using provided SDK and it generates you GCM unique identifier of current device
You upload this key to your server (if you have user profiles in your app architecture, it's a good idea to store it in current user profile)
Once something important happens on server, say, user gets a new unread message, your server takes the GCM unique identifier from user profile and sends a notification to GCM server
GCM server sends this data to user's device by using this identifier and delivers the notification to your implementation of a BroadcastReciever. After that it's up to you what to do with this data: create a system notification or/and use this information to update UI of your app.
It is just an overview of how does Google Cloud Messaging work, there are tons of articles about how to set it up and implement into your project, for example, this one. This solution might look way more complicated than just sending HTTP request every second, but your potential users will be thankful for saved battery and data limit.
Also, if you want to make Android system notifications, you may want to use Parse library which wraps GCM and makes implementation a bit easier.

I am using Google Cloud Messaging for push notifications in my app and i have 2 basic doubts about it

Is GCM the only way for push notifications in android? And is it advisable over other methods (if there are any)?
So let's say my app from a device registers on GCM. Is it the app itself which is assosciated with the device that registers itself, or the user and his email id that register? If my user switches devices in future, will the same 'registration token' work for him ? Or in a similar scenario if a user with another g-mail id registers to my app from the same device, do i push notifications to the same device with 2 different registration tokens?
Extending to what i asked in 2, suppose a single user has his g-mail id working on my app on different devices. Does GCM push the notification to all those devices, or only one of them? And if one, then how does it prioritize?
No, there are other push notification services in Android, like Parse. However, it is strongly recommended to use the default push notification service that is present in any Android device that has Google Play Store, because that reduces battery usage. If you are pushing your app somewhere else though, like Amazon Store, keep in mind that Kindle Fire does not comply with this and doesn't have Google Play Services -- at least as far as I know.
The registration token is very volatile and is not bound at all to an email. Actually, sometimes the same device may get a new GCM ID out of the blue. There are many tutorials on GCM's best practices, but Google's is the best way to start. What you should do to prevent problems is store the GCM id of your device in your database, so you can always know which ID is currently associated to your device. GCM may give you new IDs for no reason, so always parse its response properly and store the new ID it may provide, linking it to the device.
GCM doesn't really care which Google account is your app using. That means you can register as many devices as you want with the same account. You have to manage to which devices you push notifications, because the ID is managed by device.
Be careful: there's been some changes with the API lately, so a lot of unnoficial tutorials you find on the internet may point to deprecated methods.
There are other ways of sending notifications, Tokodu and RabbitMQ for example. I wont go over if X is better than Y, since it's not allowed on StackOverflow.
A unique device token is generated for the device, how you use this device token is totally up to you. You can make it unique for the user by, for example, implementing a login system, so that the device token is created and stored in a database (together with the user information). Let's say if two different users uses your application on a shared device, they can both receive notifications on the same device if you allow them to. It depends on your own implementation.
This again depends on how you chose to implement the GCM features on your client and server side. For example, you can choose to store device tokens for each and every device the user has installed the app on, or you can store the latest device token so that notifications are only sent to one of the user's devices.
I hope this helps clear some things up.
Besides good answers above, if you need a push notification solution for a working environment without Internet access, I suggest SignalR of Microsoft, which has already supported Android and Java (you can find out more at GitHub).
Hope this helps little!

Categories

Resources