Fixed internal datahandling for the avahiclient implementation

[mattes-bru]

Hi Jon,

this patch solves the issue you reported to me by mail. The issue was simply that the internal data, stored in the QMap was never updated with the ip data. For the bonjour implementation there was no such issue. The core implementation (Android?) isn't tested, as I am not having a platform / sdk for this.

I also merged your latest changes and added a debugging output for the QZeroConfService Class, which is already used by the example.

If there are some formatting issues, simply let me know and I'll do my best to fix them. (I had a really hard time to force QtCreator to use tabs instead of spaces)

Regards Matthias

[jbagg]

Hi Matthias, I pulled in the MetaType stuff and your debug stuff. I like it.

QZeroConfService is a read only object (QZeroConf writes, everybody else reads only). I think the QExplicitlySharedDataPointer is the right solution unless I'm missing something. Sync up your repo with mine. I had already added QExplicitlySharedDataPointer last night.

[mattes-bru]

Hi Jon,

I am not sure wether ExplicitlySharedData is what you want. With that a user can mess up the internal data map by using the setters. As well there might be issues with thread safety, as we are working on the same data in QZeroConf and the application which uses the app. If we use SharedData there will be always a deep copy before a write access. So the application does not have access to the internal array (or as soon as it changes the data, it does it on it's own copy) and as well in a multithreaded application, each thread writes in it's own data. So the implementation of QZeroConfService has to be only reentrant and not thread safe (at least from my understanding see: http://doc.qt.io/qt-5/threads-reentrancy.html)

[jbagg]

Hi Matthias, I was planning on making QZeroConfService's setter functions private and making QZeroConfPrivate a friend so only QZeroConfPrivate can write data to a QZeroConfService. Pull my latest code.