Как правильно осуществить множество разных запросов QNetwork

Пишу небольшео ПО которое поятоянно работает с api. Для запросов использую QNetworkAccessManager и у него есть сигнал finished к которому я подключил свой слот. Сам connect указываю в кострукторе класа. Я правильно понмаю, что как только я буду делать запрост через QNetworkAccessmanager то будет вызыватся слот который указан в connect. Но вот задача, запросов будет много, соответственно мне надо и много слотов для обработки данных. Почитал что есть у QNetworkReply сигнал QIODevice::readyRead который будет вызыватся после того как данные будут получены для чтения. connect я укажу в функции которая будет отправлять запрос. Но вот немогу понять как читать из него данные. Или как правильно арганизовать множество POST/GET запросов в одном классе.


Ответы (1 шт):

Автор решения: KoVadim

Когда Вы делаете запрос, Вы можете подцепить к Вашему запросу свои пользовательские данные (например, номер запроса), что бы потом по получению ответа суметь идентифицировать причину отсылки этого запроса.

Сами данные можно подцепить с помощью "динамических свойств функцией setProperty сразу после выполнения QReplay::get (тут немного странно звучит, но если знать, что если позвать QReplay::get, то запрос на самом деле не будет отправлен, пока EventLoop не получит управление, а это произойдет обычно по выходу с функции. И это позволяет после вызова get/post навесить обработчики и все такое).

В слоте finished с помощью property("имя-свойства").isNull() проверяете, если у пришедшего ответа Ваши данные (эти данные не передаются в внешний мир, они живут внутри объекта replay). и если ок, то как то так reply->property().toString("имя-свойства"); получаете, что там.

Ещё раз. с помощью get/post отправляете запросы, добавив им своих пользовательских данных для идентификации. а в слоте finish просто проверяете и отправляете в нужное место на обработку.

код с примером можно найти в похожем вопросе https://stackoverflow.com/questions/40707025/how-to-make-qnetworkreply-to-return-custom-data

Ещё один способ заключается в том, что бы завести мапу (QMap), которая будет хранить как ключ указатель на replay, а значением некую структуру с пользовательскими данными. Суть та же, но эту структуру нужно будет сделать доступной в двух местах, что не очень хорошо.

Третий способ состоит в том, что QReplay имеет свой собственный finished, а значит при отправке запроса можно тут же подписаться на нужный обработчик. В комбинации с первым способом может быть вполне хорошим решением.

QIODevice::readyRead интересная идея, но в ней есть один минус - сокет имеет полное право прислать ответ не одним куском, а несколькими. И Вам придется решать ту же задачу, которую за Вас уже решил QNetworkManager...

→ Ссылка