QQmlNetworkAccessManagerFactory Class

Description détaillée

Un moteur QML utilise QNetworkAccessManager pour tous les accès réseau. En implémentant une fabrique, il est possible de fournir au moteur QML des instances personnalisées de QNetworkAccessManager avec un support spécialisé de cache, de proxy et de cookies.

• Le site QNetworkDiskCache peut être utilisé comme cache de requête avec QNetworkDiskCache.
• En utilisant QNetworkProxy, le trafic envoyé par QNetworkAccessManager peut être acheminé par un proxy.
• Les cookies peuvent être sauvegardés pour de futures requêtes en ajoutant un QNetworkCookieJar.

Pour mettre en œuvre une fabrique, sous-classez QQmlNetworkAccessManagerFactory et mettez en œuvre la méthode virtuelle create(), puis affectez-la au moteur QML approprié à l'aide de QQmlEngine::setNetworkAccessManagerFactory(). Par exemple, les objets QNetworkAccessManager créés par l'extrait suivant mettront en cache les demandes.

class CachingNetworkAccessManagerFactory : public QQmlNetworkAccessManagerFactory
{
public:

    inline QNetworkAccessManager *create(QObject *parent) override
    {
        QNetworkAccessManager *networkAccessManager = new QNetworkAccessManager(parent);
        QNetworkDiskCache *diskCache = new QNetworkDiskCache(parent);
        diskCache->setCacheDirectory("requestCache");
        networkAccessManager->setCache(diskCache);

        return networkAccessManager;
    }
};

La fabrique peut ensuite être transmise au moteur QML afin qu'il puisse instancier l'objet QNetworkAccessManager avec le comportement personnalisé.

CachingNetworkAccessManagerFactory networkManagerFactory;
engine->setNetworkAccessManagerFactory(&networkManagerFactory);

Notez que le moteur QML peut créer des instances QNetworkAccessManager à partir de plusieurs threads. Pour cette raison, l'implémentation de la méthode create() doit être reentrant. En outre, le développeur doit être prudent si les signaux de l'objet à renvoyer par create() sont connectés aux slots d'un objet qui peut être créé dans un autre thread :

• Le moteur QML traite en interne toutes les demandes et nettoie tous les objets QNetworkReply qu'il crée. La réception du signal QNetworkAccessManager::finished() dans un autre thread peut ne pas fournir au destinataire un objet de réponse valide s'il a déjà été supprimé.
• Les détails d'authentification fournis à QNetworkAccessManager::authenticationRequired() doivent l'être immédiatement. Ce signal ne peut donc pas être connecté en tant que Qt::QueuedConnection (ou en tant que Qt::AutoConnection par défaut d'un autre thread).

Pour plus d'informations sur les signaux et les threads, voir Threads et QObjects et Signals and Slots Across Threads.