Pull to refresh

Comments 59

Надо мне написать статью как программировать под Android на Pascal-е. )))

Кстати, Android Studio позволяет работать с любым компилируемым языком (а может вообще с любым) для сборки приложений под Android.

Embarcadero Studio (delphi) отлично с этим справляется и есть бесплатный community edition

Я больше по полной нативной разработке, пока видел возможность только в FPC/Lazarus данную возможность. Но побеседовав с человеком (переписка ниже), думаю проверить данную возможность и в Delphi.

Android в Delphi это Firemonkey и вообще не совсем то. Android в FPC - это фактически просто NDK. Биндинги к системе придется прокидывать самому

Я посмотрю, возможно можно всё "выкинуть", что предлагает Delphi и использовать чистый нативный код.

В Delphi так тоже никто не мешает делать. А FMX (Firemonkey) просто уже готовый вариант на JNI. И сделать на чистом NDK с полной нативной работой без JNI приложение можно, но придется делать это так же как в FPC - с нуля.

Тоже думал написать что-то подобное, правда я на паскале в основном GLES дёргал и игруху писал

Ещё и .NET MAUI есть (Бывший Xamarin) чтобы писать приложения на андроиде
https://dotnet.microsoft.com/en-us/apps/maui

Можно, конечно ещё и PWA притянуть, оно не нативное, но тоже на JS.
https://developer.mozilla.org/en-US/docs/Web/Progressive_web_apps

Популярность не знаю, на Xamarin видел много, за PWA не слежу совсем ибо децентрализованная установка.

Ещё есть Delphi + FMX (полностью кроссплатформенный) или FGX (нативный для Android и iOS)

FPC/Lazarus забыл упомянуть. )))

Он может, но у него пока плохо с дизайнером форм для андроид. Насколько я помню, для андроид там не LCL, а отдельно сделано

это да, но нативно наоборот лучше использовать FPC (Lazarus не обязателен). Но нативно мало кто делает.

Для андроид и иос в Делфи тоже есть нативный фреймворк - FGX.

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

Так же нативный код - это код под данную архитектуру. Точнее машинный код.

Ну так Делфи генерирует нативный код для всех платформ, равно как и Лазарус. Об этом речи и нет

Есть пример, где Delphi собёрёт рабочую библиотеку на 100Кб? Под любой Android.

Размер тут при чем? Делфи использует LLVM для компиляции кода под Андроид. LLVM генерирует корректный машинный код для ARM

Я пишу про нативные библиотеки, которые можно запустить на Android без использования сторонних библиотек или практически без сторонних библиотек. Я собираю подобные рабочие примеры для Android используя FPC.

Вы можете привести подобный пример на Delphi который будет занимать малый размер нативного кода? И соответственно малый размер самого приложения. Допустим "Hello World".

Я пишу вам про нативный код, вы мне ответили что Delphi может в нативный код и привели в пример библиотеку которая не использует нативный код данной архитектуры, а использует нативные библиотеки (что не является нативным кодом данной архитектуры, даже разработчик той библиотеки об этом сказал).

Я интересуюсь, есть ли подобные примеры! По той причине, что мне это интересно и я не видел ни одного на сегодняшний день. Если подобный код существует, то мне будет интересно использовать данную возможность!

О каких "сторонних" библиотека вообще идет речь? FMX - штатный фреймворк на чистом паскале. Всё приложение для android на Delphi - это чистый машинный год и требуемые для приложения ресурсы и манифесты.

Нет. Этим вы показываете, что даже не заглядывали внутрь библиотек для сборки приложений под Android используемые Delphi.

Если вы заглянете внутрь, то поймёте, что практически ни какого нативного кода там нет и маловероятно что используется, потому что всё необходимое уже скомпилировано в Jar-файлы и Паскалевксий код нужен только для связки (в данном случае).

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

Я показал ниже. В чем вообще вопросы? jar-файлы - это дополнительный инструментарий, который позволяет использовать нативные инструменты платформы Андроид.

Вы понять не можете или не хотите. Нативным кодом я считаю тот, который нативен для конкретной арихитектуры. jar-код это байт-код, он не нативен для конкретной архитектуры и не зависим от архитектуры.

jar - и Java классы это нативные компоненты приложений Андроид.

Код на Делфи - НАТИВНЫЙ. Выполняется напрямую процессором. Без посредников. Всё остальное - это инструменты, для работы приложения так, как этого ожидают пользователи. Андроид имеет богатый функционал, который предоставляет в виде JAVA классов. Ими им пользуется Delphi.

нативный код может работать без библиотек и фреймворков. Есть подобный пример на Delphi?

На FPC - есть. На C/C++ - есть (лежит прямо в примерах NDK).

FGX - это фреймворк аналогичный VCL, который использует Паскалевский код и классы Java для работы с платформой Андроид. Никакие сторонние so для этого не нужны.

мне нужны. Мне нужен пример, пожаааалуйста! Ну хотя бы один примерчик SO-библиотеки малого размера сделанного на Delphi!

Этот пример уже почти 10 минут висит ниже. Внимательнее надо быть

А сам проект?

Эта библиотека входит в состав библиотек? Эта библиотека была собрана с помощью Delphi?

Я показал вам открытый проект в Делфи и результат - собранную бинарную библиотеку so. Справа - кусок среды с открытым проектом. Слева - папка с собранной библиотекой.

а пример как "Hello World" собрать можете показать? Но чтоб использовалась только SO-библиотека, а не всё что засунет туда Delphi.

Конечный APK-файл (или какой там сейчас AAB?) для конкретной архитектуры.

FMX использует JNI для работы с ОС. Код при этом нативный. В чем ещё вопрос? HelloWorld будет весить много, потому что подтянется вся нужная инфраструктура для работы полноценного приложения. Я не понимаю в чем претензия в данном случае и зачем гоняться за минимальным размером приложения.

Любому разработчику нужно полноценное приложение, которое будет взаимодействовать с ОС так, как это требуется. Зачем мне легковесный HelloWorld на Лазарусе, который будет весить 100кб, если я могу гараздо быстрее и удобнее создать полноценное приложение на Delphi, и пусть оно весит 8мб?

Я разработчик библиотеки ZenGL, если слышали о такой. Если в Delphi есть возможность создавать нативные приложения не зависящие (или почти не зависящие) от библиотек/фреймворков используемых (не используемых, а просто приложенных) в Delphi, то я бы хотел это знать.

Если такая возможность есть, то я постараюсь использовать данную возможность для того чтоб ZenGL мог поддерживать Android используя и Delphi, а не только FPC.

FGX, который собирает приложения под андроид не использует вообще какие-либо модули FMX.

меня не интересуют вообще ни какие библиотеки, ни фреймворки. У меня уже всё необходимое собрано и работает. )))

так... получается мы можем вручную удалить jar-файлы?! Хм... надо проверить.

Можем. Ты можешь убрать весь рантайм делфи и FMX и собирать приложение или библиотеки под Андроид.

Благодарю! Проверю!

Хочу написать свой мультимедийный велосипед с перламутровыми пуговицами, шахматами и поэтессами (метроном). Желательно и для ведра и для огрызка сразу. Умею только на сипипи.
Куда пойти? Куда податься? Что мне найти? Чему отдаться? В плане выбора технологии).

Можно писать на плюсах и под Android, и под iOS. Но так, чтобы один и тот же код работал и там, и там - не получится. Слишком разные системы.

Kotlin multiplatform используйте

Kivy и Python наше все. Ну и плюс java, там где этого мало (всякие сервисы например).

Я бы не ставил всё на язык с динамической типизацией и сомнительным code style. Статья написана неплохо по меркам 2017 года. Сегодня же есть Kotlin и другие приколы, с ним связанные.

Очевидно что этот Kivy уступит место KMM, это лишь вопрос времени. Сторы блокируют наших гигантов, особенно тяжко живётся iOSерам. Всё может свестись к тому, что уберут разделение и будут писать на мультиплатформе. Тогда нет совершенно никакого смысла от изучения командой Kivy, в то время как стоимость переобучения опытных чуваков с Kotlin на KMM ≈0. Да и Swift тоже имеет похожие конструкции, так что с него проще на KMM.

На больших проектах, бэк на питоне - не видел что используют, Гошка лучше. Питон остаётся хорош для ML. Пока так.

В общем писать приложения под android это боль и страдания, а с учетом публикации в сторах ещё и унижение.

Это миф. Конечно, под Android есть свои болячки типа миллиона фреймворков для GUI, AppCompat/Android X и прочей дичи, но используя минимальный сабсет системного API вполне можно реализовать большинство необходимых приложений. В том числе и 3D-игры писать, а если стандартый гуй вгоняет в депрессию своей производительностью или просто хочется велик - то можно и свой гуй рендерить, т.к в Java прокинуты биндинги к GLES.

Какие миллионы фреймворков ? Под Android есть ровно два способа построения UI - старый, на основе XML, и новый - Compose. Никаких фреймворков там и в помине нет, все сам, все ручками )

Ну, я лично аппкомпат тоже считаю хоть и дополнением к основному UI, но все равно самодостаточным, поэтому тоже приплел его к общему балагану :) Но если честно, идея гугла реально так себе. Если хочется апгрейдить виджет-тулкит, нужно было давать возможность OTA-обновления или типа того, а не прибивать к framework.jar :(

Название "как писать на андроид". В статье солянка. И даже Шилд здесь.

Кстати, Джава Шилда, как по мне, пепреоценина. Его имя как синоним нужной учёбы яп, отбивающих желание учить.

Шилд хороший источник знаний. Но лучше его книги рассматривать как дополнение.

С 2011 пишу под дроид. Так вот. А что я щас такое прочитал?

Видимо некто пытается войти в андроид разработку, и для улучшения резюме - статья на хабре. :)

много лет пишу кроссплатформу. начинал с натива, потом был phonegap/cordova (pwa), потом перелез на react native. не для наброса на вентилятор, но справедливости для пробегусь по минусам RN:

  • Хоть JSX и использует JavaScript, что делает его намного понятнее, нельзя не отметить довольно сложный и запутанный синтаксис этого языка.

сложность и запутанность javascript? это по сравнению с явой то?

  • React Native не предоставляет полный доступ к нативным функциям устройства, что может затруднять разработку.

интересно, каким образом RN ограничивает доступ к функциям устройства? ну т.е. этот пункт надо вычеркнуть и забыть, что он вообще был, это просто глупость.

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

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

  • Приложения, созданные с использованием React Native, менее производительными по сравнению с нативными приложениями из-за моста JavaScript и самой концепции кросс-платформенного кода. Это может быть особенно заметно при работе с большим объемом данных или сложными анимациями.

это очевидно, т.к. действительно кроссплатформа даёт прилично оверхеда. на самом деле современный RN стал быстрым, современные андройды стали быстрыми, разницы конечный клиент по сути и не заметит, но да действительно, если считать миллисекунды на бутстрапе -- натив победит. про большой объём данных -- допустим, что автор просто опечатался, т.к. нет никакой разницы из натива ты работаешь с большими данными или из rn. про сложные анимации вообще смешно, reanimated настолько подняли планку, что не каждый нативщик сможет так же просто и быстро делать 60fps анимацию.

  • Создание сложных пользовательских интерфейсов может быть более сложным с использованием React Native по сравнению с нативными разработками из-за ограниченности фреймворка.

а в чём ограниченность фреймворка? тут автор прав при одном условии -- если rn пишут новички, то действительно приложение будет запутанным и сложным для понимания. свобода, которую даёт jsx+javascript играет в обратную сторону, если проект делает не опытная команда. в этом плане android studio, конечно, всё же обязаывает разработчика писать "правильно" и не придумывать велосипед. но опять же, всё зависит от команды.

  • В отличие от нативной разработки, React Native может ограничить доступ к некоторым функциям и возможностям, доступным только на конкретной платформе. То есть то что работает на iOS в лучшем случае будет выдавать ошибку на Android.

опять же, к некоторым, это например к каким? и что, например, будет работать на иос и будет выдавать ошибку в андройде?

  • Использование сторонних библиотек и плагинов может привести к проблемам совместимости или возникновению ошибок в процессе разработки. При этом зачастую их использование необходимо для реализации определённого функционала.

и ничего не мешает разработчику исправить код этих "плагинов"... ровно так же, как и в нативе.

А еще есть B4X. На 80% кроссплатформенно.

У меня тоже возник вопрос: И что я сейчас прочитала?

Потому что текст не соответствует названию.

Я новичок. Выучила сама Яву и написала 2 приложения под Андроид. Не стала писать ещё только потому, что сейчас проблема с их продажей из-за санкций и законов. И ничего из перечисленного в статье, кроме Шилдта, мне не пригодилось. Кстати, в плане теории Шилдт почти идеален. А практика великолепна в книге Канель, Фрайман "Ява Задачи по основам программирования" там больше 600 задач. Советую любому новичку.

Код я писала в Эклипсе, потому что Андроид студио на моём древнем компьютере так и не заработал.

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

Я новичок. Выучила сама Яву и написала 2 приложения под Андроид. Не стала писать ещё только потому, что сейчас проблема с их продажей из-за санкций и законов

А как же RuStore? В нём уже есть монетизация приложений.

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

Тут согласен, недостатки Android Studio не соответствуют действительности. За 5 лет разработки только один критичный баг был при обновлении на новую версию IDE, и то его пофиксили быстро.

Здравствуйте, можете мне помочь я немного запутался , вот если я создаю мобильное приложение , то его лучше написать на React Native с использованием JavaScript , HTML, CSS или на Android Studio с использованием java или Kotlin?

@Fate77 Здравствуйте, рекомендую использовать Android Studio и Kotlin. Это нативные технологии для мобильной разработки.

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

P.S. У меня на Хабре в ближайшее время появятся новые статьи по разработке моб. приложений на Kotlin с нуля, можете почитать.

полностью нативные технологии - это использование конечного компилируемого кода под определённую архитектуру. Например код который выдают C/C++, FPC, Delphi, ассемблер и другие компилируемые ЯП с использованием NDK.

То что вы называете "нативными" технологиями, не совсем нативные. Для байт-кода можно конечно назвать нативными, но на самом деле - это подмена понятий.

Sign up to leave a comment.

Articles