Feature Request: Cloud Message Logging

[mandrachek]

I currently have to log FCM messages for debug builds of my application. It would be great if I could offload this responsibility to chucker. Perhaps by supporting an additional data type that would result in a 3rd tab, "Messages" or "Data" or something along those lines, that I would then be able to call in my FcmMessageReceiver implementation's onMessageReceived handler to be able to pass the message into Chuck for logging.

I don't expect you'd want to add a dependency on the FCM libraries, but supporting most of the values in the RemoteMessage class would be great. The only one that would be mandatory would be the data (Map<String,String>), and the current timestamp.

Something like:

  @Override
  public void onMessageReceived(RemoteMessage remoteMessage) {
     chuckerCollector.onMessage(remoteMessage.getData());
  }

or:

  @Override
  public void onMessageReceived(RemoteMessage remoteMessage) {
     chuckerCollector.onMessage(
       remoteMessage.getData(),
       remoteMessage.getFrom(),
       remoteMessage.getTo(),
       remoteMessage.getMessageId(),
       remoteMessage.getmessageType(),
       remoteMessage.getSentTime(),
       remoteMessage.getTtl()
    );
  }

This or something like it could be useful to a lot of people, even if they're not using it for cloud messaging.

[ColtonIdle]

This is interesting. I really like keeping Chucker to just network traffic, but I guess one could argue that this is a form of network traffic. The same feature framework being discussed in #100 could maybe be used here as well?

[psh]

Going with the open-closed principle for a moment, the core of Chucker is the ability to monitor HTTP traffic. Hopefully the core of Chucker being closed for modification but open for extension would allow for adding nuances (like graphql, websockets or FCM messages) without core classes being modified.

Square's Retrofit handles this by having external modules act as Converter Factories and Call Adapter Factories where these external modules are dependent upon Gson, Moshi, Jackson, RxJava, etc. The core of Retrofit doesn't need to be modified when the next body encoding mechanism comes along. Would a similar approach work here?

[cortinico]

Would a similar approach work here?

Absolutely. Ideally having ChuckerCollector and ChuckerInterceptor as extensions point could allow to extend the behavior of Chucker to support new features.