I have my app running on a Nexus 5 (Marshmallow) which has 2 active registration ids. Just want to know if that is normal by GCM behavior?
Here's how it's causing me trouble:
Android M has come up with Group permissions - which means the user chooses whether or not he wants the app to have access to his device identifiers (Android ID). Let's assume he denies it and I can't identify the device. The way my app functions is that a user can log in from multiple devices, all of which remain in sync. Because a user can be on mulitple devices, I must handle multiple registration IDs to send push messages (and I cant be sure of the number of devices the user is on, as they can deny providing the device identifiers). This means that I cant delete/update any registration ids on the server side, but only send every push message to all recorded IDs against a user, in the hope that all the devices on which that particular user is signed in will receive the messages.
Because I have a device which has two active registration IDs, I am getting 2 notifications for everything.
On the client end, we were noticing frequent changes in the Registration IDs, we have a class that keeps generating registration ids and updating the server.
Having multiple registration Ids can be a bug in the client app (which you have to deal with).
And the only way to ensure that there will only be one notification being sent per device is to implement canonical IDs on the server side. It is included in the webservice response as "canonical_ids".
Canonical IDs
If a bug in the client app triggers multiple registrations for the same device, it can be hard to reconcile state and the client app might end up with duplicate messages.
Implementing canonical IDs can help you more easily recover from these situations. A canonical registration ID is the registration token of the last registration requested by the client app . This is the ID that the server should use when sending messages to the device.
If you try to send a message using an old registration token, GCM will process the request as usual, but it will include the canonical ID in the registration_id field of the response. Make sure to replace the registration token stored in your server with this canonical ID, as eventually the old registration token will stop working.
Here is a related issue
android GCM get original id of canonical id which tackles how canonical ids work in the actual code
Related
So, I have an App where the user needs to sign up to access the app. I'm planning to run an offer where user can order that item only once in a day. But I have the doubt that he may change login Id (if have multiple emails) and can place the order with Different ID's.
I'm thinking of registering the device with an email id:
Pros: - Not able to login with a different email Id.
Cons: - Not able to use the app on a different device ( if changed) as it may give an error email Id already registered with another device.Which leads to deregister from the previous device (Chances device may not be available).Or raise a ticket which is time-consuming. this may lead to customer loss.
Have also, read about IP tracking, Phone number, and Credit card details but not satisfied with the answers (somebody already raised for same). So what will be a good method to avoid multiple logins/sign up from the same device?
You can get the MAC adress from device using WifiInfo.getMacAddress()
I am working on a web application which is based on Google App Engine (GAE). The requirement of the application is that one user can be associated with multiple company accounts.
My application has two main types of accounts. One is that main Admin/Company account. Other is the employee account (i.e. the persons who work under a company). Now, what I want to do is that to allow an employee to work under more than one companies, but he does not have to make a separate account for each company. His single account can be associated with multiple companies.
I have explored different platforms which are already supporting this feature. The major ones which I found are Slack and Asana. And my problem can be perfectly mapped to what Slack is doing right now i.e. I create a single account on Slack and I can join multiple workspaces on Slack using this single account.
I want to achieve the same in my application too. I am curious that how Slack is supporting this feature right now? Does it send some ID with every request to the server which indicates that the activity which just has been done is associated with the workspace under this ID? Or there is some unique sort of token associated with every workspace (on Slack API level)?
I do have such a model in my app. A unique auth_token is associated with every company account. So, I am thinking that when an employee wants to do an activity for a specific company he will send this unique token with the request to the server so that server knows for which company the activity was performed.
Does anybody know what is the best way of achieving this?
There are two different concepts at work here:
Relation between account and company / workspace
The data structure for the Slack account is designed such that it can be linked to multiple Slack workspaces, e.g. in SQL you would have a many-2-many relation between the accounts and the workspaces table.
Staying logged in
The way Slack and others Single-Sign-On provides like Google SSO keep you logged in is by settings a browser cookie. That cookie would usually be some kind of crypto hash and the SSO provider will use it to identify to which account the current user belongs to or to request a login via OAuth if the cookie is missing / invalid.
This can also be achieved partly with server sessions (which also uses cookies). Using server sessions is easier to implement than implementing your own (secure) cookie solution, however the user will only stay logged in as long as the browser stays open. But that should be sufficient for most solutions.
Note that tokens for the Slack API work very differently. e.g. they have to be generated per workspace, user and app.
I have my push notifications working fine for my mobile Android app
through GCM, but have a specific question about my environment. My
app would like to be able to receive pushes potentially from more than 100
senders (servers) and the comments (see below) in the documentation confuse me.
Basically consider this situation...
I registered my project on the Google Dev Console and obtained my
project number (aka - sender ID) and my server key. For the latter
I did NOT specify specific IP addrs.. just left the field blank.
My app boots and does a "register" with this one single sender ID
and receives the registration key.
I send this registration key to my 500 "source" servers, and these servers also
have the SAME server key.
So again to summarize... my 500 servers that want to send pushes to the phone would
ALL be using the SAME server key and the SAME registration ID.
Simple question.. is this allowed? If so, what do all the restriction warnings mean
(below) from the GCM docs.... and if not allowed, I want to understand technically
why this is not allowed.. for example, does the GCM server monitor and keep
track of server keys and the source IP they are from?
Thanks so much - been searching for days and cannot get a real hard answer
I feel I can trust. My whole development project design hinges on the truth in
this matter - ha ha !
Receiving Messages from Multiple Senders
"GCM allows multiple parties to send messages to the same application. For example,
suppose your application is an articles aggregator with multiple contributors, and
you want each of them to be able to send a message when they publish a new article.
This message might contain a URL so that the application can download the article.
Instead of having to centralize all sending activity in one location, GCM gives you
the ability to let each of these contributors send its own messages.
To make this possible, all you need to do is have each sender generate its own project
number. Then include those IDs in the sender field, separated by commas, when requesting
a registration. Finally, share the registration token with your partners, and they'll
be able to send messages to your application using their own authentication keys.
Note that there is limit of 100 multiple senders."
or worded another way in some other doc ....
Receiving Messages from Multi-senders
"GCM allows multiple parties to send messages to the same client app. For example,
suppose the client app is an articles aggregator with multiple contributors, and
each of them should be able to send a message when they publish a new article. This
message might contain a URL so that the client app can download the article. Instead
of having to centralize all sending activity in one location, GCM gives you the ability
to let each of these contributors send its own messages.
To make this possible, make sure each sender generates its own sender ID. See the
client documentation for your platform for information on on how to obtain the GCM
sender ID. When requesting registration, the client app fetches the token multiple
times, each time with a different sender ID in audience field.
Finally, share the registration token with the corresponding app servers (to
complete the GCM registration client/server handshake), and they'll be able to
send messages to the client app using their own authentication keys.
Note that there is limit of 100 multiple senders."
and even in some register code I saw.....
chrome.runtime.onStartup.addListener(function() {
chrome.storage.local.get("registered", function(result) {
// If already registered, bail out.
if (result["registered"])
return;
// Up to 100 senders are allowed.
var senderIds = ["Your-Sender-ID"];
chrome.gcm.register(senderIds, registerCallback);
});
});
I'd like to develop a tracking system using an API of course (like the famous Orange API).
the idea is simple:
I send a SMS (from my Web interface) to the person i want to track
The person's mobile terminal (GPS like this) send me back automatically
the coordinates by SMS.
The sent information are displayed on the user's web interface.
The questions are simple:
How the terminal can send automatically the response?
How to indicate in the message that the information is for "user4655"?
How to make connection between the information and the database?
Thanks,
Regards.
* How the terminal can send automatically the response?
Ans: You set the gateway and the time intervals you want the device to send the sms to on the device itself.
* How to indicate in the message that the information is for "user4655"?
Ans: The gateway you use will have the API to determine that the number it is sent from. The device will use a registered phone number from either a sim or enabled by one of those cell providers.
* How to make connection between the information and the database?
Ans: I dont understand this. But I'm guessing you will have a database to keep track of the user data. You'll just probably need another table that is a child of the user, which has a list of the data and the time they came in.
I am developing an application in which I want to use push notification service. I have a server, now I want to know that
How do I handle multiple devices?
Is there a unique device id/name for every iphone?
Suppose I want to delete request for a specific device token, so how do I handle multiple users?
Is there a way I can generate unique name for every device through application?
You should really read the APNS documentation, this is all explained in depth there.
The short answer is that when you launch an app on the phone it requests a push notification key from the OS. You then take that key and send it back to your server. Your server uses that key when it sends a push via Apple's servers to indicate the devices to send the push out to.
The service just gives you a token. If you want accounts or device names you need to come up with them and store them with the credentials on your server.
You handle multiple users by same way you handle single users, you send message with the appropriate key to the service.
As for deleting a request, you can't. It is like a text message, there may be some latency before hits the device, but the moment you commit the push it could be delivered instantly.