[Interest] remoteobject returning a list of remoteobjects

[Stottlemyer, Brett (B.S.)]

On 4/22/19, 10:10 AM, "Marc Van Daele" <marc.van.daele90 at gmail.com> wrote:    
    • If I don't need signals and slots on my Person class, I should use a POD.  PROP(QList<Person*> persons) will be supported but whenever something changes in the list or any property of any item in it, the complete list has to be resent (there is only a single personsChanged signal)

In general, I like PODs for simple data collections that make sense to go together, but don't need signals and slots.  I can't tell if "Person" fits that, but your description of the implications of using PODs (or a QList of PODs) is correct.

    • If I do need signals and slot on my Person class, Person should be a rep-class (nested inside Household) 
       o I can create a MODEL(persons) [can you give a pointer of this syntax? I couldn't find much info on MODEL]. 

The CLASS and MODEL keywords are distinct from each other.  MODEL --> QAbstractItemModel (QAIM), CLASS --> QObject.
MODEL example: https://code.qt.io/cgit/qt/qtremoteobjects.git/tree/tests/auto/modelreplica
CLASS example: https://code.qt.io/cgit/qt/qtremoteobjects.git/tree/tests/auto/subclassreplica

    • This will behave as if the model was local to the client.  Slots can be called on the items in the model, signals of the model and the individual items in the mode can be received.  
    • Is it correct to say that the HouseholdReplica contains a model of PersonReplica (pointers) and the HouseholdSource contains a model of PersonSource (pointers) ?
    • Can both the client and the server add rows (new Persons) to the model?
       o Can I also create a PROP(QList<Person*> persons)?   
    • Is it correct to say that the HouseholdReplica contains a QList of PersonReplica pointers?
    • Are the PersonReplica's automatically linked to the corresponding PersonSources?  Or should I somehow link them myself to ensure that a slot called on the 2nd PersonReplica ends up in the correct PersonSource?
    • Can I add/remove Persons both from client and server side?

The idea of QtRO is that where a "normal" app would have all QObjects and UI elements in a single process, QtRO lets you split into multiple processes or devices.  But you shouldn't have to redesign the object structure, instead you just share the QObjects themselves.  To the extent possible, given latency and error conditions in communication, you shouldn't have to care whether the QObjects are in another process or not.

From that perspective, what you are asking isn't really how QtRO works, you are (in effect) asking how your apps/processes should be designed.  How would you implement these classes if they were in one process?

QAIM classes have signals for when chunks of the model change, not individual signals.  They just behave differently, and if you aren't familiar with how they work, I'd recommend reviewing that first (https://doc.qt.io/qt-5/model-view-programming.html).  A QAIM over QtRO works just the same as if the model were local.  If you need additional methods to add data to the model, those would need to be additional slots that you'd have to implement yourself on the Source side.  This might be the right direction to go, but it might not be.

I've only rarely seen a case where a QList of QObject pointers is the right design.  If the list is dynamic, connecting signals of those objects to slots of other objects gets to be complex and error prone.  That would get compounded by the additional error states involved with QtRO.

One alternative, instead of having the fundamental shared object be a household, would be to have a Person class as the shared type.  You can have multiple source/replica objects of the same type, as long as each is given a distinct name.  The Household could potentially be only in the UI process, consolidating the individual Person replicas.

I'm not sure what the right design is for your use-case, but hopefully the above gives an idea of what some of the options are and how one might select from them.

Good luck,
Brett