Welcome!

Welcome to the official BlackBerry Support Community Forums.

This is your resource to discuss support topics with your peers, and learn from each other.

inside custom component

Native Development

Reply
Developer
Posts: 163
Registered: ‎01-30-2013
My Device: Blackberry 10 Simulator

Re: Handle server response

in your example, the finished() will also call both customProcessing1 and customProcessing2 isn't it??

 

And btw. In my scenario (it is a bit modified now), from the requestFinished(QNetworkReply *reply) of QNetworkAccessManager I am specifically emitting a signal called "signalSuceeded" because it may carry some data with it (e.g., such as string in above case).

 

what to do in this case??

Developer
Posts: 293
Registered: ‎10-15-2012
My Device: bb10 developer
My Carrier: Orange

Re: Handle server response

use:


emit signalSucceeded("your string here")



Developer
Posts: 163
Registered: ‎01-30-2013
My Device: Blackberry 10 Simulator

Re: Handle server response

[ Edited ]

Hi, thanks.

 

We have a little miscommunication here. I know and I have already done:

emit signalSucceeded("your string here").

 

My problem was that I didn't want same signal to call different (say 10 slots)

each time it is emitted. Rather, when the signal is emitted once, I want it to call

say Slot1, when the (same) signal is emitted the other time, I want it to call Slot 2

(I don't want it to call Slot1 once again).

 

That is why I asked and I will ask you once again, in your example before, will

not the finished() signal call both customProcessing1and customProcessing2??

Or since it is tied to different QNetworkReplies -- that will not be the case???

 

thanks.

 

Developer
Posts: 293
Registered: ‎10-15-2012
My Device: bb10 developer
My Carrier: Orange

Re: Handle server response

No - the example I provided does exactly what you want it to

Recall that signals are emitted from an *object*. Each time you make a network request, you obtain a different QNetworkReply *object* that uniquely identifies that specific request.

Signals - such as finished() - emitted from reply1 will be entirely separate from the finished() signal emitted from reply2. This is because the QNetworkReply is different in each case - its a different object
Developer
Posts: 163
Registered: ‎01-30-2013
My Device: Blackberry 10 Simulator

Re: Handle server response

Thanks. That's exactly what I wanted. Btw. On the previous page, I think I was suggesting smth

similar when I mentioned that I could use different "network" objects for connecting signals and slots right???

 

Highlighted
Developer
Posts: 293
Registered: ‎10-15-2012
My Device: bb10 developer
My Carrier: Orange

Re: Handle server response

[ Edited ]

You could use different QNetworkAccessManager for every connection and achieve the same effect - but it is not recommended.

 

One useful way of passing more 'context' or additional information to your slots (that doesn't get returned in the network data) - is to use Qt properties on your QNetworkReply:

 

void MyApp::blah()
{
  QNetworkReply *reply = .... do a network request....
  
  // set a property on the networkreply (this works
  // because QNetworkReply inherits from QObject)
  reply->setProperty("myProperty", "hello");

  reply->connect(SIGNAL(finished()), this, SLOT(customProcessing1()));
}

 

and then in your slot:

void MyApp::customProcessing1()
{
  // find which qnetworkreply we are processing
  QNetworkReply *reply = qobject_cast<QNetworkReply*>(sender());
  
  // retrieve the property that was set earlier
  QString hello = reply->property("myProperty").toString();
}

 

Developer
Posts: 163
Registered: ‎01-30-2013
My Device: Blackberry 10 Simulator

Re: Handle server response

[ Edited ]

Hi, thanks for your reply.

One modification in my situation was that the QNetworkAccessManager requestFinished(..)

was issuing this signal: signalSucceeded(QVariant data) because I was basically

sending out a parsed version of the server response (and also this way I did not need

to handle QNetowkorReply outside the class anymore -- I would just catch the  signalSucceeded signal

which carried the server data).

I will look into your solution. I hope I made my goal clear -- if your suggestion, of using different

QNetworkReply objects and corresponding slots for them will solve my issue, I may not use

the signalSucceeded anymore and just parse the data in the custom slots (e.g., customProcessing1, customProcessing2 etc.) and using different QNetworkReply objects...

Hope I was clear??? Thanks.

 

btw. who is sender() in your code??

 

Developer
Posts: 293
Registered: ‎10-15-2012
My Device: bb10 developer
My Carrier: Orange

Re: Handle server response

sender() provides you with the QObject that emitted the signal that your slot has been called on.

In your case you know that your slot is only going to be called from a QNetworkReply object, so you can cast it appropriately to obtain the network reply.

Developer
Posts: 163
Registered: ‎01-30-2013
My Device: Blackberry 10 Simulator

Re: Handle server response

aha..........

because in one of the examples I was recommended to use a QNetworkReply as a member variable, for example like here:

 

(1) QNetworkReply* reply1 = makePostRequest("ApiCallLogin");
connect(reply1, SIGNAL(finished()), this, SLOT(customProcessing1()));

 it is a local variable. And in my code I had implemented it as a member variable:

 

(2) reply1 = makePostRequest("ApiCallLogin"); // reply1 is a member variable

 so that in the Slot I could directly call reply1->readAll(). Otherwise how I would get the contents of reply1 in some different slot??? (I think your suggestion also solves this issue of obtaining the reply contents without using a member variable).

 

My problem with the solution I described with member variables was that -- as I mentioned in my previous samples there maybe many places where I would connect signals and slots and issue network requests, and in that case I would have to have separate QNetworkReply member variables for each slot connection I think ?? e.g., as shown above on the second code line (2). I think using your suggestion I would not need separate QNetworkReply member variables for each invocation of a network function??