Subclassing QNetworkReply

[piotr.dobrogost]

I have to deal with two kinds of network requests when using QtWebKit; synchronous and asynchronous. Synchronous requests are those that are sent to download all external resources referenced by some web page. Asynchronous ones are those that are sent after a web page is loaded and are triggered by JavaScript code and/or user's actions. When all synchronous requests are finished and the page is complete QWebPage (or QWebFrame in case of single frame) emits loadFinished() signal. However QtWebKit does not signal when asynchronous request is finished. To know when they are finished I had to subclass QNetworkAccessManager used by QtWebKit.

Now I'm wondering how should I subclass QNetworkReply so that I have two subclasses, one for each kind of request?

Simply declaring

class SynchReply : public QNetworkReply {};

class SynchReply : public QNetworkReply {};

To copy to clipboard, switch view to plain text mode 

and

class AsynchReply : public QNetworkReply {};

class AsynchReply : public QNetworkReply {};

To copy to clipboard, switch view to plain text mode 

won't work as there's no way of setting its QNetworkReply part after receiving QNetworkReply from QNetworkAccessManager in a call like this
QNetworkReply * reply = QNetworkAccessManager::createRequest(op, req, outgoingData);
from within my subclass of QNetworkAccessManager.

[wysota]

You have to subclass QNetworkAccessManager and reimplement createRequest(). Then you can return whatever you want.

[piotr.dobrogost]

You have to subclass QNetworkAccessManager and reimplement createRequest().

I'm already doing this but in a different way.

QNetworkReply *
NetworkAccessManager::createRequest( Operation op, const QNetworkRequest & req, QIODevice * outgoingData)
{
QNetworkReply * reply = QNetworkAccessManager::createRequest(op, req, outgoingData);
 
	if (checkIfAsync(req.url().toString()))
	{
		QObject::connect(reply, SIGNAL(finished()), this, SLOT(asyncFinishedHandler()));
	}
 
	return reply;
}

QNetworkReply *
NetworkAccessManager::createRequest( Operation op, const QNetworkRequest & req, QIODevice * outgoingData)
{
QNetworkReply * reply = QNetworkAccessManager::createRequest(op, req, outgoingData);

	if (checkIfAsync(req.url().toString()))
	{
		QObject::connect(reply, SIGNAL(finished()), this, SLOT(asyncFinishedHandler()));
	}

	return reply;
}

To copy to clipboard, switch view to plain text mode 

I would like to rewrite it in such a way I wouldn't have to connect individual replies with my slot anymore. I would like to handle the difference in reply's type in one place, in handler of this signal:

void QNetworkAccessManager::finished ( QNetworkReply * reply )   [signal]

void QNetworkAccessManager::finished ( QNetworkReply * reply )   [signal]

To copy to clipboard, switch view to plain text mode 

Then you can return whatever you want.

Any customer can have a car painted any colour that he wants so long as it is black. -- Henry Ford

C++ supports only* covariant return types in overridden virtual functions. (* - my addition.)

Shortly speaking you can't return whatever you want
But the question was how to subclass QNetworkReply?

Having

class MyNetworkReply : public QNetworkReply
{
   bool myFlag;
};

class MyNetworkReply : public QNetworkReply
{
   bool myFlag;
};

To copy to clipboard, switch view to plain text mode 

how to reuse

QNetworkReply * QNetworkAccessManager::createRequest ( Operation op, const QNetworkRequest & req, QIODevice * outgoingData = 0 )   [virtual protected]

QNetworkReply * QNetworkAccessManager::createRequest ( Operation op, const QNetworkRequest & req, QIODevice * outgoingData = 0 )   [virtual protected]

To copy to clipboard, switch view to plain text mode 

to set QNetworkReply part of MyNetworkReply object?

[wysota]

Use the decorator or proxy pattern.

[piotr.dobrogost]

This was the answer that answers my question

What would you say to add Visitor to the mix like this

struct ExtendedNetworkReply : public QNetworkReply
{
    virtual void doStuff() = 0;
    // the rest
};

struct ExtendedNetworkReply : public QNetworkReply
{
    virtual void doStuff() = 0;
    // the rest
};

To copy to clipboard, switch view to plain text mode 

struct SynchNetworkReply : public ExtendedNetworkReply
{
    virtual void doStuff() {};
};

struct SynchNetworkReply : public ExtendedNetworkReply
{
    virtual void doStuff() {};
};

To copy to clipboard, switch view to plain text mode 

struct AsynchNetworkReply : public ExtendedNetworkReply
{
    virtual void doStuff() {};
};

struct AsynchNetworkReply : public ExtendedNetworkReply
{
    virtual void doStuff() {};
};

To copy to clipboard, switch view to plain text mode 

and use doStuff() instead of checking tag? I guess it's more OO style

And two more questions;

1. One can avoid all this subclassing using one dynamic property of QNetworkReply (QObject in fact) to tag replies. Which one you think is better and why?

2. If QNetworkReply is meant to be extended by inheritance and used polimorphically why doesn't it have virtual destructor?

[piotr.dobrogost]

Use the decorator or proxy pattern.

I've found the example of proxy for QNetworkReply here.

I don't quite understand what's the reason for calling base subobject's methods in the following places:

NetworkReplyProxy::NetworkReplyProxy(QObject* parent, QNetworkReply* reply) {
...
setOperation(m_reply->operation());
setRequest(m_reply->request());
setUrl(m_reply->url());
...
}
 
 
// QIODevice proxy...
virtual qint64 bytesAvailable() const { 
return m_buffer.size() + QIODevice::bytesAvailable();    // <-- QIODevice::bytesAvailable() ?
}
 
// not possible...
void setReadBufferSize(qint64 size) {
    QNetworkReply::setReadBufferSize(size);    // <-- ???
    m_reply->setReadBufferSize(size); 
}
 
void errorInternal(QNetworkReply::NetworkError _error)
{
    setError(_error, errorString());    // <-- ???
    emit error(_error);
}

NetworkReplyProxy::NetworkReplyProxy(QObject* parent, QNetworkReply* reply) {
...
setOperation(m_reply->operation());
setRequest(m_reply->request());
setUrl(m_reply->url());
...
}


// QIODevice proxy...
virtual qint64 bytesAvailable() const { 
return m_buffer.size() + QIODevice::bytesAvailable();    // <-- QIODevice::bytesAvailable() ?
}

// not possible...
void setReadBufferSize(qint64 size) {
    QNetworkReply::setReadBufferSize(size);    // <-- ???
    m_reply->setReadBufferSize(size); 
}

void errorInternal(QNetworkReply::NetworkError _error)
{
    setError(_error, errorString());    // <-- ???
    emit error(_error);
}

To copy to clipboard, switch view to plain text mode 

Shouldn't proxy forward all calls to the original object?

[wysota]

In the first case bytesAvailable() of QIODevice is called because the latter has its own internal buffer that can contain some of the data. There is a labs article about it somewhere.