krapotkin

услышьте plz. в токио перешли на "правильную" работу в едином потоке с Java. Вообще это хорошо. Но вся FMX писалась в расчете на старую модель. А теперь те фишки не работают )))
когда поменяют - ХЗ
поэтому универсальный ответ - смотрите как это сделано в исходниках, например у TAnimation там все понятно. ProcessMessages точно не будет работать больше. Наконец-то г"внокод умрет. Аллилуйя.
Чтобы ответить на вопрос, как часто может быть вызван таймер, надо не срач на форуме устраивать а просто попробовать. И станет ясно, что 1000 fps не получить. И 100. Возможно, при попутном ветре, 10.

Нашел место, отвечающее за не правильную реализацию звука в NotificationPublisher.java
private Builder buildNotification(String msgTitle, String msgText, PendingIntent contentIntent) {
        int icon = this.mContext.getApplicationContext().getApplicationInfo().icon;
        Builder mBuilder = new Builder(this.mContext);
        mBuilder.setSmallIcon(icon);
        mBuilder.setTicker(msgTitle);
        mBuilder.setContentTitle(msgTitle);
        mBuilder.setContentText(msgText);
        mBuilder.setContentIntent(contentIntent);
        mBuilder.setSound(RingtoneManager.getDefaultUri(2));
        return mBuilder;
    }
Виноват mBuilder.setSound(RingtoneManager.getDefaultUri(2));
буду править и пересобирать fmx.jar
 
 

трудно придумать что-то, что может успеть выполниться менее чем за 1 мсек на десктопе, а на мобильном и подавно
так что вы немного остудите жар-то ))

стиль нужно менять для каждой системы индивидуально. но основой стиля является большой PNG из которого тащатся картинки для контролов
а его перенести в другой стиль несложно

я давно говорил, что использование Button.Click(); это беда. При появлении FMX это стало невозможно, и многие плакали. Но вещь правильная
Так же давно я всяко боролся с Application.ProcessMessages. Теперь они по факту запрещены ))) Тенденция, аднака ))))

не надо ничего включать. сделаете только хуже код. выносите в отдельный поток. 

В чате проскакивал вопрос по пушам в 10.2.3. Ярослав говорил, что забыли "положить" в новом релизе какую-то либу с сервисами гугла. Может быть и карты на этой либе завязаны...

FMX будет развивать Embarcadero т.к. это и есть их продукт
FGX будет жить отдельно, пока эмро не сочтет его "убийцей айфонов" и не перекупит на корню. А до этого еще ох как далеко

FMX будет развивать Embarcadero т.к. это и есть их продукт
FGX будет жить отдельно, пока эмро не сочтет его "убийцей айфонов" и не перекупит на корню. А до этого еще ох как далеко

не в качестве спора, просто мысли по поводу на основании своего опыта
1. тормоза при старте скорее ваши, чем FMX. Моя программа стартовала абсолютно сравнимо с любыми приложениями на этом же телефоне.
Первая форма была простой как мычание. Картинка и кнопка на ней. 
2. Наверное, многое зависит от конкретики. Я на берлине добился вполне адекватного поведения. Охватом китайцев похвастаться не могу, но в основном все работало как минимум предсказуемо.
3. сервисы и на новых телефонах, например на моем Xiaomi, не превратят телефон в трекер, ибо будут нещадно тормозиться и прибиваться системой. поэтому надеяться на этот функционал можно только при запущенной программе

почему-то самое важное не зашло
теперь Mobile Pack вошел в Professional

почему-то самое важное не зашло
теперь Mobile Pack вошел в Professional

если прямо много всего, то проще сделать "фреймворк"
описание заводим, а едиты, валидация и загрузка-выгрузка данных создаются динамически

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

для полноценной подсказки и на windows и на android я в критических местах добавляю малую кнопку с вопросиком ))

в любом контексте это плохой стиль.
то что он в оф примерах это еще хуже

в любом контексте это плохой стиль.
то что он в оф примерах это еще хуже

в любом контексте это плохой стиль.
то что он в оф примерах это еще хуже

сценарий
1. пока не вернется последний запрос (или вылетит таймаут) работать нельзя. поэтому запускаем анимацию, контролы дизейблим
2. запускаем нужное количество потоков с запросами на каждый комбобокс
3. при возвращении потока мы уже в главном потоке (например через OnTerminate) а) заполняем структуру с данными или сам комбо б) проверяем все ли потоки  вернулись
если все вернулись  - приводим страницу в рабочее состояние
если произошел таймаут - говорим, что не удалось
 

не вижу разницы

может, так
http://www.cyberforum.ru/delphi-beginners/thread2193827.html

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

Очередные холивары из разряда "мои проблемы никто не хочет решить за меня, значит 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, другие) тоже не лишены недостатков, но там слегка другие концепции и другая аудитория, кто лучше - покажет лишь время.

это абсолютно аналогично тому, что показал Равиль.
когда не хочется создавать класс-потомок TThread

Если пытаться кормить json парсер кривым json и ожидать, что почему вдруг объект станет неожиданно массивом и не будет исключений, то таких парсеров вам не найти. Проще написать самому: быстро, дешево, без 100500 классов и исключений. И такой, который будет считать, что {} - это массив.
А вообще, рекомендую начать с http://www.json.org/
Возможно, после этого придет понимание того, почему нужно то или иное количество классов, ну или хотя бы вы сами разберетесь и поймете, почему так происходит.