Doing work after QML item is destroyed

[pherthyl]

I've got a QML mobile app based around a StackView. Anytime I push a new screen onto the stack I notify a C++ function that the screen is about to load and load the appropriate controller (C++ class which manages the data and other tasks related to this view).

So to load the controllers I have the following on the QML side:

function createScreenObject(path, props) {
        // notify the backend that we are about to create a screen.
        shellinterface.initScreen(path)
        var component, obj
        component = Qt.createComponent(Qt.resolvedUrl(path))
        if (component.status === Component.Ready) {
            obj = component.createObject()
            obj.screenName = path
        }
        else if (component.status === Component.Error)
            shellinterface.logError("Screen::createScreenObject(" + path + ")" + " - Error loading component: " + component.errorString())
        return {item:obj, properties:props, destroyOnPop:true}
    }
 
stack.push(createScreenObject("To-Do Module/TasksToDoView.qml"))

function createScreenObject(path, props) {
        // notify the backend that we are about to create a screen.
        shellinterface.initScreen(path)
        var component, obj
        component = Qt.createComponent(Qt.resolvedUrl(path))
        if (component.status === Component.Ready) {
            obj = component.createObject()
            obj.screenName = path
        }
        else if (component.status === Component.Error)
            shellinterface.logError("Screen::createScreenObject(" + path + ")" + " - Error loading component: " + component.errorString())
        return {item:obj, properties:props, destroyOnPop:true}
    }

stack.push(createScreenObject("To-Do Module/TasksToDoView.qml"))

To copy to clipboard, switch view to plain text mode 

Then in the C++ backend I have the initScreen function which is similar to:

void ShellInterface::initScreen(const QString &identifier) {
    if (identifier.endsWith("ContextView.qml")) {
        loadController<ContextController>(identifier);
 
    }
    else if (identifier.endsWith("EmployersView.qml") || identifier.endsWith("AddEditEmployerView.qml"))
        loadController<EmployersController>(identifier);
}

void ShellInterface::initScreen(const QString &identifier) {
    if (identifier.endsWith("ContextView.qml")) {
        loadController<ContextController>(identifier);
        
    }
    else if (identifier.endsWith("EmployersView.qml") || identifier.endsWith("AddEditEmployerView.qml"))
        loadController<EmployersController>(identifier);
}

To copy to clipboard, switch view to plain text mode 

So for each view I can load any number of controllers. This works great, because the controllers are loaded before the QML, so the QML can safely use the controller functions when it loads.

The problem comes when unloading. Currently all the screens that get loaded onto the StackView are derived from a Screen object. To unload the controller, I have something like:

Screen.qml
Rectangle {
    property string screenName
    Component.onDestruction: shellinterface.deinitScreen(screenName)
}

Screen.qml
Rectangle {
    property string screenName
    Component.onDestruction: shellinterface.deinitScreen(screenName)
}

To copy to clipboard, switch view to plain text mode 

This works, except that onDestruction is called before the component is fully done being destroyed. So when I unload the controller I get errors from QML bindings that are still trying to read values from the controller.

How would I change it from onDestruction to something like onDestroyed? I want to run code after the QML item is totally gone, but I can't see any events I could hook up to.
Thoughts?

[anda_skoa]

Two ideas:

1) in deinitScreen() don't unload but schedule unloading, e.g. using QMetaObject::invokeMethod with Qt::QueuedConnection.

2) Register the controllers as QML instantiable types and let each screen just create its controller objects. Like any other children they will then be deleted with the screen

Cheers,
_

[pherthyl]

Two ideas:

1) in deinitScreen() don't unload but schedule unloading, e.g. using QMetaObject::invokeMethod with Qt::QueuedConnection.

I've been experimenting with this. I think it is working, but hard to tell if this is actually a guarantee that the controller will be deleted after the object. Since destroy() schedules deletion of the QML and then I schedule deletion of the controller I think the order is undefined.

2) Register the controllers as QML instantiable types and let each screen just create its controller objects. Like any other children they will then be deleted with the screen

Cheers,
_

This might be the way to go. It would also be cleaner because right now the controllers do a setContextProperty("someController", this) in their constructors, and since there is no way to remove context properties I just set them to null when the controller is destroyed.
Only thing is that sometimes different QML screens have the same controller. Right now I manage this with QSharedPointers so they are created and then destroyed when the last reference to them is popped off the stack. I wonder can you have a C++ singleton object that can be instantiated from QML?

[anda_skoa]

I've been experimenting with this. I think it is working, but hard to tell if this is actually a guarantee that the controller will be deleted after the object. Since destroy() schedules deletion of the QML and then I schedule deletion of the controller I think the order is undefined.

Delayed invocation is implemented using events and those are queued (FIFO), so if the delayed invocation for destroy is scheduled first it should come first.

Anyway

Only thing is that sometimes different QML screens have the same controller. Right now I manage this with QSharedPointers so they are created and then destroyed when the last reference to them is popped off the stack. I wonder can you have a C++ singleton object that can be instantiated from QML?

QML2 (Qt5) has singleton objects.
However you can also easily achieve that by an indirection:

class ControllerQmlPart :  public QObject
{
    Q_OBJECT
    Q_PROPERTY(QString someProperty READ someProperty NOTIFY somePropertyChanged);
 
public:
    explicit ControllerQmlPart(QObject *parent = 0);
 
    QString someProperty() const;
 
Q_SIGNALS:
    void somePropertyChanged();
};

class ControllerQmlPart :  public QObject
{
    Q_OBJECT
    Q_PROPERTY(QString someProperty READ someProperty NOTIFY somePropertyChanged);

public:
    explicit ControllerQmlPart(QObject *parent = 0);

    QString someProperty() const;

Q_SIGNALS:
    void somePropertyChanged();
};

To copy to clipboard, switch view to plain text mode 

ControllerQmlPart(QObject *parent) : QObject(parent)
{
    connect(ControllerSingletonPart::instance(), SIGNAL(somePropertyChanged()), this, SIGNAL(somePropertyChanged()));
}
 
QString ControllerQmlPart::someProperty() const
{
    return ControllerSingletonPart::instance()->someProperty();
}

ControllerQmlPart(QObject *parent) : QObject(parent)
{
    connect(ControllerSingletonPart::instance(), SIGNAL(somePropertyChanged()), this, SIGNAL(somePropertyChanged()));
}

QString ControllerQmlPart::someProperty() const
{
    return ControllerSingletonPart::instance()->someProperty();
}

To copy to clipboard, switch view to plain text mode 

Cheers,
_

[wysota]

An alternative:

class ControllerProxy : public QObject {
  Q_OBJECT
  Q_PROPERTY(QObject* controllerType1 READ controllerType1 CONSTANT)
  Q_PROPERTY(QObject* controllerType2 READ controllerType2 CONSTANT)
public:
  ControllerProxy(QObject *parent = 0) : QObject(parent) {}
  QObject* controllerType1() const { return ControllerType1::instance(); }
  QObject* controllerType2() const { return ControllerType2::instance(); }
};

class ControllerProxy : public QObject {
  Q_OBJECT
  Q_PROPERTY(QObject* controllerType1 READ controllerType1 CONSTANT)
  Q_PROPERTY(QObject* controllerType2 READ controllerType2 CONSTANT)
public:
  ControllerProxy(QObject *parent = 0) : QObject(parent) {}
  QObject* controllerType1() const { return ControllerType1::instance(); }
  QObject* controllerType2() const { return ControllerType2::instance(); }
};

To copy to clipboard, switch view to plain text mode 

ControllerProxy {
  id: controller
}
 
Connections {
  target: controller.controllerType1
  onSomeSignal: ...
}

ControllerProxy {
  id: controller
}

Connections {
  target: controller.controllerType1
  onSomeSignal: ...
}

To copy to clipboard, switch view to plain text mode 

First use of instance() would of course instantiate a specific controller type.