Closed GoogleCodeExporter closed 9 years ago
The GCMConstants define a suffix for the intent service, which is appended to
your app's default package.
If you need a different class name or package, you must extend
GCMBroadcastReceiver and override the getGCMIntentServiceClassName() method to
return the desired FQCN (Fully-Qualified Class Name).
If you have an user case that is not covered by this approach, please let us
know.
Original comment by felip...@android.com
on 23 Jul 2012 at 4:14
Check this code.
http://code.google.com/p/gcm/source/browse/gcm-client/src/com/google/android/gcm
/GCMRegistrar.java#285
Inside GCMRegistrar class, it uses GCMBroadcastReceiver directly.
so I think erkasrim's patch is reasonable. Is'n it?
Original comment by skyi...@gmail.com
on 24 Jul 2012 at 1:56
Thank your answer.
I know your suggest
But!!! It is include bug!
Show this code
<GCMRegistrar class code>
public static void register(Context context, String... senderIds) {
setRetryBroadcastReceiver(context);
GCMRegistrar.resetBackoff(context);
internalRegister(context, senderIds);
}
private static synchronized void setRetryBroadcastReceiver(Context context) {
if (sRetryReceiver == null) {
sRetryReceiver = new GCMBroadcastReceiver();
String category = context.getPackageName();
IntentFilter filter = new IntentFilter(
GCMConstants.INTENT_FROM_GCM_LIBRARY_RETRY);
filter.addCategory(category);
// must use a permission that is defined on manifest for sure
String permission = category + ".permission.C2D_MESSAGE";
Log.v(TAG, "Registering receiver");
context.registerReceiver(sRetryReceiver, filter, permission, null);
}
}
register method is always call setRetryBroadcastReceiver
and setRetryBroadcastReceiver method is create the GCMBroadcastReceiver !!!
Look this is my AndroidManifest.xml file! and Custom GCMBroadcastReceiver class
I do not want define 'GCMBroadcastReceiver' in my AndroidManifest.xml file
<!-- using GCM service -->
<service android:name="net.daum.mf.push.gcm.GCMIntentService" />
<receiver
android:name="net.daum.mf.push.gcm.DaumGCMBroadcastReceiver"
android:permission="com.google.android.c2dm.permission.SEND" >
<intent-filter>
<action android:name="com.google.android.c2dm.intent.RECEIVE" />
<action android:name="com.google.android.c2dm.intent.REGISTRATION" />
<category android:name="net.daum.mf.push.sample" />
</intent-filter>
</receiver>
public class DaumGCMBroadcastReceiver extends GCMBroadcastReceiver {
private static final String TAG = "GCMBroadcastReceiver";
@Override
public final void onReceive(Context context, Intent intent) {
Log.v(TAG, "onReceive: " + intent.getAction());
String className = getGCMIntentServiceClassName(context);
Log.v(TAG, "GCM IntentService class: " + className);
// Delegates to the application-specific intent service.
GCMBaseIntentService.runIntentInService(context, intent, className);
setResult(Activity.RESULT_OK, null /* data */, null /* extra */);
}
/**
* Gets the class name of the intent service that will handle GCM messages.
*/
protected String getGCMIntentServiceClassName(Context context) {
return "net.daum.mf.push.gcm.GCMIntentService";
}
}
You know, an exception is raised!!!
And then, I need 'setGCMIntentServiceClassName' method!!!
Original comment by erkasr...@gmail.com
on 24 Jul 2012 at 2:18
GCMRegistrar uses GcmBroadcastReceiver directly because it uses it to handle
the retry logic. If you extend that class, your "main" receiver will be an
instance of the extended class, while the "retry" broadcaster will be an
instance of the base class, which is fine. Even if you don't extend it, there
will be 2 instances anyways, as they require different permissions.
So, I still don't see the point of this patch. We could split the receivers in
2 classes to make it clearer, but the overall code would be more complicated.
Original comment by felip...@android.com
on 24 Jul 2012 at 2:58
Inside 2nd instance of GCMBroadcastReceiver, it delegate intent to
DEFAULT_INTENT_SERVICE_CLASS_NAME.
if DEFAULT_INTENT_SERVICE_CLASS_NAME not exist, it will crash.
I think he want use his own service class name instead of
DEFAULT_INTENT_SERVICE_CLASS_NAME
Original comment by skyi...@gmail.com
on 24 Jul 2012 at 3:41
Ah, ok, makes sense, thanks for the clarification.
I will try to fix it without requiring a new method.
Original comment by felip...@android.com
on 24 Jul 2012 at 6:15
Fixed on
http://code.google.com/p/gcm/source/detail?r=8094cc6410b7dc2db452eb19cc9274fda1b
2d6a2 , will be available in the next release.
Please note that the new methods are used internally so this fix won't require
any change in the apps.
Original comment by felip...@android.com
on 27 Jul 2012 at 4:05
Thanks~!!!
Original comment by erkasr...@gmail.com
on 30 Jul 2012 at 6:35
Original issue reported on code.google.com by
erkasr...@gmail.com
on 23 Jul 2012 at 8:37