Мнение о Lua Love (game engine)

Коротко:

Не надо вам это, особенно для Android, даже если хочется.

Были у меня мысли использовать Love движок как кроссплатформенный вариант , для написания приложений в linux, windows, android, ios.
я и знаю, что он он не предназначен для этого.

Хотелось потому, что есть прекрасный способ делать на нем UI Slab

B есть вообще много всего, что работает и красиво (задел от игровой индустрии).
Однако минусы:

  1. Android сборка капризная, с кучей ndk зависимостей (бинарные под процессоры, которые не SDK а нативные) , которые нужны для многих lua пакетов.
  2. Сборка в Android ограничена android… со всеми вытекающими, я уж не говорю о IOS, который так ограничен, что и говорить нечего. У вашего приложения в Android будет возможность лишь рисовать себя и минимально, по взаимодействию с системой - там love проблем не решает.
  3. пакетирование приложения в Love файл создаёт трудности с путями, и загрузкой модулей, ведь приложение работает в итоге во временной папке… это не то что надо для приложений работающих в системе.

Вывод про Android в целом (внезапно)

После поиска вариантов как писать приложения для Android я пришел в таким выводам и таким вариантам:

  • рассмотрел Flet (Flutter) , PySide, Qt Qml, ReactNative

Пришел к таким выводам:

  1. для именно Андройд приложения наиболее адекватен ReactNative, но
  2. Андройд приложения не так уж и гибки как хочется. Они и не сервис и не ГИП - они посередине.

Поэтому далее о том что я выбрал для Андройд

“Наилучший путь” для Android

TERMUX - вот что нужно программисту чтобы быстро и качественно делать много ГИП и приложений для Android.

Нативные приложения - не очень то полезны по сравнению с тем, что можно отобразить в браузере, имея локальный сервис\сервер - можно отображать локальный сайт, который будет “летать” и решать любые ГИП UI задачи.

ReactNative это React, в первую очередь, а раз мы не ушли от React, то логично НЕ заходить на территорию Native - больше свободы в рамках UI.

Каждый фреймворк диктует свою архитектуру приложений и свои возможности и свою производительность труда. У серверных скриптов наилучшая произвдительность труда и TERMUX поддерживает это.

Если выбрать локальный сервер на смартфоне и ГИП UI в браузере мы не теряем производительность труда и время на разработку и не теряем в качестве результата.

Но termux еще и предоставляет возможности типа Termux:Gui - Это особый сервис на Android SDK, который доступен через сокет из termux для приложений в нём. Это круто ! это лучшее из всех миров : из скриптов, из сервер кода и предосталвяет нативный интерфейс. По сути они переделали SDK ! - сделали его доступным для скриптов из linux (termux). Никаких ограничений, гибкость, отсутствие бинарных зависимостей и сборка под termux того, что этого требует - это очень хорошо.

​ В Termux есть Python, Js, Go, C++ , … там есть всё что нужно. Там есть ubuntu, alpine… и их пакетные менеджеры… Зачем вам Android SDK и ndk если у вас есть всё это?

Мне очень нравится этот подход. Я пишу для Termux сервис на чем угодно и открываю большую часть интерфейса в браузере. (и же это работает и для Linux - идеально)

Мнение о Flet

Flet поразил меня, это неожиданно (Flutter + Python, учитывая, что Dart - всё).

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

Минусы:

  1. Очень большая сборка для android со всеми особенностями и зависимостями, и их много: Это и сам Fluter и особый Python + pyc для него и нативные wheels тоже… и это почти тоже самое как сборка Love для Android - те же проблемы с зависимостями и размером. Это не легковесно, мягко говоря. Эти же проблемы при сборке и использовании PyQt, Qml и этого всего. А раз это в одном ряду - то выбирать среди этого даже не хочется.
  2. Кастомные компоненты тоже платформенно зависимые, например FilePicker не умеет drag drop из файлового менеджера. Он либо соберётся (а может нет), но в браузере (web) такой возможности просто не будет из-за ограничений браузера… Компоненты которые только выглядят и мало взаимоджействуют с системой я могу и React написать для браузера то..
  3. Кстати о стиле приложения. Приходится мапить состояние приложения в компоненты и делать page.update() а внаше время этим уже не занимаются, это тратит уйму времени. Мы экономим наодном (на чём , кстати?) и тратим время на другом - мапим изменения состояния на компоненты.
  4. Код не красивый, это Python а в нём появляется много замыканий, а питон плохо раотает с замыканиями, и те что в нём есть - не захватывают нормально контекст и приходится добавлять контексты, оборачивая калбеки функциями.. код в итоге представляет собой плохо читаемую кашу из калбеков и ссостояний и компонентов , их композитов… это не красивый код. И никакие классы не делают его функциональнее.

В итоге я поигрался Flet и отложил его в сторону.

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