[Qt-interest] QNetworkAccessManager and a QHash of QNetworkReply pointers

[Mandeep Sandhu]

On Mon, Sep 6, 2010 at 3:14 PM, Juha Ruotsalainen
<juha.ruotsalainen at fastroi.fi> wrote:
> Thanks for all replies. A very good point about adding a property to QObject. I need to do just that, but to the reply object, not to the NAM, since the reply object's URL contain data that we need when we process the readyRead signals. That's the logical place to store fetch-related properties since those are also needed when processing readyReads.
>
> A SIDENOTE: we have few types of fetches that require different handling in finished and readyread slots;
> there's a switch-case that checks the hash's value, a QPair mentioned in my first post, and calls the appropriate handler function based on that.

You can also add custom "attributes" to the QNetworkRequest object
(see QNetworkRequest::setAttribute()). So when you receive a reply,
you can get the request object for it and inspect the attribute to do
different actions. We use this method for differentiating between n/w
replies for image fetch and other types like plain text, JSON etc.

>
> 3. The generic handler code for finished, namFin, removes the reply from the hash and finally calls reply's deleteLater.
>
> Here's an excerpt:
>        // Remove the reply from the list.
>        bool removeReply=true;
>        // Check the type.
>        switch( NAM_TYPE( networkReplies.value(reply) ) )
>        {
>            case NAM_AutoUpdate:
>                versionQueryFinished( reply );
>                break;
>            case NAM_ClientData:
>                clientDataReceived( reply );
>                break;
>            case NAM_WorkList:
>                workListReceived( reply );
>                break;
>            case NAM_Task:
>                removeReply=false;
>                tasksDoneCheck( reply );
>                break;
>            case NAM_StyleSheet:
>                saveStyleSheet( reply );
>                break;
>            default:
>                // Empty on purpose.
>                break;
>        }
>        if(removeReply)
>        {
>            networkReplies.remove(reply);
>        }
>        // Close the reply.
>        reply->close();
>        // Schedule the reply for deletion.
>        reply->deleteLater();
>

If networkReplies.remove(reply) is not being called from any other
place, this should work. Does networkReplies.contins(reply) return
true here?

> 4. The removal shield provided removeReply is the method with which the code now works.
>
> 5. The point where the application had the access violation exception was when the user pressed a button on UI that should reset the application state. Resetting the application state requires that the networkReplies hash is looped through and each network reply's abort and deletelater are called.

While iterating the hash, are you removing the item in the loop too?
Removing items in a loop can cause problems if you're using a
read-only (java style) iterator. CMIIW.

Safe approach would be to abort all replies in the loop and then call
clear() on the hash to remove all items at once.

HTH,
-mandeep

>
>
> CURRENT PLAN...
> ... is to add the two items that are in the hash's value into network reply as properties. This way I can ditch the hash alltogether, and also I don't need to connect to NAM's signals at all.
>
>
> HOWEVER!
> I'm curious to know why hash items were not deleted from the hash on the code sample above? Before removeReply shield being implemented, that is. I had debug prints there and their output were something like:
> """
> fetch #1 net access finished, item removed, 4 remaining
> fetch #4 net access finished, item removed, 4 remaining
> fetch #3 net access finished, item removed, 4 remaining
> fetch #5 net access finished, item removed, 4 remaining
> fetch #2 net access finished, item removed, 4 remaining
> """
>
> Slaínte,
> --
> jussi
>
>
> _______________________________________________
> Qt-interest mailing list
> Qt-interest at trolltech.com
> http://lists.trolltech.com/mailman/listinfo/qt-interest
>