Fedor K

У стандартного TListView уже все есть:
 
//устанавливаем режим редактирования у списка либо в редакторе свойств выставляем ListView1.EditMode := True; //... //Получаем список всех выбранных элементов ListView1.Items.CheckedIndexes(true); //обращаться к свойству текущего элемента так: ListView1.Items.SetChecked(const Index: Integer; const Value: Boolean); ListView1.Items.GetChecked(const Index: Integer): Boolean;  

@Pavel M, Судя по вашей обертке класса и самой JAR:
 Нужно удалить все не статические методы из описания интерфейса наследуемого от JObjectClass: JUserClass = interface(JObjectClass) ['{A4B29440-8C8B-4C1F-A8E7-B7612D4FEEB4}'] function init(uuid : JString; secondName : JString; firstName : JString; inn : JString; phone : JString; pin : JString; roleUuid : JString; roleTitle : JString) : JUser; cdecl; overload; function init(uuid : JString; secondName : JString; firstName : JString; phone : JString; pin : JString; roleUuid : JString; roleTitle : JString) : JUser; cdecl; overload; end; У класса User нету конструктора по умолчанию, поэтому вызов такого кода вызовет ошибку: //неправильный вариант с ошибкой TestClass := TJUser.Create; //правильный вариант TestClass := TJUser.JavaClass.init( StringToJString('uuid'), StringToJString('secondName'), StringToJString('firstName'), StringToJString('phone'), StringToJString('pin'), StringToJString('roleUuid'), StringToJString('roleTitle') );  
Если к проекту подключаете любые JAR файлы, то следите, чтобы вместе с ними были подключены и все остальные .jar библиотеки с классами, на которые ссылаются исходники. Например, в Вашем примере при вызове вышеприведенного конструктора первым делом выскочит ошибка:
Вам нужно найти все такие подключения и найти сборки, в которых они валяются:

Если в проекте в Android Studio включено копирование всех сторонних библиотек в папку libs, то после компиляции всего преокта практически все либы можно найти:
папка libs; output папке проекта; папка Android SDK. п.с. Тему лучше перенести в раздел Android, так больше шансов получить помощь.

При работе с API конкретной платформы советую использовать именно справку самой платформы. Находим реализацию на родном языке и пытаемся повторить тоже самое через wrappers от Delphi.
1 - это идентификатор вашего сервиса отличный от 0 (см. подробнее Service | Android Developers), т.е. можете использовать любые положительные цифры. По сути и обычные уведомления тоже содержат такой идентификатор, но это практически редко используется.

При работе с API конкретной платформы советую использовать именно справку самой платформы. Находим реализацию на родном языке и пытаемся повторить тоже самое через wrappers от Delphi.
1 - это идентификатор вашего сервиса отличный от 0 (см. подробнее Service | Android Developers), т.е. можете использовать любые положительные цифры. По сути и обычные уведомления тоже содержат такой идентификатор, но это практически редко используется.

@Pavel M, Судя по вашей обертке класса и самой JAR:
 Нужно удалить все не статические методы из описания интерфейса наследуемого от JObjectClass: JUserClass = interface(JObjectClass) ['{A4B29440-8C8B-4C1F-A8E7-B7612D4FEEB4}'] function init(uuid : JString; secondName : JString; firstName : JString; inn : JString; phone : JString; pin : JString; roleUuid : JString; roleTitle : JString) : JUser; cdecl; overload; function init(uuid : JString; secondName : JString; firstName : JString; phone : JString; pin : JString; roleUuid : JString; roleTitle : JString) : JUser; cdecl; overload; end; У класса User нету конструктора по умолчанию, поэтому вызов такого кода вызовет ошибку: //неправильный вариант с ошибкой TestClass := TJUser.Create; //правильный вариант TestClass := TJUser.JavaClass.init( StringToJString('uuid'), StringToJString('secondName'), StringToJString('firstName'), StringToJString('phone'), StringToJString('pin'), StringToJString('roleUuid'), StringToJString('roleTitle') );  
Если к проекту подключаете любые JAR файлы, то следите, чтобы вместе с ними были подключены и все остальные .jar библиотеки с классами, на которые ссылаются исходники. Например, в Вашем примере при вызове вышеприведенного конструктора первым делом выскочит ошибка:
Вам нужно найти все такие подключения и найти сборки, в которых они валяются:

Если в проекте в Android Studio включено копирование всех сторонних библиотек в папку libs, то после компиляции всего преокта практически все либы можно найти:
папка libs; output папке проекта; папка Android SDK. п.с. Тему лучше перенести в раздел Android, так больше шансов получить помощь.

@Pavel M, Судя по вашей обертке класса и самой JAR:
 Нужно удалить все не статические методы из описания интерфейса наследуемого от JObjectClass: JUserClass = interface(JObjectClass) ['{A4B29440-8C8B-4C1F-A8E7-B7612D4FEEB4}'] function init(uuid : JString; secondName : JString; firstName : JString; inn : JString; phone : JString; pin : JString; roleUuid : JString; roleTitle : JString) : JUser; cdecl; overload; function init(uuid : JString; secondName : JString; firstName : JString; phone : JString; pin : JString; roleUuid : JString; roleTitle : JString) : JUser; cdecl; overload; end; У класса User нету конструктора по умолчанию, поэтому вызов такого кода вызовет ошибку: //неправильный вариант с ошибкой TestClass := TJUser.Create; //правильный вариант TestClass := TJUser.JavaClass.init( StringToJString('uuid'), StringToJString('secondName'), StringToJString('firstName'), StringToJString('phone'), StringToJString('pin'), StringToJString('roleUuid'), StringToJString('roleTitle') );  
Если к проекту подключаете любые JAR файлы, то следите, чтобы вместе с ними были подключены и все остальные .jar библиотеки с классами, на которые ссылаются исходники. Например, в Вашем примере при вызове вышеприведенного конструктора первым делом выскочит ошибка:
Вам нужно найти все такие подключения и найти сборки, в которых они валяются:

Если в проекте в Android Studio включено копирование всех сторонних библиотек в папку libs, то после компиляции всего преокта практически все либы можно найти:
папка libs; output папке проекта; папка Android SDK. п.с. Тему лучше перенести в раздел Android, так больше шансов получить помощь.

@Pavel M, Судя по вашей обертке класса и самой JAR:
 Нужно удалить все не статические методы из описания интерфейса наследуемого от JObjectClass: JUserClass = interface(JObjectClass) ['{A4B29440-8C8B-4C1F-A8E7-B7612D4FEEB4}'] function init(uuid : JString; secondName : JString; firstName : JString; inn : JString; phone : JString; pin : JString; roleUuid : JString; roleTitle : JString) : JUser; cdecl; overload; function init(uuid : JString; secondName : JString; firstName : JString; phone : JString; pin : JString; roleUuid : JString; roleTitle : JString) : JUser; cdecl; overload; end; У класса User нету конструктора по умолчанию, поэтому вызов такого кода вызовет ошибку: //неправильный вариант с ошибкой TestClass := TJUser.Create; //правильный вариант TestClass := TJUser.JavaClass.init( StringToJString('uuid'), StringToJString('secondName'), StringToJString('firstName'), StringToJString('phone'), StringToJString('pin'), StringToJString('roleUuid'), StringToJString('roleTitle') );  
Если к проекту подключаете любые JAR файлы, то следите, чтобы вместе с ними были подключены и все остальные .jar библиотеки с классами, на которые ссылаются исходники. Например, в Вашем примере при вызове вышеприведенного конструктора первым делом выскочит ошибка:
Вам нужно найти все такие подключения и найти сборки, в которых они валяются:

Если в проекте в Android Studio включено копирование всех сторонних библиотек в папку libs, то после компиляции всего преокта практически все либы можно найти:
папка libs; output папке проекта; папка Android SDK. п.с. Тему лучше перенести в раздел Android, так больше шансов получить помощь.

@Pavel M, Судя по вашей обертке класса и самой JAR:
 Нужно удалить все не статические методы из описания интерфейса наследуемого от JObjectClass: JUserClass = interface(JObjectClass) ['{A4B29440-8C8B-4C1F-A8E7-B7612D4FEEB4}'] function init(uuid : JString; secondName : JString; firstName : JString; inn : JString; phone : JString; pin : JString; roleUuid : JString; roleTitle : JString) : JUser; cdecl; overload; function init(uuid : JString; secondName : JString; firstName : JString; phone : JString; pin : JString; roleUuid : JString; roleTitle : JString) : JUser; cdecl; overload; end; У класса User нету конструктора по умолчанию, поэтому вызов такого кода вызовет ошибку: //неправильный вариант с ошибкой TestClass := TJUser.Create; //правильный вариант TestClass := TJUser.JavaClass.init( StringToJString('uuid'), StringToJString('secondName'), StringToJString('firstName'), StringToJString('phone'), StringToJString('pin'), StringToJString('roleUuid'), StringToJString('roleTitle') );  
Если к проекту подключаете любые JAR файлы, то следите, чтобы вместе с ними были подключены и все остальные .jar библиотеки с классами, на которые ссылаются исходники. Например, в Вашем примере при вызове вышеприведенного конструктора первым делом выскочит ошибка:
Вам нужно найти все такие подключения и найти сборки, в которых они валяются:

Если в проекте в Android Studio включено копирование всех сторонних библиотек в папку libs, то после компиляции всего преокта практически все либы можно найти:
папка libs; output папке проекта; папка Android SDK. п.с. Тему лучше перенести в раздел Android, так больше шансов получить помощь.

Close, Application.Terminate - я бы не советовал использовать на Android. Может оказаться такая ситуация, что часть приложения останется в памяти, а что-то уже убьется. В итоге заново запустить приложение без выкидывания из истории не получится и увидите только черный экран. Желательно обойтись без самоубийства на Android  и лишь свернуть через SharedActivity.moveTaskToBack(True); Если все же самоубийство по плану, тогда лучшие средства  TJProcess.JavaClass.killProcess(TJProcess.JavaClass.myPid); MainActvity.Finish; - как упомянул выше Равиль.  

Очередные холивары из разряда "мои проблемы никто не хочет решить за меня, значит Delphi плохой инструмент, давайте все перейдем в другую песочницу...". Минусы FMX есть и будут, от этого никуда не денешься, но в последнее время весь soft и продукты катятся в яму с кучей bugs даже от крупных компаний и корпораций даже спустя многие releases. 
Если на то пошло, то предлагаю все "невозможные" фишки периодически добавлять в первый пост и прикреплять решения, если они существуют.
Проблемы FMX  в следующем:
Жесткая привязка к версии SDK, возможно сделано целенаправленно, чтобы пользователи обновляли лицензии год за годом. Позволяет разработчику не углубляться в особенности операционной системы, и не меняя мышления клепать свой "первоклассно рабочий VCL стиль" код и тонны компонентов под все платформы. Пропаганда "возьмите свой старый код и сделайте мобильное приложение" - маркетологи, вы в своем уме? Отсутствие достойных плагинов для IDE. Тот же Cn Wizard давно пора включить по дефолту. Неужели сложно добавить плагин для создания wrappers для java классов сразу в IDE? Разве сложно загрузить приложение прямо в маркет без ручного копирования?  Отсутствует редактор manifest, plist как таковой. Вспоминается анекдот про танк и "доработать напильником". Многие достойные вещи делаются на голом энтузиазме сообществом, но почему-то только спустя много-много времени внедряются в коробку. Отсутствует нормальный debug на мобильных платформах, логами все не покроешь. Ограничения в ARM процессорах. Желание все хранить в .fmx, .dfm файлах, а не ссылками в ресурсы, как это принято в мобильной разработке. Это конечно обходится написанием своих менеджеров, но неужели сложно это продумать из коробки? Такое чувство, что пытаемся охватить как можно больше платформ по чуть чуть, чтобы кому-нибудь впарить свой продукт, а уже потом будем думать, как выкручиваться. FMX Canvas - ахиллесова пята. Не смотря на все это FMX является очень мощным инструментом и крайне приятным в умелых руках, если вы любите напильник (или мазохист). Средне статические проекты можно реализовывать не боясь, но для более серьезных вещей понадобятся знания нативной разработки, без этого никак. Если заказчик начинает разговор "я хочу такое, как в том-то приложении..." - значит без написания своей обертки или исправления исходников не обойдешься.
FMX в последнее время активно развивается и спустя Х лет все будет у нас превосходно, просто не бегите за новыми версиями, а подождите Update 3 или используйте предыдущую версию (Berlin Update 2 все еще в соку).
Другие кросплатформенные frameworks (Xamarin, Reac Native, RemObject, Native script, другие) тоже не лишены недостатков, но там слегка другие концепции и другая аудитория, кто лучше - покажет лишь время.

Что конкретно печально в асинхронности клиента? На какой платформе? Если с примером - то вообще замечательно.
п.с. Еще раз повторю, что нареканий со стороны работы асинхронности не было замечено в течении года в нагруженном мобильном приложении на обоих осях, Delphi Berlin Update 2.
 

Пожалуйста, внимательней прочтите тему, здесь идет речь про асинхронный THTTPClient, а не про Indy компоненты. Если в вашем приложении до сих пор используется Indy, то советую от него избавляться.
Пожалуйста, будьте более культырными в своем общении, этот форум нацелен повысить уровень делфи программистов, а не унизить кого-то и пустить по плохому пути.
THTTPClient успешно делает асинхронные запросы и синхронизирует callback для обработки, поэтому использовать его в синхронном режиме и добавлять свою реализацию асинхронности считаю лишними затаратами ресурсов.

@Akad, У Вас есть опыт работы с TNetHTTPClient компонентом или классом THTTPClient? Как и где вы это использовали? Что не понравилось? Какие трудности были?
... можете не отвечать, я уже глянул ваши предыдущие сообщения и смысла в продолжении беседы не вижу
@kiz35196 Наиболее простой вариант Вы можете глянуть в этом посте.

Пруфов про потоки в асинхронных вызовах не будет, если я правильно понял...
Я тоже могу повторить, что завершение всех инициированных собой операций - это проблема создателя этих операций, которую он обязан решить. Если прервать никак - значит дождаться завершения. Более того, возможно (но пока не могу утверждать), что с уничтожением экземпляра THTTPClient его асинхронная операция должна уйти в небытие.
А вот здесь ткните меня носом, пожалуйста. Что за HTTPServer - в справке в классах System,Net я такого не нашел. И в исходниках (правда, у меня Берлин) тоже. Возможно - плохо искал.
THTTPClient. Причем - без необходимости таскания с собой всяких OpenSSL Library в разных ипостасях. Обратите внимание - я говорил именно за отказ от Indy в http(s) обмене. А не про "полный отказ".

Что конкретно печально в асинхронности клиента? На какой платформе? Если с примером - то вообще замечательно.
п.с. Еще раз повторю, что нареканий со стороны работы асинхронности не было замечено в течении года в нагруженном мобильном приложении на обоих осях, Delphi Berlin Update 2.
 

Что конкретно печально в асинхронности клиента? На какой платформе? Если с примером - то вообще замечательно.
п.с. Еще раз повторю, что нареканий со стороны работы асинхронности не было замечено в течении года в нагруженном мобильном приложении на обоих осях, Delphi Berlin Update 2.
 

Легче и быстрее всего сделать свой стиль(и) TListBoItem, который содержит нужные вам контроллы и затем чисто добавлять новый элемент списка. делать солянку с фреймами или TVertScrollBox требует лишних телодвижений.

Вы наверняка меня не поняли, стоило использовать кавычки). Добавлять SDK можно, но это головная боль  с "напильником" в руках. Если вы считаете, что все классно - не стану переубеждать. На том же Xamarin подключить SDK займет пару минут. Пока не будет создано расширений для IDE и небольшого рефакторинга исходников -> использовать сторонние библиотеки будут вызывать негативные эмоции.
 
1. Да, используется, но это очередной костыль, который не ахти сказывается на скорости работы. 
2. Да, с 2016 года прекращен выпуск мобильных процессоров. Поэтому со временем этот пункт можно отметать.
 
п.с. Давайте соберем список действительно невозможных на сегодняшний день вещей.

Очередные холивары из разряда "мои проблемы никто не хочет решить за меня, значит Delphi плохой инструмент, давайте все перейдем в другую песочницу...". Минусы FMX есть и будут, от этого никуда не денешься, но в последнее время весь soft и продукты катятся в яму с кучей bugs даже от крупных компаний и корпораций даже спустя многие releases. 
Если на то пошло, то предлагаю все "невозможные" фишки периодически добавлять в первый пост и прикреплять решения, если они существуют.
Проблемы FMX  в следующем:
Жесткая привязка к версии SDK, возможно сделано целенаправленно, чтобы пользователи обновляли лицензии год за годом. Позволяет разработчику не углубляться в особенности операционной системы, и не меняя мышления клепать свой "первоклассно рабочий VCL стиль" код и тонны компонентов под все платформы. Пропаганда "возьмите свой старый код и сделайте мобильное приложение" - маркетологи, вы в своем уме? Отсутствие достойных плагинов для IDE. Тот же Cn Wizard давно пора включить по дефолту. Неужели сложно добавить плагин для создания wrappers для java классов сразу в IDE? Разве сложно загрузить приложение прямо в маркет без ручного копирования?  Отсутствует редактор manifest, plist как таковой. Вспоминается анекдот про танк и "доработать напильником". Многие достойные вещи делаются на голом энтузиазме сообществом, но почему-то только спустя много-много времени внедряются в коробку. Отсутствует нормальный debug на мобильных платформах, логами все не покроешь. Ограничения в ARM процессорах. Желание все хранить в .fmx, .dfm файлах, а не ссылками в ресурсы, как это принято в мобильной разработке. Это конечно обходится написанием своих менеджеров, но неужели сложно это продумать из коробки? Такое чувство, что пытаемся охватить как можно больше платформ по чуть чуть, чтобы кому-нибудь впарить свой продукт, а уже потом будем думать, как выкручиваться. FMX Canvas - ахиллесова пята. Не смотря на все это FMX является очень мощным инструментом и крайне приятным в умелых руках, если вы любите напильник (или мазохист). Средне статические проекты можно реализовывать не боясь, но для более серьезных вещей понадобятся знания нативной разработки, без этого никак. Если заказчик начинает разговор "я хочу такое, как в том-то приложении..." - значит без написания своей обертки или исправления исходников не обойдешься.
FMX в последнее время активно развивается и спустя Х лет все будет у нас превосходно, просто не бегите за новыми версиями, а подождите Update 3 или используйте предыдущую версию (Berlin Update 2 все еще в соку).
Другие кросплатформенные frameworks (Xamarin, Reac Native, RemObject, Native script, другие) тоже не лишены недостатков, но там слегка другие концепции и другая аудитория, кто лучше - покажет лишь время.

Очередные холивары из разряда "мои проблемы никто не хочет решить за меня, значит Delphi плохой инструмент, давайте все перейдем в другую песочницу...". Минусы FMX есть и будут, от этого никуда не денешься, но в последнее время весь soft и продукты катятся в яму с кучей bugs даже от крупных компаний и корпораций даже спустя многие releases. 
Если на то пошло, то предлагаю все "невозможные" фишки периодически добавлять в первый пост и прикреплять решения, если они существуют.
Проблемы FMX  в следующем:
Жесткая привязка к версии SDK, возможно сделано целенаправленно, чтобы пользователи обновляли лицензии год за годом. Позволяет разработчику не углубляться в особенности операционной системы, и не меняя мышления клепать свой "первоклассно рабочий VCL стиль" код и тонны компонентов под все платформы. Пропаганда "возьмите свой старый код и сделайте мобильное приложение" - маркетологи, вы в своем уме? Отсутствие достойных плагинов для IDE. Тот же Cn Wizard давно пора включить по дефолту. Неужели сложно добавить плагин для создания wrappers для java классов сразу в IDE? Разве сложно загрузить приложение прямо в маркет без ручного копирования?  Отсутствует редактор manifest, plist как таковой. Вспоминается анекдот про танк и "доработать напильником". Многие достойные вещи делаются на голом энтузиазме сообществом, но почему-то только спустя много-много времени внедряются в коробку. Отсутствует нормальный debug на мобильных платформах, логами все не покроешь. Ограничения в ARM процессорах. Желание все хранить в .fmx, .dfm файлах, а не ссылками в ресурсы, как это принято в мобильной разработке. Это конечно обходится написанием своих менеджеров, но неужели сложно это продумать из коробки? Такое чувство, что пытаемся охватить как можно больше платформ по чуть чуть, чтобы кому-нибудь впарить свой продукт, а уже потом будем думать, как выкручиваться. FMX Canvas - ахиллесова пята. Не смотря на все это FMX является очень мощным инструментом и крайне приятным в умелых руках, если вы любите напильник (или мазохист). Средне статические проекты можно реализовывать не боясь, но для более серьезных вещей понадобятся знания нативной разработки, без этого никак. Если заказчик начинает разговор "я хочу такое, как в том-то приложении..." - значит без написания своей обертки или исправления исходников не обойдешься.
FMX в последнее время активно развивается и спустя Х лет все будет у нас превосходно, просто не бегите за новыми версиями, а подождите Update 3 или используйте предыдущую версию (Berlin Update 2 все еще в соку).
Другие кросплатформенные frameworks (Xamarin, Reac Native, RemObject, Native script, другие) тоже не лишены недостатков, но там слегка другие концепции и другая аудитория, кто лучше - покажет лишь время.

Иконка изменится внутри приложения в рамах текущего контекста до ее завершения. С других приложений и в системе ничего не поменяется (см. прикрепление).
Чтобы не влиять на другой функционал, достаточно сделать следующее:
//запоминаем ид по умолчанию lDefaultId := TAndroidHelper.Context.getApplicationInfo.icon; //устанавливаем нашу кастомную иконку TAndroidHelper.Context.getApplicationInfo.icon := lId; //создаем локальное уведомление NotificationCenter.PresentNotification(lNotification); //возвращаем обратно TAndroidHelper.Context.getApplicationInfo.icon := lDefaultId; п.с. Если такой вариант не устраивает, всегда можно написать class helper for TBaseNotificationCenter и использовать классы JNotificationCompat_Builder, JNotificationManager, JNotification. Справка из developer.android.com.

Мне кажется вся проблема в том, что идет удаление объекты до окончания операций. Учитывайте, что процесс выполняется асинхронно:
begin //тут лишь создается поток, в котором выполняется запрос lHttp.Post(Url, lSendData); Result := ''; end; // Result := lResponse.StatusCode = 200; finally //вот здесь ошибка. Нельзя удалять объекты, если действие еще не завершилось. Вы можете узнать об завершении прцоессса в событии OnRequestCompleted lSendData.Free; lHttp.Free; end;  
 

Посмотрел ваш пример, все зависания и вылеты с ошибками связаны с обращением к пустым объектам, попыткой обработать все в одном обработчике. Исправить клиент дело не благодарное, поэтому сделал пример по работе с TCP сокетом с возможностью автоподключения (тык). Проверил на нескольких устройствах, полет нормальный.
Основные замечания:
Не используйте FormActivate событие, тем более на мобильной платформе. Его обработка замораживает приложение. В примере посмотрите вариант обхода. TIniFile нет смысла использовать каждый раз для считывания настроек. 1 раз считали при старте приложения и больше к файлу не обращаемся. Хранить настройки в компонентах (edSettingHost.Text и т.п.). Создание свойства отнимет максимум минуту, а выгоду даст существенную. TCP сокет соединения следуют принимать как асинхронные, а не как запрос-ответ. Это предусматривает получение команды сервером, какое-то выполнение и лишь потом отправка на клиент. Поэтому попробуйте отказаться от использования GetFromServer. Сервер только запускал для проверки клиента, пару раз ловил outofmemory и access violation, закрыться тоже не захотел по-хорошему. Поэтому желательно его тоже довести до ума.

Посмотрел ваш пример, все зависания и вылеты с ошибками связаны с обращением к пустым объектам, попыткой обработать все в одном обработчике. Исправить клиент дело не благодарное, поэтому сделал пример по работе с TCP сокетом с возможностью автоподключения (тык). Проверил на нескольких устройствах, полет нормальный.
Основные замечания:
Не используйте FormActivate событие, тем более на мобильной платформе. Его обработка замораживает приложение. В примере посмотрите вариант обхода. TIniFile нет смысла использовать каждый раз для считывания настроек. 1 раз считали при старте приложения и больше к файлу не обращаемся. Хранить настройки в компонентах (edSettingHost.Text и т.п.). Создание свойства отнимет максимум минуту, а выгоду даст существенную. TCP сокет соединения следуют принимать как асинхронные, а не как запрос-ответ. Это предусматривает получение команды сервером, какое-то выполнение и лишь потом отправка на клиент. Поэтому попробуйте отказаться от использования GetFromServer. Сервер только запускал для проверки клиента, пару раз ловил outofmemory и access violation, закрыться тоже не захотел по-хорошему. Поэтому желательно его тоже довести до ума.

Можете мне сделать тестовый сервер и клиент, чтобы я смог у себя проверить? Тогда мой ответ будет более детальным. А пока:
Какой вы объем данных шлете по соединению? Чем вызвана потребность использовать именно сокеты? TimeOut  никогда не ставьте большими. Indy работает по принципу блокировки сокета и всего потока в целом. Поэтому большое значение = зависание всего приложения = нежелательные результаты и зависание. Я ставил 100 мс для работы с маленькими пакетами. С такой задержкой доп. поток не обязателен. Если значения более 500 мс - нужно создавать отдельный поток и работать с сокетами в ней + синхронизация при обработке / отправке данных. TIdTCPClient на Andoid любит спать и не проверять входящий буфер. Поэтому вручную нужно вызывать по таймеру проверку типа: procedure T<какое-то имя класа>.Read; var sz : integer; lMsg : string; begin try TMonitor.Enter(Self); try if not Assigned(Client.IOHandler) then Exit; //Client = TIdTCPClient if Client.IOHandler.InputBufferIsEmpty then begin if not Client.IOHandler.CheckForDataOnSource() then exit; end; sz := Client.IOHandler.InputBuffer.Size; if sz <= 0 then exit; lMsg := Client.IOHandler.InputBuffer.ExtractToString(-1, IndyTextEncoding_UTF8); Client.IOHandler.InputBuffer.Clear; <какой-то обработчик входящего сообщения>; except on e : Exception do <какой-то обработчик ошибки>; end; finally TMonitor.Exit(Self); end; end; AntiFreeze - это мягко говоря "костыль" от Indy, использование его плохая практика. На мобильной платформе вряд ли он появится, хотя и реализуется не сложно.