[Interest] remoteobject returning a list of remoteobjects

[Stottlemyer, Brett (B.S.)]

Hi Marc,

On 4/20/19, 6:46 AM, "Interest on behalf of Marc Van Daele" <interest-bounces at qt-project.org on behalf of marc.van.daele90 at gmail.com> wrote:

    Hello,
    
    I'm trying to understand the remoteobjects component.
    Suppose I have, on my backend, a Household containing a list of Persons.
    
The intent is for Qt Remote Objects to allow what Qt allows, with the only constraint being that queued connections be supported.  So you should design your interface as you would for standard Qt in-process interaction, and not have to modify it for QtRO.  If that doesn’t work (there are a few unsupported cases), please file a bug report.

    I guess I'll have a rep file like
    class Person
    {
       //some properties, slots and signals
    }
    class Household
    {
        PROP(QList<Person> persons)
    };
    
    Now I wonder
    • Is this a valid approach?

No, this isn't valid, as it wouldn't work in a queued connection.  Only QObject *pointers* can be used in queued connections, as QObjects are not copy-able.

    • will the persons property result in a list of PersonReplica on the client side and in a list of PersonSources on the server side?

In this specific case, no, for the above reason.  There are a number of alternatives available, depending on the complexity of the types involved.

For simple types, I recommend using a POD in the .rep interface definition.  This resolves to a Q_GADGET, basically a struct with a metaobject defined.  Signals and slots aren't supported on PODs, though.  These are only data containers, but a QList of them is supported.  A potential downside here is that changing any single value would require the entire list to be resent.

QtRO also supports QAbstractItemModel based types, using the MODEL keyword in the .rep file.  This has the advantage of allowing individual rows or fields to be adjusted, and scales to large numbers of records.

Lastly, you could a nested subclass using the CLASS keyword in the .rep file.  This has the advantage of allowing a nested object with its own signals and slots.

So there are several options, with the hope that you can design for what makes sense from a user/API perspective and QtRO doesn't get in the way.

    • how can I link a specific PersonReplica object to the corresponding PersonSource object?

With PODs (or a QList of PODs) as a property, you can replace the objects and assign the new value via the setter, which will propagate the new value to any Replicas.  With QAIM, you just change the model values on the Source and QtRO handles propagating the changes.  Nested CLASS objects work like just like other QObjects, and you assign the object itself via the generated setter on the Source.

    • where should this linking be done?

Does the above answer this question?  If not, can you rephrase?
    
Regards,
Brett