Лидеры

зачем у вас тут нетипизированные параметры? сделайте два разных метода и не будет такой каши. function bdconected(s2:string;s1,s{,sd}: TObject): string;

нет не следует там написано, "если вы хотите получать данные прямо в процессе их получения, вместо того чтобы ждать когда скачается всё до конца..." ну собсно, да, можно из того же стрима их забирать в событии OnReceiveData, но зачем вам неполный json ?? это же не звук, не видео, которые можно сразу на экран выводить, не дожидаясь всего кино... но при этом это будет происходить независимо, опять же в другом потоке. ваш поток, где вы вызвали Post, будет ждать окончания загрузки. Асинхронно это будет только через BeginPost

Вся эта процедура в моем коде запущена в отдельном потоке через TTask.Run(). (кстати - асинхронно! т.е. сначала скорее всего выполнится до конца FormCreate а потом запустится run) Поэтому доступ к визуальным компонентам должен быть только через синхронизацию. Для этого вывод в memo обернут в TThread.Synchronize(); Далее. В этой форме POST второй параметр - стрим, данные из которого мы передаем на сервер, а третий - стрим, куда придет результат. Так как мы знаем, что туда и обратно будет ходить текст, то и выбираем TStringStream, как самый подходящий. Т.е. в stRes нас будет ждать результат. Такой же как и в R.ContentAsString Если вы хотите отслеживать (track) процесс получения данных, то можно повеситься на OnReceiveData там будет сообщаться сколько байт уже скачано, сколько всего планируется скачать. В этом обработчике можно сделать обновление progressBar, тоже через синхронизацию. Предполагается, что у вас там хотя бы сотни килобайт данных, иначе сомневаюсь, что этот обработчик хоть раз сработает. Ловить окончание с его помощью точно не нужно ) Все процессы обмена обычно делятся на синхронные и асинхронные. Синхронные - программа дальше не идет, пока не выполнится эта строчка. Асинхронные - команду отдали и пошли дальше. В этом случае обычно задается кусок кода, который выполнится по окончании процесса. THttpClient имеет оба вида вызовов. Обычные синхронные Get, Post и т.д. Асинхронные - BeginGet, BeginPost и т.д. http://docwiki.embarcadero.com/Libraries/Rio/en/System.Net.HttpClient.THTTPClient_Methods Обычно кроме самого вызова происходит еще много всяких вещей, которые я выношу в отдельный поток, поэтому всегда использую синхронные методы. Если вы будете это делать из главного потока, то можно использовать асинхронные. Вопрос удобства и архритектуры. Но говорить, что "что там, фигня, один маленький запросик" нельзя. Если сервер недоступен, не отвечает, плохая связь и т.д., ваша программа тупо зависнет сек на 30. Несколько раз так зависнет, а потом Андроид предлагает удалить ее с устройства, т.к. в ней баги и вообще она плохая. Пользователи не очень любят такое))

Сломали они вторым патчем ограничения с записями. Либо откатывать его, либо убирать ограничения https://quality.embarcadero.com/browse/RSP-30073 Видимо хотели починить это https://quality.embarcadero.com/browse/RSP-28761

код приложен, запускайте и играйтесь до просветления

httpDemo.7z вот демо работает одинаково на Windows и Android

это зависит от того, кто программировал этот сервер) но вы же ему по сути передаете "отвечай как хочешь". и первый в списке html

вот инструкция на английском, с картинками - http://docwiki.embarcadero.com/RADStudio/Rio/en/Submitting_Your_Android_App_to_Google_Play

нормально у меня работают и Get и Post и кодировка нормально принимается. вам нужно проверить, что же реально уходит на сервер для этого есть эхо сервера например https://docs.postman-echo.com либо направить на любой свой сервер, сделать неск строк скрипт на PHP который покажет все заголовки и контент, который он получил Совершенно непонятно, для чего тут TBytesStream, TStringStream работает абсолютно прозрачно (под капотом ессно то же самое) Ну и делать общение с сервером в главном потоке - странное занятие конечно