Qt Backend && Qt Quick

Psychomax

Hello together.

I try to make me ready for Qt5. So i want to push my further applications to Qt Quick. I wrote some proof of concepts that work pretty nice. But i have one logic problem. This is the OPTIMAL connection to the backend (in C++). In my eyes there a two ways:

A) Senario

[Consumer 1] ---> [Producer] <--- [Consumer 2]

The Producer is an object that does something. Holding data and refresh them what ever. In the Application there is only one Instance of Producer. The Consumers read the data of the Producer. Every Consumer represents a datamodel and a QML screen. When i switch the screen from consumer 1 -> consumer 2, consumer 1 will be deleted. (Mobile device small memory :-) )

So thats the senario.

1.) setContextProperty(...)
This way I'm using at the moment. But this has a disadvantage. In the documentation there is a warning:

"Setting the context object or adding new context properties after an object has been created in that context is an expensive operation (essentially forcing all bindings to reevaluate). Thus whenever possible you should complete "setup" of the context before using it to create any objects." (http://doc.qt.nokia.com/4.7/qdeclarativecontext.html)

What does that exactly mean? I do that the following way at the moment. (only pseudocode ;-) )

....
//Init
Producer *p = Producer::instance();
Consumer *c1 = new Consumer(p);
Consumer *c2 = NULL;

context1->setContextProperty("consumer1", c1);
context1->setContextProperty("consumer2", c2);
....
//switch case called by qml
...
c2 = new Consumer(p);
delete c1;
c1 = NULL;
...

So in this case will Qt "forcing all bindings to reevaluate"? If yes it is not a perfect way.

2.) Plugin in for QML
This would be a nice way. But how can a manage that senario? Ok i could start my Application with the producer object. But how does the plugin gets a pointer to the producer. How i've seen it is not possible to add a constructor with a param (e.g. Consumer::Consumer(const Producer *))

Hope you can help me! :-)
Max

zester

Max It means that you probably don't want to be doing it the way that you are. The only time you ever want
to talk to the c++ back-end is when it provided's a feature that qml doesn't. You can create, share and destroy objects in qml.

http://doc.qt.nokia.com/4.7-snapshot/qdeclarativedynamicobjects.html

srikanth_trulyit

Follow the classic MVC pattern if it makes sense for you. In our case we have a dynamic property requirement wherein widget properties are changed at runtime, like text of label etc. So we choose to put our model and controller in C++ and inject the controller into the respective qml. But the creation of qml elements is completely left to dynamic object management of qml.

Hornsj2

I use the context properties as AbstractListModel back-ends for views which need to be fed dynamic content.

Is this not the preferred method? Is there a more efficent method?

These properties are added to the context before main.qml is created though...

aalpert

If I understand your situation correctly, the correct solution would be to expose the Consumer type to QML. If there is only one instance of the Producer class, then each Consumer class can find that instance using a static method on the Producer class, inside the C++ constructor.

Assuming that the Consumer class is a QObject derived class, you just register it with QML and instantiate it in QML when ever you want one. From QML you can access the properties and data of the Consumer object to display them. You can do your special setup in the C++ constructor. This does not require a plugin if you have your own C++ application already, you can register types for use just within your application.