A common library would definitely be the way to go here then, added it to my todo-list.
I don’t know how much you have looked at the RuuviCollector sources, but I was thinking about refactoring (and renaming) so that there would be an “extra layer” between the HCIData output from HCIParser and the actual DataFormat parsers (implementations of BeaconHandler, to be renamed to RuuvitagParser or something?) so that the parsers would just receive the raw payload (ie. the eddystone packet which includes the eddystone url, or the raw manufacturer specific data used by the RAW data formats) as a
byte data array.
This extra layer would then be RuuviCollector specific and contain the HCIData to data mapping as well as the shouldUpdate() logic currently present in the parsing classes (that logic shouldn’t even be there in the first place…)
That way the common library would offer parsers that simply accept a byte array as a parameter and produce a RuuviMeasurement object as output. Any comments? (anyone else may comment as well, of course)
I don’t think it would make sense to include the HCIParser itself in the library, especially considering I’m working on getting rid of the hcitool and hcidump dependencies as they’re getting deprecated due to the lack of maintainers.
It’ll be probably late next week or something before I have time to get all this done, especially since I need to figure out the necessary requirements and steps for publishing libraries to eg. maven central.