Лидеры

Задачу решил. Вот измененная процедура, ну и добавил вытягивание параметра sound private Builder buildNotification(String msgTitle, String msgText, String msgSound, 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); // savage if (msgSound == "") { mBuilder.setSound(RingtoneManager.getDefaultUri(2)); } else { mBuilder.setSound(Uri.parse("android.resource://" + this.mContext.getPackageName() + "/raw/"+msgSound)); } // return mBuilder; } Звуковой файл надо добавить в Deployment Расположение res/raw/ При формировании push-сообщения имя файла указывается без расширения. К примеру, если звуковой файл был event1.mp3, то в пуше посылаем "sound":"event1" Во вложении патченый файл. Сборка fmx.jar и classes.dex как в этой теме NotificationPublisher.zip

Нашел место, отвечающее за не правильную реализацию звука в 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

В копилку знаний. Напишу как решил задачу. Может кому-то будет интересно. Таких как мне надо параметров у MediaPlayer'a конечно нет. Но есть свойство VideoSize.X и Y там можно посмотреть реальный размер воспроизводимого видео в пикселях. Берем эти значения, делим высоту на ширину и выясняем астект (соотношение сторон). После чего берем ширину контейнера в котором отображает видео на форме и умножаем на этот аспект. Получаем нужную высоту контейнера. В итоге если у вас контейнер видео с привязкой Top, Bottom то его размер всегда будет пропорционально равным размеру проигрываемого видео-файла, что избавит от ненужный черных рамок.

да нет, все правильно. целевой sdk можно указывать любой для которого обеспечена совместимость. а вот минимальный зависит от того на какой версии он будет запускаться. но при этом вы гарантируете работу программы на sdk от минимальной до целевой.

Выше правильно написали о глюках в Tokyo под Android. Также учтите, что событие таймера, также как и анимации, обрабатываются в главном потоке. При этом вы задали достаточно маленький интервал для таймера. Поэтому, лучше перенести действия над визуальными компонентами за пределы таймера (если они там есть), а сам таймер сделать на основе потоков.

Токио сам по себе довольно глючный, особенно до обновления 10.2.3 там и без таймера баги с анимацией, эффектам и низким FPS на ровном месте, в этом случае лучше Берлин использовать (что я и делаю под Android и iOS (Xcode 9 btw) ).

Абсолютно неправильное понимание. Гугл анализирует minSdkVersion и targetSdkVersion не для того, чтобы запрещать публикацию apk в google play, а для того, чтобы: 1. ограничить установку apk на устройства с sdk, меньшей чем minSdkVersion - т.е. если например minSdkVersion="18", то на Android ниже 4.3 гугл плей не даст установить 2. использовать на устройстве sdk наиболее приближенной к targetSdkVersion (но не превышая) - т.е. если например targetSdkVersion="23", то на Android 4.3 будет использовать sdk 18, на android 8.1 - sdk 23

на iOS свой звук подбрасывается норм. На Андроиде скорее всего печаль

Не, оказывается я ошибся еще больше. Чтобы окончательно выяснить - залез на https://msdn.microsoft.com/ru-ru/library/windows/desktop/ms644906(v=vs.85).aspx USER_TIMER_MINIMUM (0x0000000A), - минимально возможный интервал = 10мс. Но это недостижимый идеал :)))

Графические движки не пользуются таймерами, это чревато гигантскими лагами. QueryPerfomanceCounter и т.п.

Ни одна операционная система (за исключением систем реального времени) не обеспечит вам такую точность. Среда разработки здесь ни при чем. Совсем. К примеру, на Windows минимально возможный интервал таймера, емнип, 55мс. При этом нужно понимать, что событие таймера сработает только тогда, когда главный поток не будет ничем занят. А это, поверьте, случается достаточно редко. Грубо говоря - событие отработает "по остаточному принципу". Т.е. в реальности даже 55мс на Windows будет обеспечено далеко не всегда. Что уж говорить про мобильные платформы. Вам нужно пересмотреть алгоритм работы.

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

ну вы же не 1Сник чтобы кириллицей писать, не надо извращении. пишите латиницей, хоть транслитом если угодно

Спасибо за труд! Ковыряю сейчас тему изменения звука в push-уведомлении. И, судя по всему, надо патчить этот же исходник.

Есть смысл переходить с 10.2.2 на 10.2.3? Народ тут писал, что студия вылетать стала на ровном месте. А судя по чейнж логу ни одного серьёзного бага поправлено не было. Во-первых интервал в 1мс для таймера не достижим без специальной настройки ОС. Реально события будут приходить 10-23мс. И это при условии, что программа больше ничего не делает. Это не зависит от дельфи, а зависит от винды. Во-вторых "накладные расходы" таймера при таком обновлении - это основная статья расходов процессора. И вообще так писать - это просто жесть. Любая анимация - это 1000/60мс т.е. частота обновления среднестатистического монитора. И то лучше 1000/30 или 1000/25. Меньше плавности на чуть, зато будет реально работать. Если нужна не анимация, а рассчёт чего-то - это надо выносить в отдельный поток. Если речь идёт про андроид/яось, то кроме нескольких деталей в целом ситуация не меняется. Писать так нельзя.