Нет сил держать в себе.
Содержит субъективную ненависть к платформе Android вообще и создателям её отдельных частей в частности.
Я с 2008 года пишу под iOS, с 2009 — под ОС Андроид.
До этих мобильных был embedded c, C++ под десктопный Линукс, Windows Mobile, документооборот "тяжёлым клиентом" под Windows.
Возможно, именно этот порядок — сначала iOS, потом Android, и определил моё восприятие.
Нет такой вещи, которая бы в инфраструктуре ОС Андроид не вызывала бы ненависти и раздражения.
Начиная с чудесной, казалось бы, IDE Android Studio, которая запускается в два раза медленнее Xcode, на нажатия клавиш реагирует в два раза медленнее, иногда попросту отказывается выполнять какие-либо действия, мотивируя необходимостью внутренней индексации. Два раза на дню Андроид Студия говорит что есть обновления чиха того или чиха того. Под macOS в этом поделии даже клавиши не подумали сделать, приходится самостоятельно назначать, например, Cmd-Up для перехода в самый верх исходника.
NDK спасибо что есть, иначе пришлось бы писать на нелепых языках Java и Kotlin, а они, кроме как в Андроид, нужны вот где:.
Да, у iOS есть нелепые Objective-C и Swift, но С++ там компилируется на "родном" уровне.
В отличие от Android.
От чего, собсно, накатило:
Есть у меня библиотека, которая парсит специфического вида XML. На С++. Зависит, как ни странно, от libxml2. Этот libxml2 внутри Андроида есть, НО его нельзя использовать в NDK, потому что нет ни заголовочных файлов, ни нужной .so
И так с десятком библиотек общего назначения (ещё мне нужен SQLite, например), которые есть внутри Андроида как операционки, потому что это виртуальное поделие ART всё равно использует опенсорсные де-факто стандарты для своей работы.
В результате мне приходится тащить libxml2 отдельно (из репы опенсорсной части Андроида, хаха), думать, как его собирать. Android Studio предлагает все нативные сорцы собирать CMake (о, я знаком с CMake, писал на нём довольно развесистую систему сборки в своё время, под linux), НО в клоне libxml2 в репах Андроида нет поддержки CMake!!! Есть "родные" automake/autoconf. Спасибо, очень помогло.
Ещё в libxml2 есть файл Android.bp, про который гуглится, что это файл для blueprint, который как-то связан с сборочной системой с именем "soong". В документации на этот соонг написано как писать сборочные скрипты, но НИГДЕ не написано, как собрать сам, написанный на очередном нелепом языке go, этот соонг.
В состав NDK система сборки блюпринт/соонг не входит, конечно! Пишут "начинали мы с одного и того же ndk-build, но потом в NDK внедрили cmake, а в самом Андроиде soong. Криворукие дебилы, которые не могут выработать единый стандарт инфраструктуры для платформы. Free as in free fuck.
This Makefile-based system is in the process of being replaced with Soong, a new build system written in Go. During the transition, all of these makefiles are read by Kati, and generate a ninja file instead of being executed directly. That's combined with a ninja file read by Soong so that the build graph of the two systems can be combined and run as one.
StackOverflow вообще не в курсе что бывают такие проблемы. Ну, то есть, там пишут "вот cmake для libxml2", но (а) без поддержки Юникода (у меня легко могут быть нац-языковые XML в UTF-8 или даже в UTF-16, чем чёрт не шутит) (б) предлагают подправить в некоторых местах конфигурационные файлы, чего я делать не хочу, я хочу подключить libxml2 из репы Андроида как git submodule и добавить его в сборочный CMakeLists.txt выше каталогом. Но нет, фигтамбыл.
Ещё пишут "так откатись на несколько ревизий назад, там есть Android.mk, а это обычный мейкфайл!"
Нет, сука, если я откачусь на несколько ревизий назад, то я могу получить не ту библиотеку.
Как такое дичайшее, лютейшее говно собрало на себя имеющиеся 80% рынка — понимать отказываюсь.
--
Да-да, напишите мне, что я криворукий дебил и не разобрался.
Я-то разберусь, не сегодня-завтра.
А кривым в Андроиде всё останется.
Здравствуйте, Dair, Вы писали:
D>Начиная с чудесной, казалось бы, IDE Android Studio, которая запускается в два раза медленнее Xcode, на нажатия клавиш реагирует в два раза медленнее, иногда попросту отказывается выполнять какие-либо действия, мотивируя необходимостью внутренней индексации.
А руки проверять не пробовали на радиус кривизны?
PS: XCode — уродство вообще максимальное.
D>NDK спасибо что есть, иначе пришлось бы писать на нелепых языках Java и Kotlin, а они, кроме как в Андроид, нужны вот где:.
Java — как бы самый частоиспользуемый язык в мире, мелочь совершенная.
D>Да, у iOS есть нелепые Objective-C и Swift, но С++ там компилируется на "родном" уровне.
В Андроиде аналогично.
D>В результате мне приходится тащить libxml2 отдельно (из репы опенсорсной части Андроида, хаха), думать, как его собирать. Android Studio предлагает все нативные сорцы собирать CMake (о, я знаком с CMake, писал на нём довольно развесистую систему сборки в своё время, под linux), НО в клоне libxml2 в репах Андроида нет поддержки CMake!!! Есть "родные" automake/autoconf. Спасибо, очень помогло.
Кто мешает взять обычную libxml, скомпилировать (можно даже статически) и прилинковать её? Кривизна рук опять?
D>StackOverflow вообще не в курсе что бывают такие проблемы. Ну, то есть, там пишут "вот cmake для libxml2", но (а) без поддержки Юникода (у меня легко могут быть нац-языковые XML в UTF-8 или даже в UTF-16, чем чёрт не шутит)
libxml2 без поддержки Unicode не существует.
D>(б) предлагают подправить в некоторых местах конфигурационные файлы, чего я делать не хочу, я хочу подключить libxml2 из репы Андроида как git submodule и добавить его в сборочный CMakeLists.txt выше каталогом. Но нет, фигтамбыл.
Зачем?
D>Как такое дичайшее, лютейшее говно собрало на себя имеющиеся 80% рынка — понимать отказываюсь. D>Да-да, напишите мне, что я криворукий дебил и не разобрался.
Точно так.
И вообще, на какие 3 буквы писать учётную систему для Андроида на С++? И потом кушать кактус, удивляясь, что он колючий.
Здравствуйте, Dair, Вы писали:
D>Нет сил держать в себе. D>Содержит субъективную ненависть к платформе Android вообще и создателям её отдельных частей в частности.
1. Под Андроид нужно разрабатывать из-под Винды или Линукса.
2. Писать на Java or Kotlin.
3. Нужен мощный компьютер. Не ноутбук.
Здравствуйте, Dair, Вы писали:
D>Как такое дичайшее, лютейшее говно собрало на себя имеющиеся 80% рынка — понимать отказываюсь.
Дык бесплатно ж. И, значит, дешевые смартфоны. А за дешево массы любое дерьмо сожрут, даже такое, как ведро.
Являюсь штатным настройщиком одного семейного ведроида. Хосспадя, после яблофона какое же это убогое говно. Просто помои. Ну ничего, недолго этому агрегату осталось портить мне нервы. Осенью заменю его, скорее всего.
Здравствуйте, Dair, Вы писали:
D>Содержит субъективную ненависть к платформе Android вообще и создателям её отдельных частей в частности. D>От чего, собсно, накатило:
D>Есть у меня библиотека, которая парсит специфического вида XML. На С++. Зависит, как ни странно, от libxml2. Этот libxml2 внутри Андроида есть, НО его нельзя использовать в NDK, потому что нет ни заголовочных файлов, ни нужной .so
В SDK андроида есть поддержка xml-парсера: https://developer.android.com/training/basics/network-ops/xml
D>И так с десятком библиотек общего назначения (ещё мне нужен SQLite, например), которые есть внутри Андроида как операционки, потому что это виртуальное поделие ART всё равно использует опенсорсные де-факто стандарты для своей работы.
Здравствуйте, Dair, Вы писали:
D>Как такое дичайшее, лютейшее говно собрало на себя имеющиеся 80% рынка — понимать отказываюсь.
Очень просто. Под него у меня есть бесплатные mpdroid (управление проигрывателем mpd), bubble upnp (dlna) и transmission (управление торренто-качалкой).
А у эпла этого нет или в плачевном состоянии, потому что торренты — зло, dlna и mpd не нужен — покупайте наши печеньки.
Но я — всего лишь пользователь, а не программист под андроид.
Здравствуйте, Dair, Вы писали:
D>Есть у меня библиотека, которая парсит специфического вида XML. На С++. Зависит, как ни странно, от libxml2. Этот libxml2 внутри Андроида есть, НО его нельзя использовать в NDK, потому что нет ни заголовочных файлов, ни нужной .so D>И так с десятком библиотек общего назначения (ещё мне нужен SQLite, например), которые есть внутри Андроида как операционки, потому что это виртуальное поделие ART всё равно использует опенсорсные де-факто стандарты для своей работы.
Добавлю к этому списку Skia. Android умеет рисовать на экран. По всей видимости эффективно. Но через NDK рисовать низзя — нужно тащить свой вариант Skia и заводить его через OpenGL. Хорошо хоть OpenGL есть.
С грустью вспоминаю Windows CE / Windows Mobile.
Даже того потного Бормана на сцене с криками "Developers, developers, developers" готов обнять при встрече. Ибо по делу орал.
Здравствуйте, BlackEric, Вы писали:
BE>1. Под Андроид нужно разрабатывать из-под Винды или Линукса. BE>2. Писать на Java or Kotlin. BE>3. Нужен мощный компьютер. Не ноутбук.
Я пишу под Андроид на С++ и Kotlin, из Mac OS X и на ноуте. Всё работает нормально.
Здравствуйте, c-smile, Вы писали:
CS>Добавлю к этому списку Skia. Android умеет рисовать на экран. По всей видимости эффективно. Но через NDK рисовать низзя — нужно тащить свой вариант Skia и заводить его через OpenGL. Хорошо хоть OpenGL есть.
???
Рисование работает через EGL — создаём поверхность, рисуем на неё (с помощью OpenGL или хоть как иначе) и отображаем. Можно даже ещё ниже спуститься и напрямую создавать AHardwareBuffer и ими кормить композитора.
Здравствуйте, BlackEric, Вы писали:
BE>1. Под Андроид нужно разрабатывать из-под Винды или Линукса.
Второй компьютер с линуксом заводить? Ну, не знаю... У первого два монитора, если у второго ещё два монитора будет, они на столе не поместятся. А первый иногда нужен, iOS-проект-то тоже параллельно разрабатывается.
BE>2. Писать на Java or Kotlin.
Есть общие части, например, бизнес-логика, написанные на C++. Чтобы не писать их два раза и дважды не поддерживать.
Все интерфейсные вещи на Котлине.
Ага. Она написана через libxml2. Я ж не буду из С++-кода через JNI дёргать библиотеку, написанную на Java, которая будет вызывать нативную часть на libxml2.
LB>В SDK андроида есть поддержка sqlite: LB>https://developer.android.com/training/data-storage/sqlite
Ровно та же история, что и с libxml.
LB>Если уже есть "искаропки", то зачем прикручивать что-то неприспособленное?
Нет искаропки. Точнее, так.
Есть искаропки на Java/Kotlin, использующее нативную libxml2/SQLite.
Мне не надо Java/Kotlin, мне сразу libxml2/SQLite дайте. Скачав образ любого Андроида, можно найти нужные .so в соответствующих местах (типа /usr/lib). Но не дают.
Здравствуйте, Cyberax, Вы писали:
C>А руки проверять не пробовали на радиус кривизны?
Давай курвиметр. Других рук вот только нет, сорри.
C>PS: XCode — уродство вообще максимальное.
Там не всё хорошо, конечно, но мне удобно и привычно.
D>>NDK спасибо что есть, иначе пришлось бы писать на нелепых языках Java и Kotlin, а они, кроме как в Андроид, нужны вот где:. C>Java — как бы самый частоиспользуемый язык в мире, мелочь совершенная.
И я рад за Java (который используется в бэкенде банков, вроде как, да?), но я, конечно, говорил про конкретную область.
Вот у меня есть кроссплатформенное приложение на Win/Lin/iOS/Android. Критичное иногда к времени выполнения. С++ — единственный выбор для этого. Не то чтобы я сильно фанат С++, но другого не дают.
D>>Да, у iOS есть нелепые Objective-C и Swift, но С++ там компилируется на "родном" уровне. C>В Андроиде аналогично.
Как я показал ниже, не совсем.
D>>В результате мне приходится тащить libxml2 отдельно (из репы опенсорсной части Андроида, хаха), думать, как его собирать. Android Studio предлагает все нативные сорцы собирать CMake (о, я знаком с CMake, писал на нём довольно развесистую систему сборки в своё время, под linux), НО в клоне libxml2 в репах Андроида нет поддержки CMake!!! Есть "родные" automake/autoconf. Спасибо, очень помогло. C>Кто мешает взять обычную libxml, скомпилировать (можно даже статически) и прилинковать её? Кривизна рук опять?
Ты перечитай. Я и взял. В репе Андроида она и лежит, отличие только в наличии Android.bp.
Я и хочу теперь уже собрать и прилинковать.
Но есть нюанс.
Сборка нативного кода в Студии сделана на CMake, а сборка нативного кода в репах Андроида сделана на Blueprint/Soong.
Стоит совершенно непонятно зачем задача сопряжения одного и другого.
D>>StackOverflow вообще не в курсе что бывают такие проблемы. Ну, то есть, там пишут "вот cmake для libxml2", но (а) без поддержки Юникода (у меня легко могут быть нац-языковые XML в UTF-8 или даже в UTF-16, чем чёрт не шутит) C>libxml2 без поддержки Unicode не существует.
Ты прав, я про другие кодировки, для которых используется iconv.
D>>(б) предлагают подправить в некоторых местах конфигурационные файлы, чего я делать не хочу, я хочу подключить libxml2 из репы Андроида как git submodule и добавить его в сборочный CMakeLists.txt выше каталогом. Но нет, фигтамбыл. C>Зачем?
Что "зачем"? Чтобы собрать libxml2, конечно!
C>И вообще, на какие 3 буквы писать учётную систему для Андроида на С++? И потом кушать кактус, удивляясь, что он колючий.
Какую учётную систему???
У меня бизнеслогика на С++, которая собирается и туда, и туда.
Здравствуйте, Dair, Вы писали:
D>Как такое дичайшее, лютейшее говно собрало на себя имеющиеся 80% рынка — понимать отказываюсь.
Зато их программисты знают, зачем круглые люки! И что "попасть в гугл ооооочиньсложна!". Да в гробу я видал такие шарашки! Да-да, "шарашки" бывают и под 10,000 человек, причём чем челов больше, тем бестолковее весь процесс.
Мне кажется, тут прошло не без продавливаний со стороны гугли — написали тупейшую нашлёпку на линупс, "убедительно попросили" компании поставить это фуфло на их железо, наобещали "поддержку", вот и закрутилось! Своих прогеров нагнули — или увольнение, или Ведроид!
Вот так тысяча индусов, которым, похоже, вообще по-барабану на чём писать, стали выкатывать мало-мальский "маркет приложений". Шальные деньги чего только не сделают! И это позорище ИТ к счастью они вроде как собираются заменять, потому что самих достало И что обидно, ни один клоун-дебил-подаван-посредственность не будет уволен за похабнейшую ОС! Сделали бабла, слили говнецо, а юзеры... да чё юзеры — пусть ещё покупают железки! (хотя любой аппарат 10-летней давности СПОКОЙНО отрабатывает любое современное приложение, если его писать правильно в нэйтиве)
А ещё убивает брошеный практически в стадии завершения Win Mobile — будто какая-то мразь из гугла "элопила" проект до полного фэйла, хотя практически ни одной технической причины фэйла нет!
Здравствуйте, Dair, Вы писали:
D>Ага. Она написана через libxml2. Я ж не буду из С++-кода через JNI дёргать библиотеку, написанную на Java, которая будет вызывать нативную часть на libxml2.
Кстати, я однажды именно так и извратился, но совсем для другой библиотеки, работающей с внешними девайсами. Делал это, чтобы иметь унифицированный сишный API для винды и андроида + из академического интереса. Для винды было просто, ибо там была DLL, а для андроида был jar. Ну и ч0, все летало со свистом. Правда, там надо было совсем немного библиотечных вызывов обеспечить.
D>Есть искаропки на Java/Kotlin, использующее нативную libxml2/SQLite. D>Мне не надо Java/Kotlin, мне сразу libxml2/SQLite дайте. Скачав образ любого Андроида, можно найти нужные .so в соответствующих местах (типа /usr/lib). Но не дают.
Ну, если нужна суровая кроссплатформа и комромисс невозможен...
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, c-smile, Вы писали:
CS>>Добавлю к этому списку Skia. Android умеет рисовать на экран. По всей видимости эффективно. Но через NDK рисовать низзя — нужно тащить свой вариант Skia и заводить его через OpenGL. Хорошо хоть OpenGL есть. C>???
C>Рисование работает через EGL — создаём поверхность, рисуем на неё (с помощью OpenGL или хоть как иначе) и отображаем. Можно даже ещё ниже спуститься и напрямую создавать AHardwareBuffer и ими кормить композитора.
Да пофигу что там, OpenGL или OpenGLES.
Важно то что те 2D примитивы рисования что использует сам Android не доступны. А шрифты, i18n и прочее?
Где бы были Windows, MacOS или Linux если бы из них убрать GDI, CoreGraphics и GTK. Что-бы было если убрать DrawText и его поддержку ClearType из Windows API...
Оно же всё есть на платформе, но только в Java ...
Здравствуйте, Dair, Вы писали:
D>Вот у меня есть кроссплатформенное приложение на Win/Lin/iOS/Android. Критичное иногда к времени выполнения. С++ — единственный выбор для этого. Не то чтобы я сильно фанат С++, но другого не дают.
Ну так а сначала написать на Java, а потом посмотреть на скорость? Или вообще на JS с Electron.
D>Сборка нативного кода в Студии сделана на CMake, а сборка нативного кода в репах Андроида сделана на Blueprint/Soong. D>Стоит совершенно непонятно зачем задача сопряжения одного и другого.
Ну так возьми обычный libxml2 с сайта libxml и поставь в сборку. Там будет и CMake и блэкджек.
D>>>StackOverflow вообще не в курсе что бывают такие проблемы. Ну, то есть, там пишут "вот cmake для libxml2", но (а) без поддержки Юникода (у меня легко могут быть нац-языковые XML в UTF-8 или даже в UTF-16, чем чёрт не шутит) C>>libxml2 без поддержки Unicode не существует. D>Ты прав, я про другие кодировки, для которых используется iconv.
А они точно нужны? UTF-8 уже доминирует везде.
D>>>(б) предлагают подправить в некоторых местах конфигурационные файлы, чего я делать не хочу, я хочу подключить libxml2 из репы Андроида как git submodule и добавить его в сборочный CMakeLists.txt выше каталогом. Но нет, фигтамбыл. C>>Зачем? D>Что "зачем"? Чтобы собрать libxml2, конечно!
Зачем из репозитория Андроида?
D>У меня бизнеслогика на С++, которая собирается и туда, и туда.
Вот тут-то и вопрос — если в С++ нужно чтение XML, да ещё с кодировками, то задача выглядит уж совсем точно не для С++.
Здравствуйте, Cyberax, Вы писали:
D>>Вот у меня есть кроссплатформенное приложение на Win/Lin/iOS/Android. Критичное иногда к времени выполнения. С++ — единственный выбор для этого. Не то чтобы я сильно фанат С++, но другого не дают. C>Ну так а сначала написать на Java, а потом посмотреть на скорость? Или вообще на JS с Electron.
Требовать от клиента ставить Java при установке на винду — моветон.
Как поставить джаву на iOS, и пустят ли такое приложение в аппстор — поделись.
D>>Сборка нативного кода в Студии сделана на CMake, а сборка нативного кода в репах Андроида сделана на Blueprint/Soong. D>>Стоит совершенно непонятно зачем задача сопряжения одного и другого. C>Ну так возьми обычный libxml2 с сайта libxml и поставь в сборку. Там будет и CMake и блэкджек.
To build on an Unixised setup:
./configure ; make ; make install
Меня это несколько не устраивает, потому что кросс-компиляция в аж 4 архитектуры (реально, конечно, нужны две, но всё равно кросс-компиляция).
Но и это я решу. Но хотелось-то чтобы было проще. Я тут ною не от невозможности чего-то сделать, а от того что сделано сложно ну вот просто так, без каких-либо реальных причин, просто не подумали.
C>А они точно нужны? UTF-8 уже доминирует везде.
Пользовательский контент, теоретически, может быть любым. Пока это валидный XML, надо уметь парсить. В Японии "любят" родную (JIS) кодировку до сих пор, например, это про что я точно знаю.
D>>Что "зачем"? Чтобы собрать libxml2, конечно! C>Зачем из репозитория Андроида?
Потому что в репозитории Андроида он ровно тот, который внутри Андроида. Вообще у меня была мысль с ним слинковаться, но в бандл не пихать, чтобы библиотека пользовалась системным. Но, видимо, не судьба, я уже смирился.
С "родным" репозиторием (URL выше), впрочем, всё ровно то же самое.
D>>У меня бизнеслогика на С++, которая собирается и туда, и туда. C>Вот тут-то и вопрос — если в С++ нужно чтение XML, да ещё с кодировками, то задача выглядит уж совсем точно не для С++.
Да XML-то пример просто. Так-то, вообще, у меня есть бизнес-логика, которая:
1. Хранит на "диске" SQLite-базы
2. "Спрашивает" и "слушает" сеть (сеть на "родных" интерфейсах, через уровень абстракции)
3. По этой сети получает (в т.ч.) XML определённого формата и JSON определённого формата. Если JSON — это всего лишь моё с сервером API, то XML он по стандарту (не внутреннему), и есть (уже внутренняя) библиотека, которая умеет парсить нужный XML-формат согласно определённому стандарту. Библиотека покрыта юниттестами и гарантированно работает в нескольких продуктах. Переписывать её на Java отдельно — отдельный геморрой и человекомесяц.
4. Предоставляет двустороннее API для "фронтенда", т.е., GUI. GUI написан на "родных" фреймворках — Cocoa для iOS, Android SDK под Android.
