Лидеры

BeginUpdate и EndUpdate приносят счастье

логика должна быть такой в главном потоке запускаем индикатор и доп. поток. При окончании работы доп. поток например в событии OnTerminate прячет индикатор. Всё. Если есть прямо жестокая необходимость, чтобы доп. поток как-то отчитывался о прогрессе, пусть отправляет сообщения в главный поток. Никаких других знаний друг о друге у обоих потоков быть не должно. Это идеальная универсальная схема. Ессн бывают всякие обстоятельства, но в целом она рабочая всегда. подробнее я писал об этом тут

Ну вот набросал примерчик. Он упрощенный, но смысл такой же примерно (код листвью со скриншота выше выложить не могу просто из-за того, что там идут зависимости от модели данных). Лично я все рисую кодом - так полный контроль того, что выводится на экран. И собственно так можно выводить практически что угодно. И не нужны никакие монструозные ТМС компоненты ListView_Schedule_Sample.zip

Дам вам подсказку из Android доков... public String getDeviceId () Added in API level 1 Returns the unique device ID, for example, the IMEI for GSM and the MEID or ESN for CDMA phones. Return null if device ID is not available. Requires Permission: READ_PHONE_STATE public String getDeviceId (int slotId) Added in API level 23 Returns the unique device ID of a subscription, for example, the IMEI for GSM and the MEID for CDMA phones. Return null if device ID is not available. Requires Permission: READ_PHONE_STATE Parameters slotId of which deviceID is returned

а для Android: Uses Androidapi.JNI.Telephony, Androidapi.JNI.JavaTypes, Androidapi.Helpers, Androidapi.JNI.GraphicsContentViewText; function TfMain.GetMyImei: string; var TelephonyObj: JObject; TelephonyManager: JTelephonyManager; begin Result := ''; TelephonyObj := SharedActivityContext.getSystemService(TJContext.JavaClass.TELEPHONY_SERVICE); TelephonyManager := TJTelephonyManager.Wrap((TelephonyObj as ILocalObject).GetObjectID); Result := JStringToString(TelephonyManager.getDeviceId); end;

IOS не позволяет получить IMEI устройства.