This repository has been archived by the owner on Sep 7, 2022. It is now read-only.
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
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?
- Loading branch information