The upload manager allows to upload a file to a server via XEP-0363: HTTP File Upload. This can be used for sending files to other users.
QXmppHttpUploadManager depends on QXmppUploadRequestManager. You can enable them using
QXmppClient * client() const
Definition: QXmppClientExtension.cpp:57
T * addNewExtension(Args... args)
Definition: QXmppClient.h:117
Definition: QXmppHttpUploadManager.h:54
The QXmppUploadRequestManager implements the core of XEP-0369: HTTP File Upload.
Definition: QXmppUploadRequestManager.h:85
- Since
- QXmpp 1.5
◆ QXmppHttpUploadManager() [1/2]
QXmppHttpUploadManager::QXmppHttpUploadManager |
( |
| ) |
|
Constructor
Creates and uses a new network access manager.
◆ QXmppHttpUploadManager() [2/2]
QXmppHttpUploadManager::QXmppHttpUploadManager |
( |
QNetworkAccessManager * |
netManager | ) |
|
|
explicit |
Constructor
- Parameters
-
netManager | shared network access manager, needs to have at least the lifetime of this manager. |
◆ uploadFile() [1/2]
std::shared_ptr< QXmppHttpUpload > QXmppHttpUploadManager::uploadFile |
( |
const QFileInfo & |
fileInfo, |
|
|
const QString & |
filename = {} , |
|
|
const QString & |
uploadServiceJid = {} |
|
) |
| |
Upload data from a local file.
- Parameters
-
fileInfo | QFileInfo about a local file |
filename | filename How the file on the server should be called. This is commonly used as last part of the resulting url. |
uploadServiceJid | optionally, the jid from which an upload url can be requested (upload service) |
- Returns
- an object representing the ongoing upload. The object is passed as a shared_ptr, which means it will be stored as long as there is a reference to it. While this avoids errors from accessing it after it was deleted, you should try not store it unneccesarily long to keep the memory usage down. You can for example use std::weak_ptr to not increase the lifetime, for example when capturing in long living lambdas, for example in connects. You should also make sure to use the 4-arg QObject::connect, so the connection and the connected lambda can be deleted after the upload finished.
std::weak_ptr<QXmppHttpUpload> uploadPtr = upload;
auto upload = uploadPtr.lock();
if (upload) {
qDebug() << upload->progress();
}
});
Q_SIGNAL void progressChanged()
◆ uploadFile() [2/2]
std::shared_ptr< QXmppHttpUpload > QXmppHttpUploadManager::uploadFile |
( |
std::unique_ptr< QIODevice > |
data, |
|
|
const QString & |
filename, |
|
|
const QMimeType & |
mimeType, |
|
|
qint64 |
fileSize = -1 , |
|
|
const QString & |
uploadServiceJid = {} |
|
) |
| |
Uploads the data from a QIODevice.
- Parameters
-
data | QIODevice to read the data from. This can for example be a QFile. It can be sequential or non-sequential. |
filename | How the file on the server should be called. This is commonly used as last part of the resulting url. |
fileSize | The size of the file, in byte. If negative the size from the IO device is used. |
mimeType | The mime type of the file |
uploadServiceJid | optionally, the jid from which an upload url can be requested (upload service) |
- Returns
- an object representing the ongoing upload. The object is passed as a shared_ptr, which means it will be stored as long as there is a reference to it. While this avoids errors from accessing it after it was deleted, you should try not store it unneccesarily long to keep the memory usage down. You can for example use std::weak_ptr to not increase the lifetime, for example when capturing in long living lambdas, for example in connects. You should also make sure to use the 4-arg QObject::connect, so the connection and the connected lambda can be deleted after the upload finished.
std::weak_ptr<QXmppHttpUpload> uploadPtr = upload;
auto upload = uploadPtr.lock();
if (upload) {
qDebug() << upload->progress();
}
});
The documentation for this class was generated from the following files: