Перейти к содержанию
Fire Monkey от А до Я
  • 0

Что невозможно сделать на Delphi для Android?


Вольдемар

Вопрос

Рекомендуемые сообщения

  • 0
3 минуты назад, x11 сказал:

 

И это, хотите сказать, что на FMX написано?

в интерфейсной части ничего особо сложного нету...

я б только посмотрел как кнопка поиска реализована. как она реагирует на нажатие. есть анимация или какая-нибудь трансформация?

Изменено пользователем sinuke
Ссылка на комментарий
  • 0
7 часов назад, Fedor K сказал:

Пропаганда "возьмите свой старый код и сделайте мобильное приложение" - маркетологи, вы в своем уме?

частично это работает

Ссылка на комментарий
  • 0
21 минуту назад, sinuke сказал:

в интерфейсной части ничего особо сложного нету...

я б только посмотрел как кнопка поиска реализована. как она реагирует на нажатие. есть анимация или какая-нибудь трансформация?

есть

Ссылка на комментарий
  • 0
  • Модераторы
2 часа назад, sinuke сказал:

в интерфейсной части ничего особо сложного нету...

я б только посмотрел как кнопка поиска реализована. как она реагирует на нажатие. есть анимация или какая-нибудь трансформация?

ну ты то мастак по интерфейсным решениям и костылям (сделать из ЛВ - РичЕдит, трансформации кнопок из андроида повторить, табы с тачем. Из того что помню)

Ну ничего скоро надоест и ты уйдешь в АС:D 

Ссылка на комментарий
  • 0
26 минут назад, Равиль Зарипов (ZuBy) сказал:

ну ты то мастак по интерфейсным решениям и костылям (сделать из ЛВ - РичЕдит, трансформации кнопок из андроида повторить, табы с тачем. Из того что помню)

Ну ничего скоро надоест и ты уйдешь в АС

ну я ж не виноват, что ЛВ такой удачный и быстрый)) ну а по поводу АС... ну уже начал ковырять. посмотрим что из этого выйдет ))

 

Ссылка на комментарий
  • 0

 

1 час назад, DMS сказал:

а сделайте плиз крупнее скриншот

продублирую сюда свое "исследование"

Скрытый текст

Провел я эксперимент с ресурсами и деплоем. Создал 20 файлов по 10 Мб каждый (заполнены случайными байтами). В первом эксперименте поместил я эти файлы в ресурсы, при этом убрал галочки в деплойменте. Сборка Release, в остальном приложение пустое. Телефон Xiaomi MI A1 c Android 8 Oreo, 4 Gb RAM, Snapdragon 625. Результат - 0.99 секунды (до убратия сплеша). Во втором случае убрал все файлы из ресурсов и просто добавил в деплоймент в папку .\assets\internal\. Результат в этом случае получился 0.88 секунды. Разница в 0.1 сек. Честно, не знаю. Вполне возможно это погрешность того, как я нажимал на кнопку пуска таймера. Поэтому можно сделать вывод, что разницы в данном случае нет. Может быть на другом, более медленном устройстве разница будет более существенной, но на моем ее нет. Разница имеется только во времени билда проекта - если файлы помещены в ресурсы, то билд происходит значительно дольше

На видео заснял то, как проводил тест

П.С. т.к. моя специализация метрология, то прекрасно понимаю, что для более достоверных результатов нужно провести гораздо большее кол-во тестов. но лень )))

еще замерил потребление памяти

5a9575e80910d_(4).thumb.png.b801bdcd053310bff323e6653254743d.png

потребление памяти, когда файлы находятся в деплое - 53 Мб

5a9575ea2c5d6_(5).thumb.png.b1bda79c9e78c2376251afcf82776d67.png

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

photo_2018-01-10_20-52-44.jpg

замерял не первый запуск. а 2-3

 

 

 

Изменено пользователем sinuke
Ссылка на комментарий
  • 0
21 час назад, ENERGY сказал:

 

1. Нет жесткой привязки, можно использовать последний SDK. Есть рекомендуемый SDK, с которым EMBT протестили студию.

2. Абстракция это наоборот огромный плюс

6. А что не так сейчас отладкой? Под Android медленно согласен, но она работает, под iOS вполне быстро. 

7. Какие ограничения ARM?

8. Не совсем понял в чем тут проблема для финального результата.

 

1. Да, мы можем подключить новую версию SDK, но все обертки в исходниках остались старые. В итоге: поменял SDK -> заменил обертки -> наслаждаешься новыми "фичами" + количество оберток не резиновое.

2. Абстракция огромный плюс, когда инструмент доведен до идеала. В данный момент имеет плохую оптимизацию работы самого FMX + подарки от разработчиков = "у меня лагает" или "это валится с ошибкой, такого быть не может, на винде работает" и т.д.

6. Попробуйте отладку любого TJavaGenericImport класса, а потом возьмите этот же Java класс и посмотрите, что доступно при отладке в Android Studio.

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

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

+ к этому: Крайне не удобно поддерживать версионность, когда требуется замена картинок. Если хранить только относительный путь в ресурсы - это делается с легкостью.

В 05.11.2017 в 20:03, Вольдемар сказал:

Давайте в этой ветке соберем список невозможного (пока?) на Delphi для Android.

1. Невозможно сделать widget 

1. Сервисы тоже вряд ли можно назвать рабочими, но маркетологи с этим крайне не согласны. Поэтому согласно этому мы также можем запихнуть .jar классы widgetа в приложение и потом написать такую же оберку, как для сервисов и вызывать delphi код, но затраты не совместимы.

2. "Невозможно" сделать провайдер клавиатуры для системы. 

3. Невозможно скачать стороннее SDK и использовать в своем приложении. Для FMX их никто не делает и делать не собирается. Хотим Facebook SDK -> запаситесь терпения и сделайте все сами или делайте обходные пути.

Ссылка на комментарий
  • 0
8 часов назад, Fedor K сказал:

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

У меня знакомый на андроид студио пишет. Корпоративная прога какая-то. У него из 4000+ установок 1 или 2 установки - это устройства с процессором от Intel. Это 0,025% получается?

Ссылка на комментарий
  • 0
8 часов назад, Fedor K сказал:

1. Сервисы тоже вряд ли можно назвать рабочими, но маркетологи с этим крайне не согласны.

У меня сервис: определение номера телефона (Broadcast reciever) работа с sqlite, Toast. Пока что очень мало устройств, где я это протестировал на на моём android 5 норм.

Ссылка на комментарий
  • 0
8 часов назад, Fedor K сказал:

3. Невозможно скачать стороннее SDK и использовать в своем приложении. Для FMX их никто не делает и делать не собирается. Хотим Facebook SDK -> запаситесь терпения и сделайте все сами или делайте обходные пути.

Я уже писал - замкнутый круг. И, частично, из-за тех, кто кричит, что Delphi/FMX - отстой и с Delphi надо убегать, и что Delphi умирает. А вы наоборот - популяризируйте Delphi + FMX, пусть больше народа подсаживается.

Ссылка на комментарий
  • 0
В 25 февраля 2018 г. в 02:29, ENERGY сказал:

Нет как раз таки. Berlin Update 2 более стабильный и там меньше багов FMX чем в Tokyo. В Токио от одного бага со сменой главного потока целая эпопея, с потерей производительности и проблем с анимацией - много что посыпалось. Была, а может еще и будет.  Некоторые программисты с форума EMBT вообще считают Токио самой неудачной версией Delphi, в плане багов за всю ее историю.

Проверил эту гипотезу. На предмет глюков  RAD Studio 10.1 Berlin Update 2 с TThread.Synchronize. Эта проблема меня больше всего волнует из всех под win, остальные я уже почти все обошёл так или иначе. Для чистоты эксперимента взял виртуальную машину, образ скаченный с сайта эмбы и всё. Ничего стороннего не ставилось.

Результат печален.  Один и тот-же проект, под 10.2 стандартные падения в стандартных местах, где-то 1 раз из 4-х, может чуть реже. Берлин падает каждый раз при выходе, после использования синхронайза, плюс в процессе работы падения 1 из 3 или даже 1 из 2. В общем Токио ГОРАЗДО стабильнее работает с много поточностью.
 

P.S. Запускалось естественно всё на одной машине, под одним пользователем.
 

Изменено пользователем Akad
Ссылка на комментарий
  • 0
1 час назад, Akad сказал:

Проверил эту гипотезу. На предмет глюков  RAD Studio 10.1 Berlin Update 2 с TThread.Synchronize. Эта проблема меня больше всего волнует из всех под win, остальные я уже почти все обошёл так или иначе. Для чистоты эксперимента взял виртуальную машину, образ скаченный с сайта эмбы и всё. Ничего стороннего не ставилось.

Результат печален.  Один и тот-же проект, под 10.2 стандартные падения в стандартных местах, где-то 1 раз из 4-х, может чуть реже. Берлин падает каждый раз при выходе, после использования синхронайза, плюс в процессе работы падения 1 из 3 или даже 1 из 2. В общем Токио ГОРАЗДО стабильнее работает с много поточностью.
 

P.S. Запускалось естественно всё на одной машине, под одним пользователем.
 

Первый раз слышу о проблемах с TThread.Synchronize.

 

Ссылка на комментарий
  • 0
2 часа назад, Akad сказал:

Проверил эту гипотезу. На предмет глюков  RAD Studio 10.1 Berlin Update 2 с TThread.Synchronize. Эта проблема меня больше всего волнует из всех под win, остальные я уже почти все обошёл так или иначе. Для чистоты эксперимента взял виртуальную машину, образ скаченный с сайта эмбы и всё. Ничего стороннего не ставилось.

Результат печален.  Один и тот-же проект, под 10.2 стандартные падения в стандартных местах, где-то 1 раз из 4-х, может чуть реже. Берлин падает каждый раз при выходе, после использования синхронайза.
 

У меня никогда не было проблем с TThread.Synchronize, я уже больше 10 лет использую Delphi, начиная с Delphi 7. Мне кажеться у вас проблема с одновременным доступом двух и более потоков к каким то данным, точнее неправильно организована синхронизация (я говорю о самом термине, без привязки к Delphi) по сути. Напр. где-то что-то не защищено критическими секциями или их аналогами. Меняется одна переменная в потоке 1,  при этом она же читается с другого потока и именно поэтому будут случайные Access Violation, причем независимо от языка. 

Изменено пользователем ENERGY
Ссылка на комментарий
  • 0
2 часа назад, Akad сказал:

Проверил эту гипотезу. На предмет глюков  RAD Studio 10.1 Berlin Update 2 с TThread.Synchronize. Эта проблема меня больше всего волнует из всех под win, остальные я уже почти все обошёл так или иначе. Для чистоты эксперимента взял виртуальную машину, образ скаченный с сайта эмбы и всё. Ничего стороннего не ставилось.

Результат печален.  Один и тот-же проект, под 10.2 стандартные падения в стандартных местах, где-то 1 раз из 4-х, может чуть реже. Берлин падает каждый раз при выходе, после использования синхронайза, плюс в процессе работы падения 1 из 3 или даже 1 из 2. В общем Токио ГОРАЗДО стабильнее работает с много поточностью.
 

P.S. Запускалось естественно всё на одной машине, под одним пользователем.
 

Проблем с синхронизацией не было замечено ранее и пуля прилетает скорее всего из другого места. Сделайте нам демку пожалуйста.

Ссылка на комментарий
  • 0
39 минут назад, ENERGY сказал:

У меня никогда не было проблем с TThread.Synchronize, я уже больше 10 лет использую Delphi, начиная с Delphi 7.

Я на Delphi 1 написал экзаменационную программу, и с тех пор щупал почти все версии. :D Но вопрос не в этом. Вопрос в

Если я вырубаю поточность, все работает идеально. Как только её врубаю обратно - падает в CheckSynchronize. Происходит следующее: я закрываю форму и уничтожаю её, в родительской форме я после этого запускаю несколько потоков, которые забирают данные с сервера и заполняют свои таблицы через Synchronize. В общем-то ничего необычного, кроме того, что одновременно с этим форма уничтожается. Все привыкли их просто hide делать, разрабы когда тестировали, похоже этот момент вообще не учли. Сейчас вижу 2 варианта: либо в основной поток выходить через таймер (блин, ещё тот изврат будет...) либо создавать все формы при старте, и не разрушать их. Но тоже очень костыльное решение, так как у меня все формы описаны в скрипте, и создаются полностью динамически.
 

Ссылка на комментарий
  • 0
Скрытый текст

 

@Akad

Я так уничтожаю форму, проверено на 4 ОС (Win, Mac, Android, iOS):

OnClose событие. 

procedure TfrmSetup.FormClose(Sender: TObject; var Action: TCloseAction);
begin
  frmSetup := nil;
  Action := TCloseAction.caFree;
end;

 

Хотя это оффтоп, давайте ближе к теме.

Изменено пользователем ENERGY
Ссылка на комментарий
  • 0
7 часов назад, Akad сказал:

я закрываю форму и уничтожаю её,

зачем? если правильно все делать, она уничтожится сама. а если неправильно, то принудительное уничтожение приведет к AV рано или поздно

но лучше обсуждать это в отдельной теме.

Ссылка на комментарий
  • 0
13 часа назад, krapotkin сказал:

если правильно все делать, она уничтожится сама.

Как-то у меня большие опасения в этом. Останется какая-нибудь ссылка в недрах FMX и к вечеру у пользователя out of memory.

P.S. Вот интересно стало: а рабочие стили для 10.2 fmx для win существуют в открытом доступе? Ну что бы не глючили чудовищно сдвигая объекты со своих мест, и что бы кнопка минимизации работала.
 

Ссылка на комментарий
  • 0

@Fedor K

По поводу процессоров Intel.

1. На таких Android девайсах используется ARM эмулятор,  поэтому программы на Delphi там работают.

2. Intel уже давно не выпускает мобильные процессоры.  

Ссылка на комментарий
  • 0
12 часа назад, Akad сказал:

ссылка в недрах FMX

ну так значит по этой ссылке кто-то когда-то обратится! а вы объект прибили. а потом жалуетесь.

Ссылка на комментарий
  • 0
В 01.03.2018 в 08:56, x11 сказал:

https://blog.grijjy.com/2017/01/30/embed-facebook-sdk-for-android-in-your-delphi-mobile-app-part-2/

Embed Facebook SDK for Android in your Delphi mobile app (Part 2)

Вы наверняка меня не поняли, стоило использовать кавычки). Добавлять SDK можно, но это головная боль  с "напильником" в руках. Если вы считаете, что все классно - не стану переубеждать. На том же Xamarin подключить SDK займет пару минут. Пока не будет создано расширений для IDE и небольшого рефакторинга исходников -> использовать сторонние библиотеки будут вызывать негативные эмоции.

 

14 часа назад, ENERGY сказал:

@Fedor K

По поводу процессоров Intel.

1. На таких Android девайсах используется ARM эмулятор,  поэтому программы на Delphi там работают.

2. Intel уже давно не выпускает мобильные процессоры.  

1. Да, используется, но это очередной костыль, который не ахти сказывается на скорости работы. 

2. Да, с 2016 года прекращен выпуск мобильных процессоров. Поэтому со временем этот пункт можно отметать.

 

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

Ссылка на комментарий
  • 0
В 2/23/2018 в 09:45, x11 сказал:

10. Нельзя создавать 64-битные Андроид-приложения. А в Гугломаркете их уже 40%.

Да, FMX очень хорошая идея, но очень сильно отстаёт. Visual Studio с Xamarin давно уже позволяет компилить ARM-32, ARM-64, x86 и x64 приложения, т.е. под все возможные процессоры. Тоже самое и с Linux - в Visual Studio на C++ можно собирать x86, x64 и ARM Linux приложения, а на Delphi только x64. А ARM архитектура сейчас очень популярна, та же Raspberry Pi набирает обороты.

Ссылка на комментарий

Присоединяйтесь к обсуждению

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

Гость
Ответить на вопрос...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

  • Последние посетители   0 пользователей онлайн

    • Ни одного зарегистрированного пользователя не просматривает данную страницу
×
×
  • Создать...