Tumaso

Размер apk/ipa как раз не главное, пусть хелловорд хоть 50 мб весит. Главное чтобы все быстро и надежно работало. Ждем вебинара.

Может поувольнять нахрен всех индусов и отдать разработку в Россию? ))

Потому что фрейм это обычный TControl

Application.ProcessMessages может и плоха, в FMX в принципе не использую, но вот в VCL помогает решить проблемы с перерисовкой)))

Асинхронность работает надежно даже в андроид Вопрос в другом - каким образом вы будете непосредственно заполнять комбобоксы загруженными списками. тут либо с использованием synchronize либо через внутренние списки в потоках (откуда главный поток по готовности сам заполняет комбобоксы)

Токио умеет работать с XCode 9, берлин же только с 8.0, а с 8.1 и 8.2 уже проблемы. И это критично.

При онлайне 10 человек точно не упадет, подобные высказывания бред))). Вот 10 тысяч в онлайне один сервер может и не потянуть.

Используй библиотеку LiteDAC вместо UniDAC того же разработчика, там включаешь режим Options.Direct := True и внешние библиотеки использоваться не будут

Определяй, не перекрывается ли активный TEdit клавиатурой. Если перекрывается, то смещай все едиты вверх, чтобы было видно, в какое поле и что вводишь. Я бы разместил все TEdit например на TRectangle, ловил событие FormVirtualKeyboardShown, определял размеры перекрываемой области и в случае необходимости двигал TRectangle. А на событие FormVirtualKeyboardHidden возвращал бы все назад. Тут только есть нюанс - FormVirtualKeyboardShown не всегда вызывается с правильными размерами (Эмбе над этим еще видимо долго работать))) ), поэтому нужно отдельно хранить правильное значение размеров клавиатуры (оно возвращается при первом вызове FormVirtualKeyboardShown)

Да ты, батенька, оптимист. Большинство терминалов и кассовых ПК работают на винде XP )))

TMS Crypto не работает в эмуляторе ios, поэтому например в нашем проекте без реального iphone никак

Не требуется

Делфи не хватает большого количества примеров из коробки, с решением как можно большего количества возникающих задач при разработке. С этим у Эмбы беда.

Подниму тему - для текущей версии Tokyo 10.2.2.2004 до какого NDK с r9c можно обновиться или токио так и работает только с r9c?

Код также пишешь, как пишешь на русском языке?

Изменить главную форму можно простым Application.MainForm := fmMain;

На iOS при деплое сталкивался с проблемой, что если хотя бы у одного файла указано Startup\Documents\ вместо StartUp\Documents\, то не деплоятся ВСЕ файлы.

да, согласен именно так, только замените TNetHTTPClient на THTTPClient

DMS, простейший пример (без обработки эксепшенов) отдельного класса на базе TThread: В основном потоке создаешь нужное количество экземпляров (можно начать с одного), запускаешь, потом при необходимостии передаешь команду на выполнение/получаешь ответ выполненной команды. например так (простейший пример): LThread := TAsyncHttp.Create; LThread.Start; LThread.Command := 'http://www.site.com/data?param=value'; while not LThread.IsReady do Sleep(1);

Если ты сам руками удаляешь компоненты, то правильнее их будет создавать так: control := TEdit.Create(nil); control.Parent := parent; уничтожаю контролы через .DisposeOf (но с таким способом уничтожения согласны не все)

А меня System.JSON полностью устраивает. Ошибок парсинга валидных данных не было ни разу, скорость на нормальном уровне. Гигабайтные данные правда не парсирую, но мне это и не нужно

Равиль, я так понимаю, что вы внесли изменения в стандартный ListView. Скажите плиз, в какой версии делфи взят исходник? берлин? Я это к тому, что при переходе на токио ModernLV нужно будет заново сливать с оригинальным исходником, правильно? Сорри за кучу знаков "вопрос"

Отвечу сам себе - Apple не считает нужным давать сторонним разработчикам доступ к чтению СМС, поэтому ответ на мою проблему прост - легально СМС на iOS считать невозможно. Можно извернуться и все таки считать смски, если использовать джейлбрейк. Но это не мой путь))

Подскажите, каким образом можно прочитать входящее СМС под iOS? Для Android на форуме есть работающий пример, а вот под iOS найти не удалось.

А не забивает ли память вызов этого метода, а не StringToJString?