Мне чет кажется, что дело не в Андроиде, а в глобальной проблеме, о которой я в посте первом писала: что программирование превращается просто в настройку набора написанных кем-то модулей. И будь там чистый проект, никаких бы проблем не было. А тут, получается, куча разных библиотек подключено, которые надо перенастроить в связи с переходом на новый юнити и новые версии библиотек. А так как я дела никогда с этими тупыми настройками не имела, то теперь имею проблемы. И те же советы с форумов устаревают еще до того, как советчик заканчивает их писать. Короче, жесть. После 13 лет ПРОГРАММИРОВАНИЯ чувствую себя полной идиоткой в какой-то отстойной НАСТРОЙКЕ. Неделя, чтоб скомпилить два мелких приложения. Я б за эту неделю аналог бы той библиотеки, возможно, написала. Не полный, конечно, но чисто нужный функционал.
Я че-то не уверена, что могу просто так взять и удалить манифест. А если удалить пекедж, то ругается на его отсуствие. Так что пекедж все-таки должен быть. Я там вписала левый, который вписан у другого приложения в том же манифесте. Но это не правильно. Хотя кто знает, может, тот настройщик, который настраивал это до меня, тоже вписал туда что-то левое…
открыт же тоже, ну кроме дистрибутивов многих производителей телефонов.
Перенастраивать на новые версии да, бывает сложно
Для просто обычного деплоя/сборки много где уже не так плохо как раньше, на серверах изобрели всякие Докеры (и для разработки тоже используют), чтоб у приложения была работающая проверенная среда, а не как повезет.
Бывает сложно даже просто начать работать с большим проектом потому что непонятно как собрать, запустить тесты и т.д., а документацию не дописали. Но самодокументирование набирает популярность, например для веба самый простой вариант: Использование Makefile в веб-разработке
Это из-за высокой неоднородности. Допустим, берется какая-нибудь продвинутая среда для ЯП, умеющая автоматом кучу всего. А в коде проекта будет вручную зафигачена логика через какой-нибудь левый формат данных вроде XML или отдельный скриптовый язык.
В Android упростить не получиться, есть зависимость:
версия ОС под которую ведется разработка;
плюс железки на которые мона вставить ОСь под которую работаем.
ИМХО.Я так понял сущность разработки для Android.
Да, я недавно на Qt + Qt Quick писал, там вообще жесть и ни разу не квик (хотя бы потому что почти нет стандартных компонентов, только примитивы).
Там как бы “фронтенд” на JavaScript (+ QML) и в итоге получается дико неудобно взаимодействовать с С++ (ну и всё делать в JS не получится на практике, если бы в проекте не был нужен С++, то его б и не брали, куча более простых вариантов).
Одна из причин наверно в том, что JS по задумке асинхронный, чтобы не вешать браузер, а в десктопных приложениях это в таком виде далеко не везде надо, и тут не запрос-ответ с короткой жизнью бэкенда.
Непонятно даже как какой-нибудь месседжбокс из С++ вызвать: либо callback hell (async await и т.п. не завезли же), либо костыли типа флагов и аналога DoEvents() в цикле.
И еще и куча разных + разное железо.
Ну и в геймдеве аналогично, там даже обычные виртуальные машины не особо помогут.
Ну примерно как и в вебе, то, что связано с UI — на JS (и QML вместо HTML, только чот CSS не завезли, хотя он даже в старых Qt виджетах был ) , остальное на С++.
Только тут еще разрешено напрямую взаимодействовать с С++ из JS/QML, типа вызвать функцию С++ из JS, подписаться на событие и т.п., с разными ограничениями, например, что передаваемые объекты (классов) могут быть только наследниками Qt объектов, а не любые, и вызывать можно только функции обработанные Meta-Object компилятором Qt. Время жизни объектов обычно как-то автоматически разруливается, но бывает надо указать вручную.
В простых случаях работает более-менее, в сложных начинается боль на каждом шагу.
Может быть это и работает нормально если делать архитектуру приложения как в вебе, взаимодействовать с С++ только очень изолированно и ограниченно, но тогда обычно проще сразу не брать С++ и Qt )
) , остальное на С++.