search

drbild / c2dm4j

[UNMAINTAINED] A Java library for implementing the third-party application server component of the Android Cloud to Device Messaging (C2DM) framework.
Apache License 2.0
10 stars 0 forks source link

C2DM service deprecated by google #4

Open ochan opened 12 years ago

ochan commented 12 years ago

Hi,

The c2dm service has been deprecated ( https://developers.google.com/android/c2dm/ ). Do you have any plans to support the new service GCM ( http://developer.android.com/guide/google/gcm/index.html ) ?

Thanks so much for this library. The implementation is very elegant.

drbild commented 12 years ago

I do plan to support GCM, probably under a new name like gcm4j. I'll update the c2dm4j README with a link when that's released.

It'll take me a week or two to do the initial updates. I looked over the GCM spec last weekend, and it shouldn't affect the core of the library much. The primary changes will be (1) additional options for the data sent to GCM, (2) a few extra response/error types, (3) a new authentication method, and (4) handling the updated client identifiers returned with the responses.

nfranke commented 12 years ago

+1 on this. I've written my server using C2DM4J and now I see that it's deprecated. I'd love to be able to move to GCM2J soon. I think that the collapse key is now optional, too.

nfranke commented 12 years ago

OK, I've pretty much finished porting this to GCM. Let me know if you'd like what I did, if you haven't started yet.

ochan commented 12 years ago

Hi drblid, do you have any news from the GCM support? have you start?

Dao007forever commented 11 years ago

Hi drblid, what is the status of the new GCM lib?

Dao007forever commented 11 years ago

@nfranke : Can you upload your port to a github repo? We kind of need it since our C2DM suddenly stopped working. Thanks!

drbild commented 11 years ago

We stopped using C2DM/GCM for our product, so I haven't been able to officially spend anytime on this and I'm currently in the midst of trying to finish my dissertation.

If @nfranke can post his port, that should work at least for the features carried over from C2DM.

Handling the submission of multiple client recipients per GCM request requires some changes to the API (at the last time I worked on this, I was still floating around several APIs for this. None of them felt quite right to me) and so will be a bit more work. But if you just need to restore your C2DM functionality, that's not a problem.

Dao007forever commented 11 years ago

Thanks, drblid. Good luck to your dissertation :). Waiting for nfranke's port :D.

drbild commented 11 years ago

@Dao007forever, out of curiosity, has Google shutdown C2DM for good? I thought it was still functional for existing users.

Dao007forever commented 11 years ago

Oh, it's not, my email was deleted by the IT guy and when he restored it, I can still generate token, the push succeeds but there was no message. I guess when it was deleted, the removed the authentication for pushing.

nfranke commented 11 years ago

I might as well spin off a new github project for this.

nfranke commented 11 years ago

This is my first github project, so bear with me. I've checked what I'm using, after renaming the package.

https://github.com/nfranke/gcm4j

drbild commented 11 years ago

Great. Thanks much.

Dao007forever commented 11 years ago

@drbild I'm implementing the multiple registration_ids for the gcm4j and reading through your code. I wonder if the GlobalBackoff and DeviceBackoff is wrong in the updateDelay() method?

We should get the Attempt from the context and update the delay according to that Attempt, but you created a new Attempt every time, is there a reason for that since I'm not familiar with this flow of code (it's quite OS-like type of logic, where did you get those Context styles from?)

@nfranke What do you think?

I'm sorry if you found an email with this same content as I realized that you graduated and the email might be invalid so I post here.

drbild commented 11 years ago

@Dao007forever I believe the code is correct.

The Attempt objects are immutable and essentially stateless. The actual current state of the backoff (i.e., the next delay) is maintained in the Backoff object (see AbstractThreadSafeBackoff). Creating a new Attempt is correct and safe.

Attempt is mainly just a callback interface, providing a way of emulating something like lambdas and closures in Java. The recordSuccess() and recordFailure() are the callbacks. It also holds references to the state of the Backoff at the time the Attempt was created (essentially closing the callback over that particular state). Why do this? To allow multiple in-flight attempts (e.g., for GlobalBackoffThrottle, which is handling multiple concurrent attempts). When the recordSuccess()/Failure() methods are called, Backoff verifies that the State in the attempt matches the current State, before updating the state. If it doesn't match, it means some other newer Attempt has already updated the state and thus this one shouldn't.

I did get your other email, but this issue tracker is better anyway, because it's publicly visible.

(I'm not sure where I got the Context style from. It (or similar styles) are fairly common in a variety of open-source projects I've looked at over the years.)

drbild commented 11 years ago

FWIW, the use of immutable State and Attempt objects leads to a lot of garbage collection churn, which might be a problem in some use-cases. But for what I was doing, GC wasn't an issue and the bug reduction afforded by immutable objects was desirable.

Dao007forever commented 11 years ago

@drbild Thank you for your explanation, it becomes clearer now :+1:.

drbild commented 11 years ago

@Dao007forever Glad to help. I'd love to see gcm4j support the new GCM features (and I wish I had the time to help make that happen!).