Yarpda

С MinSDK все понятно. С TargetSDK "не все так однозначно". Ставится она не средой разработки, а руками в манифесте и никто этого не проверяет. Может быть это и нормально, но для меня как начинающего программиста на Андроид это немного смущает. Хотя по идее этот SDK влияет на поведение программы на конечном устройстве. Таким как раз я и хотел бы идеть поведение среды разработки. А сейчас мы как и можем поставить любую ТаргедСДП, хоть 28-ую, хотя в действительной поддержки этого SDK в приложении нет. И ни Emb, ни Market никак на это не реагирует. В общем для меня этот подход весьма странен. Хотя может я чего-то и не понимаю...

Ага, видимо по-этому Эмбаркадеро ставит в MIN и TargetSDK только 14 и не дает менять в настройках проекта. Чтобы обеспечить поддерживаемую совместимость. )) А если хочешь, то ты конечно можешь в манифесте руками поменять, но мы дальше не причем. (Интересно как они будут выходить из этой ситуации в связи с новой политикой Google про TargetSDK). Мне кажется как должно быть: миниальное СДК ты ставишь, а TargetSDK ставит система в зависимости от того на какой версии SDK был действительно собран этот пакет. (Кстати я уже столкнулся с проблемами с MediaPlayer при ручной смене TargetSDK более 17). А как быть тем кого Гугл заставит поменять ТаргетСДК в скором времени? Ну как понять. Когда закидываешь APK на Маркет, Гугл анализирует содержание пакета. По-идее он мог бы и проверять под каким SDK собран пакет и какой стоит в TargetSDK и говорить о несоответствии и запрещать публиковать такие APK. Но он этого не делает, поэтому можно собрать под любым SDK и в манифесте руками поставить любой и все пройдет, а действительную совместимость никто не проверяет. Вот что я имел ввиду.

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

Полагаю, что "программно нажать" не получится. Я когда-то давно решал подобную задачу под Win обработкой вводимого значения в onChange (в мобильном есть событие OnTyping - оно наверное лучше будет). Берем набранный текст в переменную, анализилируем на пробел и первый следующий символ, если символ в нижнем регистре, меняем на верхний и закидываем подмененный текст в поле ввода, ставим курсор в конец. пользователь при этом ничего не заметит, просто буква станет большой. Или уже обрабатывать все поле, после окончания ввода (но тогда надо будет объяснить пользователю что вводить можно маленькими, он сам потом сделает как надо). Можно наверное и OnKeyUp поиграться с подменой отдельных символов, но как оно в мобильном будет работать не знаю, но в теории должно...

Ну почему же бред. В настройках SDK делфи стоит ссылка на 23 SDK. В Манифесте руками правлю на любой от 14 до 28. Все собирается. В маркет заливается. Или я, что-то не так делаю?

Тут то как раз вопрос, это на что-то может повлиять (исправление, например исправление ошибок, которые были в прошлых SDK, а в новых типа нет. Или может быть компоненты по другому как-то начитают выглядеть и т.д.). А TargetSDK можно прописать какой-хочешь вручную и собрать под каким хочешь... И Google play это никак не ловит. А версия NDK например на что-то влияет или вообще можно не обращать на это внимание?

Экспериментальным путем выяснено, что TMediaPlayer под Андроид начитает гораздо менее стабильно работать (по крайней мере с видео) если в манифесте MinSDKVersion или TargetSDKVersion стоит больше 17. Обычно глюки проявляются при открытии новых файлов, или закрытии форм, на которых размещен MediaPlayerControl. У меня вплоть до видео-артефактов доходит, когда закрываешь форму, на которой проигрывалось видео. В портретном режиме через раз, а в ландшафтном - почти постоянно (в зависимости от формата воспроизводимого файла). Иногда не вылетает, а просто дико артефачит (жаль скрин снять не получилось, т.к. система во время артефактов не отвечает). Формат после 2-3 секунд закрывается, но то место где на закрытой форме находился MediaPlayerControl на другой форме перестает отвечать на нажатия, область где контейнера не было - на нажатия реагирует. В общем тихий ужас. Проверялось на нескольких устройствах (телефон (андроид 6.0) и планшет (адроид 4.4.2)). Ставишь TargetSDK- 18 и выше, - постоянные глюки. Ставишь 17 и ниже (14 - по умолчанию) - полет нормальный. Закономерность четкая и стабильная, проверял раз 15. Пробовал каждую версию SDK. С чем связано не знаю. Пост просто так, в копилку знаний, возможно кто-то тоже сталкивается с подобными проблемами (я полтора дня потерял, выясняя почему перестало работать, хотя вчера работало и в коде особо ничего не менялось).

Google постоянно обновляет и выпускает новые SDK. Хотелось бы для себя прояснить есть ли смысл собирать свой пакет в самых последних версиях SDK. Есть ли в случае FMX разница под каким SDK и NDK (настройки SDK Manager) собрано приложение? И если есть то какая?

По началу MediaPlayer был на форме, которая создавалась динамически. Но там глюки были и на нормальных машинах, поэтому от такой реализации пришлось отказать. Как временный выход - перенес его в датамодуль и использовать только один экземпляр MediaPlayer, плюс доработки напильником при закрытии формы нужно было делать. В конце концом более менее приемлемый вариант получился. На машине с 3 гб Ram нормально. Где 1 гб - пару раз открытий видео и вылет (хотя это конечно и от версии андроида зависить или еще от чего-то).

Вопрос такой: Есть видео, которое проигрывается, оно может быть разных размеров (3:4, 16:9 и т.д.). Контрол на котором воспроизводится видео изначально фиксированного размера. От этого получается в одних видео обрезки по краям, что не очень красиво. Хотелось бы сделать так чтобы контрол сам менял свои размеры (по вертикали) в зависимости от того какого формата кадра видео воспроизводится.Для этого нужно знать какую реальную область на контроле занимает сам "квадрат" видео. . Есть идеи как это можно сделать? Delphi 10.1

Up темы. Подскажите куда копать. На новых устройства с большим объемом памяти еще куда ни шло, но на старых, вылеты почти сразу наблюдаются.

Подскажите, существуют ли в FMX механизмы работы с файлами расширений (OBB)? В андроид SDK есть возможность скачать этот библиотеку (Google play APK Expansion library), но как ее использовать в FMX проекте никакой информации нет. Подскажите кто-то уже сталкивался с такой проблемой? P.S. для справки: APK Expansion file можно загрузить в Google Play, если размер APK превышает 100 мб. Данный файл представляет из себя архив с расширением obb, который содержит дополнительных контент приложения. Автоматически помещается помечается в папку androind/obb/<project_name>/file.obb.

Уже второй час бьюсь, не могу получить путь к папке android/obb своего проекта. Уже и TPath облазил и AndroidApi.IOUtils в них ничего про obb нет почему-то. Есть ли такая функция? Подскажите пожалуйста.

LB можно сделать каким угодно, наверное даже сразу с TEdit (сам правда не проверял, более опытные форумчане поправьте меня, если я ошибаюсь), но это надо знать как со стилями работать. В целом там ничего сложного (на форуме даже есть видое-курсы по этому поводу, но к сожалению платные...). Имхо без понимания принципа работы со стилями в FMX довольно сложно, хотя и можно... но в итоге лично у меня вышло, что пришлось городить огород из 3 страниц кода, чтобы нужные данные в LB выводить, а в итоге оказалось, что можно было тоже самое 5 кликами мышки сделать в дизайнере стилей...

Мое мнение, что TEdit Должен быть 1 напротив него кнопка добавить (лучше в виде иконки нативной какой-нибудь). При ее нажатии, информации из TEdit Уходит в TListBox (чтобы человек видел, что он уже добавил). Как вариант, если нужно исправить щелкаем по строке LB, и данные из itema попадают в тот-же TEdit для исправления. Человек исправил, нажал на галочку, измененные данные ушли в TListBox. А в листбокс можно напихать сколько угодно, у него свой скрол если что есть.