I am designing an application which has two types of user, vendor and Customer. Vendor delivers product and customers order them.
I want to send a notification when a Customer orders something from a vendor. Only that vendor should get notification. Similarly, when the product is mark delivered by vendor, a notification should appear on the customer side.
I was thinking of storing tokens in Firebase Database in the profile for each user, so let's say a customer orders something, he can retrieve Vendor's token so a notification appears on Vendor's side.
I recently came across this answer Cannot resolve symbol com.google.firebase.messaging.Message
which says it's not possible to do so, without admin SDK, which can't be used in Android App.
What options do I have for this use case?
Do I have to create my own server? Is there anyway to do this with just Firebase?
I fell into this same problem before and I solved it by using a token which is the same as in my national number application through the topicKey when the employee sends to the user or I already created the topicKey for the user when he is in the process of registering in the application which is the national number.
When the employee accepts the user’s request, add the order number to the topicKey, which is the national number.
In your problem you can use the phone number because it is a unique code and create a topicKey based on it.
I hope I understood your problem correctly and I apologize for the spelling errors because it is not my native language.
Related
I am using OneSignal to send notification and I was able to send a notification successfully but now I want to send them to a specific user
or users I know I can create a segment to identify these users but
let say I have a segment for company A and another for company B
how can I add a new user to that segment.
so, in short, this is how the idea in my mind works in my DB I have users that belong to company A and another to company B they open the app and subscribe now how I give them a key to identify them do I send the key from my application or I store it in my DB?
The ability to set data tags is incredibly powerful. You can store data attributes on each user. Tags are available on all OneSignal accounts and are a very popular feature among our customers. Users are tagged with attributes such as types of messages they want to receive, content categories, cart abandonment info, subscription status and user-preferences.
Read more on data tags here.
We have more details in our blog post on data integration with OneSignal
I'm working on a new app and I want to give the possibility to my user to use more then one device.
The app can receive push notification, my question is how to save more device/token for each user, this for send push notification to all the user's devices.
My idea is to retrive "some device ID" and then store a id/token for each device but I don't know which device ID I can use...
Another idea is to create a random id the first time and then send this id with token, this work (partially) until the user clear application data...in this case I need to resend a new id (no problem) but I can't know if I can remove the old id/token
any solution?
You don't need "some device ID"; the push token is the device ID. You need to ensure that your backend database can associate more than one push token with a given user account. This is typically through a one->many relationship between user "users" table and your "installations" table.
You can't rely on your app to tell your backend to remove an old token, since the user may simply delete your app and it doesn't get a chance to communicate with your back-end.
The APNS service will deliver feedback as to which push tokens were invalid (I assume that the equivalent Android service also has something like this). You use this feedback to purge invalid installations from your installations table.
I am trying to create a android messaging app using MQTT.
But i just want to know how the existing messaging apps(based on MQTT) work?
I am think of creating a unique topic for each user who installs and setups the app for the first time (providing his mobile no/email id for his topic to receive messages from others).
Once the setup is completed the contacts from users device will be synced with my server to check the available users.
And finally the user can select from the available contacts to send messages(publish messages based on the selected contacts mobile no or email id).
I know we should encrypt the contacts to protect the users privacy but,
Am i going in the right direction?
Thanks in advance.
Typically you set up a topic like
appName/device/[deviceID]
you could then put additional topics under that, like
appName/device/[deviceId]/contacts/contactName
You would then create authorization rules that limit a device to only publish things to appName/device/[deviceId]/# for the specific device id.
You could do a topic like appName/device/[deviceI]/contacts/online to get a list of available contacts... and a reply topic that gave back the results.
I am learning how to implement the GCM both from client side (Android) and from server side (ASP.NET). I spent a bit of time on reading the whole google documentation related to GCM and I also tried the sample that they provided.
Because I need to integrate the GCM in an already existing app, I would like to know some specific stuff.
As I got it, the registration id is a token which ties the app on a specific device to the GCM service and the app server; so, the backend can send downstream messages directly to that device.
In my scenario, I could have multiple users who can use the app on the same device, that means they need to login in the app and they have an account on a database in the server side. Do I need to store a different registration id for each user on that device? Or still the registration id refers to only the app?
And what about the same scenario but distributed on multiple device, because a user can have multiple devices?
Thanks in advance.
This relates a lot to the context of your app and what you want to do with notifications
Having one registration ID per device will be okay.
I manage my multiple users by using subscription tags handled by my server.
So take the scenario if you have a sports app:
User A & User B share the same device. Each user subscribes to a tag.
User A is subscribed to two tags (Basketball & Football)
User B is subscribed to two tags (Tennis & Basketball)
When User A logs out you clear the tags associated with that user and when User B logs in you fetch his/her tags.
Your server knows notifications to send to the device based on the tags the user has subscribed for.
Multiple device scenario:
The same goes, when your user logs In you get their tags. The device also has its own token from GCM.
The registration id is the app's id, it may be changed if app version was updated. Your push notification will be sent on device with your app, regardless user account. So every user on every device will receive your notification, you must store only one refistration id per device.
For multiple users: If your messages are user specific, you would want to retrieve the user's token and subscribe to it only while they are logged in. When you switch users remove/unregister the previous token, then save/register the new user's token.
You should not only do this if you have multiple users per device, but when a user signs out. This will prevent user-specific messages being shown at wrong times to wrong users.
For multiple devices: it sounds like you are looking for Device Group Messaging.
With device group messaging, app servers can send a single message to multiple instance of an app running on devices belonging to a group. Typically, "group" refers a set of different devices that belong to a single user.
This is also nice because of the collapse_key. When one of the devices on the same account opens a notification, it will dismiss the notification on the other devices..
I'm implementing a GCM handler on my server. Does Google issue a new Registration ID per device or per user? I know they issue a new ID per App version and user, but does that extend to each device the user has the app installed on?
Ultimately, I ask because I want to know how I should store a Registration ID a user's app sends me server-side.
Right now I have it implemented such that the most recently sent ID is the user's only Registration ID, but I am unsure if this is an incorrect way to model how GCM handles registration IDs. I'm leaning towards it being incorrect and that I'd have to keep a record of many IDs based on some criteria.
Any input would be appreciated.
Basically, GCM issues a new registration ID per device with the app installed. To answer your question, 1 registration ID per device.
GCM does not know anything about your own users, so it is up to you to implement the logic of how to sift through messages intended for User X and Y, if both of them use the same device.
Here's something from the docs:
A registration ID isn't associated with a particular logged in user. If you unregister and then re-register, GCM may return the same ID or a different ID—there's no guarantee either way.
To make sure that messages go to the intended user:
Your app server can maintain a mapping between the current user and the registration ID.
The app can then check to ensure that messages it receives match the logged in user.
The whole "matching" concept in the last bullet is what I meant by sifting through.
It is issuing an ID that depends on both. If the user changes on a specific device, the ID will change and vice versa. Also a user can have more devices and on each device the ID differs. But you should know that google has a limitation of how many devices each user can have, last time I checked it was 10.
You should also be checking the result the GCM server returns, it will tell you if the ID is dead and you can remove it from your database.