I've been through the other threads on this issue and haven't found a solution. My case may be unusual.
I have just inherited a production mobile app (Ionic/Angular) that is available on Google Play Store and Apple App Store. I didn't have to create a new google-services.json or a new GoogleService-Info.plist file. I have access to the Firebase Console. I did have to replace the .p8 key for iOS in order to get APNs to play nicely.
I can send a single notification to a single FCM token for Android and iOS with no problem. But when our production system sends notifications they are often multiple duplicates. Additionally, we routinely send (for those subscribed) multiple but different notifications to the same device(s). For example, a user who is subscribed to topics A and B will normally get a single notification for each subscription. But right now, they'll get 3 of the same notification from A but only 1 from B (B, in this example, seems to behave normally). NOTE: the particular topic is irrlevant. The only thing that seems to matter in this case is that the first one will multiply and second is received only once.
Our server logs show only a single instance of sending any given notification despite multiples being received by devices.
I first suspected, and still do, that somehow during the "transition" of the project, somewhere in FB and Apple, there is a dangling reference to the original certs/keys/projects. I don't see how I can confirm/reject that idea. I also doubt it's the case. I need any and all suggestions because I'm out of ideas! Thanks in advance.
Related
I've two android apps that share same project in firebase infrastructure
When i was preparing the firebase infrastructue to run the second one i decided for creating a second app in the same firebase project as the first one... this was a decision made basically because i hated the firebase "switch between projects" tools.
both apps ran great for over a year being hosted as same project although not sharing real resources
BUT NOW I RUN INTO A PROBLEM
I added FCM into the apps and i cant find a way to send messages to topics in a specific app...
firebase let me only choose between send message to specific app or specific topic...
both apps have same topics names and now if any user has both of them installed at the phone i cant imagine how firebase will behave when i send a notification to a topic the user has two different apps subscribed to.
does anyone know how to solve this?
You can't stop the message from going to both apps. But what you can do is put something in the message to say which app it was intended to go to. The app can then choose to ignore messages it's not supposed to handle.
My setup consists of two android apps, that use the same backend. I was sending push notifications based on the deviceID, meaning if you installed both apps on the same device, the listener of app 1 would listen also to notifications intended for app 2, and hell would break loose.
I would like to know if Firebase can support this type of project.
So, does one Firebase project generates one Token per device per app, or only one Token per device?
If the latest, any tips on how to get this working?
Thanks in advance.
A registration (FCM) token corresponds to an app instance. AFAIK, different apps (unique by package name) should produce different tokens when getToken() is called regardless if it's using the same Firebase Project.
However, the usual (best?) practice is to have a separate project for every different app, then handle the multiple senders for each app.
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.
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!
I am finding difficulty to know about in-App messaging.
And how to do it.
I have the following things in my mind,
in-App messaging:
Is an idea to receive contents from a server only the app is alive on screen.
This is possible only the app is active.
App should make a call to server and needs to receive contents.
Push messages
Is an idea to receive contents from a server even though the app is not active.
This is possible at any time, we can notify users while our app is closed and running also.
App do not need to make a call.
But the app should have code implemented to receive push notifications.
We can use GCM for Android and Push Notification for iOS.
Am i right with my understandings ?
If i am not and i missed something , please give your hand to take me out of this confusion.
Thanks,
When I think of in-app messaging, to me it means that you're sending a message from one part of your app to another. "Sending a message" is a very generic term that can be accomplished in a number of different ways. Among others:
Sending a broadcast to a message receiver. You'll need to call sendBroadcast to a BroadcastReceiver.
You can pass a Handler to another component and it can post messages to your handler where they're processed
You can use a third party library such as the open source "otto" library
You can build your own version using the observer pattern.
For push messages, your understanding seems about right. However, look at this post for details on the last item, "We can use GCM for Android and Push Notification for iOS".
You are right, though I would change the term in-App Messaging to Pull Messages, since you are referring to the app pulling messages from the server, while in-App Messaging implies that the application is sending the messages.
You points are mostly correct, though Pull Messages does not require the app to be in the foreground (on screen) - a part of your app can run in the background and fetch messages from the server. This is more doable on Android, since iOS limits the operation an app can do in the background.
Another point that should be added to your list is that Push messages also have the advantage of conserving battery life.
In-App Messaging can also be viewed from another standpoint. AT&T has an API for In-App messaging that allows you to send SMS cross carrier. The API can be found here. along with others. From this you can imagine the ability to message from within an app, say a game or a social app and retrieve responses. There are examples for all the platforms you have added as tags. It might be good for you to look this over as it can expand your understanding of the concept in a different direction than the other answers, Somewhere in all of these you will find what you are looking for.