Closed rwoberholzer closed 7 years ago
Is this a regression? It would be great if we could have a unit test for this if we don't already - if we do, I wonder why it didn't catch it?
I think your bugfix is fixing the problem at the wrong stage in the pipeline - we control the objects that are being serialized, so we should be using the options in the serializer to mark which fields should and should not be included.
I think the mKey field is from the KeyedMessage base class. There are a few suggestions for how to include or exclude fields from a class when serializing with Gson in this SO thread: http://stackoverflow.com/questions/4802887/gson-how-to-exclude-specific-fields-from-serialization-without-annotations
Thanks Chris, this is a much cleaner and robust solution. I appreciate the help! See commit be3f992.
When recording a trace using the enabler app, an mKey object is added to the message, which should not occur:
{"value":true,"name":"headlamp_status","mKey":{"mHashCode":1590871281,"mParts":{"name":"headlamp_status"}},"timestamp":1468518297318}
The correct output should like similar to this:{"value":true,"name":"headlamp_status","timestamp":1468518297318}