You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Sep 7, 2022. It is now read-only.
This change:
----------
* Moves Parse back to using public APIs (open [GitHub discussion](ParsePlatform#445))
* Cleans up a lot of code in `GcmRegistrar` that is redundant with GCM APIs or written before Bolts
* Fixes a typo in manifest instructions that used a literal `bool` instead of `"bool"`
* Fixes a bug where ParseInstallation did not save the GcmSenderId, causing Parse to not use the developer's secrets.
* Fixes a bug where Parse incorrectly blames a manifest error when GCM is unavailable because the device doesn't have Play Services.
* Add a compatibility shim that lets `ParsePushBroadcastReceiver` correctly handle the standard payloads expected by [com.android.gms.gcm.GcmReceiver](https://developers.google.com/android/reference/com/google/android/gms/gcm/GcmReceiver). This lets customers who previously used another push provider use the `ParsePushBroadcastReceiver` instead.
* Add support for GCMv4, including a new optional intent to notify the app when the InstanceID is invalidated.
GCM v4 has a number of benefits:
---------------
* GCM v4 is based on a device-owned InstanceID. Push tokens are oauth tokens signed by the device, so this fixes double-send bugs that Parse Push has never been able to fix.
* If we used the InstanceID as the ParseInstallation.InstallationId, we would also increase stability of the Installation record, which fixes some cases where Installations are wiped & replaced (related to the above bug for senderId stability).
* This API has a callback in case the InstanceID is invalidated, which should reduce client/server inconsistencies.
* These tokens support new server-side APIs like push-to-topic, which are _dramatically_ faster than the normal ParsePush path.
* When a device upgrades to GCMv4, the device keeps GCM topics in sync with channels. This paves the way to implement push-to-channels on top of topics. It also allows the customer to keep some of their targeting info regardless of which push provider they choose to use.
This has two possibly controversial requirements:
----------------
* The new API issues one token per sender ID rather than one token that works with all sender IDs. To avoid an invasive/breaking server-side change, we are _no longer requesting tokens for the Parse sender ID_ if the developer provided their own. We will also only support at most one custom sender ID. I've had a number of conversations about this and nobody seems concerned.
* This change introduces a dependency on the Google Mobile Services SDK. The dependency is just the GCM .jar and does _not_ limit the Parse SDK to devices with Play Services (tested on an ICS emulator w/o Google APIs). I originally tried doing this without the dependency, but the new API has a large amount of crypto and incredible care for compat shims on older API levels. I assume my hand-crafted copy would be worse quality.
Open questions
-----------------
* Should Parse use the GMS InstanceID over the InstallationId when available? This makes the server-side Installation deduplication code work better, but could break systems that assume InstallationId is a UUID.
* Google workflows provide a `google-services.json` file that GMS uses to auto-initialize various Google products (including GCM). Should we allow the Parse SDK to initialize the developer's sender ID with this file in addition to the Parse-specific way?
0 commit comments