I want to register my app for GCM services just after the user installs my app(i.e. before launch). Is this possible? Or else is there a hack available.
If you want follow the standard GCM client app registration process, your app has to launch in order register, because the app server and the client app must complete a client/server "handshake."
From the GCM documentation, it states that the client obtains a unique registration token and passes it to the app server, which stores the token and sends an acknowledgement back to the client app. The registration token exchanged in the handshake process is the same client app instance identifier used subsequently to send messages to the client.
so, if your app is not launched, you can not pass the registration token to the app server. For android, you need to use the Instance ID API to complete the process.
Sample code:
InstanceID instanceID = InstanceID.getInstance(this);
String token = instanceID.getToken(getString(R.string.gcm_defaultSenderId),
GoogleCloudMessaging.INSTANCE_ID_SCOPE, null);
(notice the R.string.gcm_defaultSenderID is a project number you acquire from the API console. )
There was a hack in this post, if you want to start a service after an app is installed. But it might not be a good practice for you to complete the registration process, because you hard code the Sender ID, Application ID and Sender Auth Token listed in this page.
Related
I'm trying to verify Firebase App Check tokens on my custom backend. Everything is fine so far, but there's one thing I'm not sure about: My backend is hosted on a private network therefore I need to know if grabbing key sets from https://firebaseappcheck.googleapis.com/v1/jwks is the only necessary outgoing HTTP request involved in the verification process.
The answer is "Yes" according to https://github.com/firebase/firebase-admin-node/issues/2014#issuecomment-1353472578
Obtaining the Firebase App Check public JSON Web Key Set is the only outgoing request for the app check verify token API. The SDK might make other http calls during the initialization based on your environment (obtaining the service account or credentials etc.) or if you use other APIs in combination with the App check token verification.
The rest of the JWT verification happens all offline. We also cache the public keys (JWKS) for up to 6 hours, so if your environment doesn't lose its state then the outgoing request to fetch the keys should not happen (if the keys are cached) every time you call the API.
I have migrated data from an app to another on Cloud Firestore, but the new deployment on the new app can't access the data on it.
I checked the config object and all the properties refer to the new app on Firebase.
Is the missing thing a kind of a link/glue between the running web app and Firestore?
According to the ErrorCode list (HTTP error code = 404), the App instance was unregistered from FCM. This usually means that the token used is no longer valid and a new one must be used.
This error can be caused by missing registration tokens, or unregistered tokens.
Missing Registration: If the message's target is a token value, check that the request contains a registration token.
Not registered: An existing registration token may cease to be valid in a number of scenarios, including:
If the client app unregisters with FCM.
If the client app is automatically unregistered, which can happen if the user uninstalls the application. For example, on iOS, if the APNS Feedback Service reported the APNS token as invalid.
If the registration token expires (for example, Google might decide to refresh registration tokens, or the APNS token has expired for iOS devices).
If the client app is updated but the new version is not configured to receive messages.
For all these cases, remove this registration token from the app server and stop using it to send messages.
I'm reading through FCM token management best practices in the documentation (https://firebase.google.com/docs/cloud-messaging/manage-tokens) and have the following questions.
On initial startup of your app, the FCM SDK generates a registration
token for the client app instance... your app should retrieve this
token at initial startup and save it to your app server alongside a
timestamp.
Is the recommendation here to handle the token on app launch or just the first time the app is launched on install? Because I can't imagine given how many server interactions there are in the typical life of a client process that we wouldn't just update the token every time the app is launched and call it a day instead of creating additional tasks to keep these tokens fresh.
We recommend that you periodically retrieve and update all registration tokens on your server.
Is the recommendation here to null stale tokens?
We recommend that you periodically retrieve and update all registration tokens on your server. This requires you to add server logic to update the token’s timestamp at regular intervals, regardless of whether or not the token has changed.
I don't understand what this means. Is the recommendation here to task the server with updating a token's timestamp? What does this accomplish? And is the server capable of generating a token for a client?
According to the docs, as I understand, you have to :
On client side :
Store the token on your server on first launch (your server will consider that your token is valid for 2 months)
Update your token on server if it changes
On server side:
When a new token is registered store the token in your database and set his validity for 2 months (if the token already exist in your database then just reset his validity for 2 months again)
When a notification send fails, then remove the invalid token from tour database
Periodically (monthly suggested), validate all tokens and reset their validity date if valid (delete if not).
The token is generated only when you first launch the app after install, and in some reset events. So your token will stay mostly the same, it won't change in every app launch. The timestamp is what the server will check. Maybe this will help:
First Launch
Token generated, send to the server with timestamp
Regular Launch
Token retrieved(same token), send again to the server periodically (2 Months?)
Now, this is where it gets hazy. As far as I understand, the server should signal the app in some way to get the token again (even if it is unchanged) to refresh the token in the server database and then refresh the timestamp.
I'm trying server side to invalidate a registration token forcing the client app to request a new token.
Reading the docs:
The InstanceID is long lived, but may expire for the following reasons:
Device factory reset.
User uninstalls the app.
User performs “Clear Data” in the app.
Device unused for an extended period (device and region determines the timespan).
Instance ID service detects abuse or errors and resets the InstanceID.
Server-side code if your client app requires that functionality.
https://developers.google.com/instance-id/reference/
Whats the server side code that allows me to invalidate or force the expiration of the token ?
Thanks.
For example, using the google API:
https://iid.googleapis.com/iid/info/token?details=true
When doing a 'get' over that endpoint I get information of the token. When was created, in what platform is running, and what are the topics registered for that token.
I would like through the API make that token invalid.
Is this possible ?
I am making use of microsoft push notification service to push notification from a web service to windows phone app. My doubt is that , how will i pass the message to mspn service (end point)? will we receive any information while we register app to mspn service?
Setting up push notifications has several steps, and to paraphrase the Push Notifications Overview for Windows Phone on MSDN:
Your application registers for push notifications via an instance of the HttpNotificationChannel class
The instance of HttpNotificationChannel does the negotiation with MPNS
Assuming step (2) was successful, the instance raises the ChannelUriUpdated event
You pass the URI in the ChannelUri property to your web service (along with whatever metadata you need to identify what push notifications should be sent to that URI)
Your webservice issues a POST request to the URI passed to it in step (4), with the relevant XML as the message body (that XML will change, depending on the type of notification you're trying to send)
The MPNS servers send that notification to the phone, which will update the Tile, show a Toast notification, or, if it was a RAW notification and your application is running, the HttpNotificationChannel object created in step 1 will raise the HttpNotificationReceived event.
To summarize, and directly answer your question, the endpoint is the URI from the ChannelUri property of your HttpNotificationChannel instance