Should applications call gcm.register() every seve

2019-01-26 01:52发布

问题:

The client-side code in the GCM example on the Android dev site defaults to calling gcm.register(SENDER_ID); after every seven days by checking if registration has expired using the following function:

public static final long REGISTRATION_EXPIRY_TIME_MS = 1000 * 3600 * 24 * 7;

/**
 * Checks if the registration has expired.
 *
 * To avoid the scenario where the device sends the registration to the
 * server but the server loses it, the app developer may choose to re-register
 * after REGISTRATION_EXPIRY_TIME_MS.
 *
 * @return true if the registration has expired.
 */
private boolean isRegistrationExpired() {
    final SharedPreferences prefs = getGCMPreferences(context);
    // checks if the information is not stale
    long expirationTime =
            prefs.getLong(PROPERTY_ON_SERVER_EXPIRATION_TIME, -1);
    return System.currentTimeMillis() > expirationTime;
}

The comment above the function implies that this is used to "avoid the scenario where the device sends the registration to the server but the server loses it. Is this suggesting that our servers (not the GCM servers) may lose the registration id? Or is this because the registration ID could become invalid on the GCM side of things? It appears that this is possible as per the following paragraph in the GCM Advanced Topics Page:

Similarly, you should not save the registration ID when an application is backed up. This is because the registration ID could become invalid by the time the application is restored, which would put the application in an invalid state (that is, the application thinks it is registered, but the server and CM do not store that registration ID anymore—thus the application will not get more messages).

Thank you in advance!

回答1:

  1. You said:

    The comment above the function implies that this is used to "avoid the scenario where the device sends the registration to the server but the server loses it. Is this suggesting that our servers (not the GCM servers) may lose the registration id? Or is this because the registration ID could become invalid on the GCM side of things?

    I think they are talking about our servers( the 3rd party servers) and NOT GCM servers. The second point will clear that a bit more.

  2. Also, you mentioned that the docs say:

    You should not save the registration ID when an application is backed up. This is because the registration ID could become invalid by the time the application is restored, which would put the application in an invalid state.

    I think If you carefully read the second point under the heading Enable GCM on Architectural Overview page, it says:

    Note that Google may periodically refresh the registration ID, so you should design your Android application with the understanding that the com.google.android.c2dm.intent.REGISTRATION intent may be called multiple times. Your Android application needs to be able to respond accordingly.

    So, Google may refresh he registration ID's periodically. That's why registration ID could become invalid by the time the application is restored.

    So, for handling that you should have a Broadcast Listener which could handle com.google.android.c2dm.intent.REGISTRATION intent, which Google send to the app when it has to refresh the registration ID.

    This also might clear the first point. As this case is handling the refreshing of the ID from Google side, the local 7 days validity will handle the other case of loosing the ID on 3rd part server( as it is being refreshed periodically after every 7 days).

This is my view about your question. Hope this helps.



回答2:

To clarify the 'backup/restore' case: the registration ID is tied to a specific device. If the app is restored on a different device - the previous registration ID still points to the old device, the only way to get messages on the restored device is to get a new registration ID.