Trying to recall why we didn't want a GCM static dependency

[inlined]

I started working on ParseServer #1369 and was trying to implement this the same way as we did v3--without any compile-time dependencies on the GMS library.

Between GCM v3 and v4, things have become much more sophisticated. Now there's the InstanceId API, which is basically OAuth for the device instead of the user. If you want to send a GCM message to that device, you get the device to issue a "GCM" scope token. If I write this all from scratch, I'm going to have to write compatibility shims for Messenger on older platforms, manage crypto keys, sign values, etc. There's a very non-zero chance I'll get some of this wrong, so I wanted to revisit our decision to not depend on the GMS libraries.

The two reasons I can recall are portability or file size, but neither of those are really valid. The GMS client libraries are themselves weakly bound to underly GMS service. It's actually totally possible for Fire Phones to implement some of the same services (though the client Android Manifest would have to explicitly trust the package name). The file size issue doesn't seem to be a big deal anymore either since we could require just com.google.android.gms:play-services-gcm:8.4.0

Side Note: With the GCM v4 upgrade, we might also want to consider using the device's Instance ID as the ParseInstallation.installationId for better record stability (since installations are already upserted by that field). I don't recall if there's still regexes anywhere that expect that to be a UUID though.

[grantland]

IIRC the main reason was not wanting to break backwards compatibility. Developers who aren't using Maven will have to manually add another dependency or else they'll hit compile/runtime failures.

Aside from that, we didn't want to force developers to add unnecessary dependencies if they aren't utilizing GCM. This is especially annoying if this puts a developer over the dex limit and they have to deal with implementing multi-dex or having to wait for proguard stripping on every build.

We had discussed this many times and our ideal implementation was a fully decoupled shim library, similar to how we open sourced ParseFacebookUtils and ParseTwitterUtils. This would allow us to utilize the GCM library as well as solve the problems outlined above, however it was never much of a priority since it wasn't broken.

I had many conversations about fully decoupling our SDKs with @nlutsenko, @wangmengyan95, @richardjrossiii and @bnham, and maybe they can fill in any gaps that I forgot, but here is what I remember:

• Creating GCMUtils or something that would be shim between Parse-SDK-Android and play-services-gcm.
• Implementing a third ProxyService and leaving GCMService untouched so that we can maintain backwards compatibility for developers who don't want to go the extra mile to add the GCM dependency.
• Publicizing necessary ParseInstallation properties so that any push shim, including GCMUtils, can access and modify.
• Decouple push registration from Parse#initialize() into GCMUtils.

[bnham]

It was because we added GCM before Android Studio and Gradle usage was widespread. Our SDK was just a jar file with no dependencies (this was before Bolts was split out) and we didn't want to add a dependency or force people to declare dependencies using Gradle or another build system.

[Jawnnypoo]

With the pulling out of the GCM module, it now uses the dependency