Нет сил держать в себе.
Содержит субъективную ненависть к платформе 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.
D>Начиная с чудесной, казалось бы, IDE Android Studio,
Зачем она тебе? Нужен любой текстовый редактор начиная от vim заканчиваю VisualStudio (с плагинами для сборки под андроид).
D>В результате мне приходится тащить libxml2 отдельно (из репы опенсорсной части Андроида, хаха), думать, как его собирать.
Пишеш / редактируеш исходный makе и добавляеш к остальным make-ам (ndk-build). Реально там совсем не сложно.
Документации нет (на самом деле — хз, я не искал или читал), но можно посмотреть другие make-и как писать и интегрировать в ndk-build.
D>Есть "родные" automake/autoconf. Спасибо, очень помогло.
Автотулз не имеют таргетов на Андроид. Забудь.
D>Ещё в libxml2 есть файл Android.bp, про который гуглится, что это файл для blueprint, который как-то связан с сборочной системой с именем "soong".
Это задродство гугловых юных андроидоводов. Это в топку, просто пиши make.
D>Ещё пишут "так откатись на несколько ревизий назад, там есть Android.mk, а это обычный мейкфайл!" D>Нет, сука, если я откачусь на несколько ревизий назад, то я могу получить не ту библиотеку.
Возьми не из Андроидных веток, а нативно из opensource.
PS: Незабудь dtd валидацию в libxml2 отключить, а то за-DDOS-ите и вас забанят (И я не шучу, т.к. такое уже было).
BE>1. Под Андроид нужно разрабатывать из-под Винды или Линукса.
+ (верно) BE>2. Писать на Java or Kotlin.
— (неверно)
BE>3. Нужен мощный компьютер. Не ноутбук.
— (неверно)
D>Второй компьютер с линуксом заводить? Ну, не знаю...
Android.mk нативно работает под Linux. В остальных случаях приходится для него (частично) эмулировать окружение и прочии плюшки.
Можеш поставить себе виртуалку, думаю время сборки не особо критично для Андроид таргетов.
У первого два монитора, если у второго ещё два монитора будет, они на столе не поместятся.
Hint: Ходи на второй (комп) по ssh из первого (компа) через putty. Второму компу вообще мониторы не нужны.
BE>>2. Писать на Java or Kotlin.
В топку (обоих).
D>Я бы с удовольствием перешёл на Линукс обратно, привык с начала нулевых, но под него нет Xcode
Под него есть Vim. Под венду тоже есть Vim. под андроид... тоже есть Vim (но придется попотеть над пересборкой).
D>Ага. Она написана через libxml2. Я ж не буду из С++-кода через JNI дёргать библиотеку, написанную на Java, которая будет вызывать нативную часть на libxml2.
Вполне вариант. Это не больно, многие так делают.
(лично мне такое не приятно, плюс есть опыт в кучерявых эффектах. Но когда деться больше некуда — это работает вполне нормально).
D>Ровно та же история, что и с libxml.
Ну sqlite совсесм простой для интеграции. ЕМНИП у них есть all-in-one-source вариант — просто добавляеш "huge .c" и заголовок.
CS>Но через NDK рисовать низзя
Можно. Создаеш контекст EGL и вперед. В купе с поддержкой нативных App классов одно раздолье: из Жабы остается только тонкая обертка вокруг эвеентов и все, остально нативно на C/C++.
CS>С грустью вспоминаю Windows CE / Windows Mobile.
WCE была достаточно корявой системой. Мне ее не жалко, хотя занимался ею достаточную часть времени, что бы помнить.
CS>Важно то что те 2D примитивы рисования что использует сам Android не доступны. CS>А шрифты, i18n и прочее?
Шрифты — рeчками. i18n — gettext.
Причем WCE ни первым ни вторым особо не отличалась (шрифты сглаживались там пень через жопу, а лайауты диалогов там автоматом под локализованый текст предлагается растягивать разработчика своими собственными руками, что совсем не айс).
CS>Где бы были Windows, MacOS или Linux если бы из них убрать GDI, CoreGraphics и GTK. Что-бы было если убрать DrawText и его поддержку ClearType из Windows API...
Там же. (кстати, в Linux, как в ОС, нет ни GDI ни единого прямого аналога: можете Xlib, а можете GTK, а можете и TUI — это все не части ОС, а сторонии либы).
Здравствуйте, eskimo82, Вы писали:
D>>Я бы с удовольствием перешёл на Линукс обратно, привык с начала нулевых, но под него нет Xcode E>Под него есть Vim. Под венду тоже есть Vim. под андроид... тоже есть Vim (но придется попотеть над пересборкой).
Я в Vim писал под Андроид, пока не было Андроид Студии, а на Эклипс у меня аллергия. А до этого писал в Vim практически вообще всё. Я умею в Vim, но настроить запуск разного и отладку не готов.
Здравствуйте, eskimo82, Вы писали:
CS>>Где бы были Windows, MacOS или Linux если бы из них убрать GDI, CoreGraphics и GTK. Что-бы было если убрать DrawText и его поддержку ClearType из Windows API... E>Там же. (кстати, в Linux, как в ОС, нет ни GDI ни единого прямого аналога: можете Xlib, а можете GTK, а можете и TUI — это все не части ОС, а сторонии либы).
Есть Linux, а есть Linux Desktop. Linux Desktop это Ubuntu, Mint и пр.
Всё что модно сравнивать так это Desktop Windows и Desktop Linux. Windows и GDI/GDI+, GTK и Cairo. То же самое на MacOS и iOS, там CoreGraphics.
Все эти OS предоставляют стабильные graphics API.
Android же есть недо-ось. Половины того что нужно нет.
Здравствуйте, Dair, Вы писали:
D>И я рад за Java (который используется в бэкенде банков, вроде как, да?), но я, конечно, говорил про конкретную область. D>Вот у меня есть кроссплатформенное приложение на Win/Lin/iOS/Android. Критичное иногда к времени выполнения. С++ — единственный выбор для этого. Не то чтобы я сильно фанат С++, но другого не дают.
CS>Есть Linux, а есть Linux Desktop. Linux Desktop это Ubuntu, Mint и пр.
"Linux Desktop" это не ось, а GDE (Graphical Desktop Environment).
CS>Всё что модно сравнивать так это Desktop Windows и Desktop Linux. Windows и GDI/GDI+, GTK и Cairo. То же самое на MacOS и iOS, там CoreGraphics. CS>Все эти OS предоставляют стабильные graphics API.
Еще раз — Linux OS не предоставляет graphics API, поскольку его там нет (фреймбуфер тут не в счет).
CS>Android же есть недо-ось. Половины того что нужно нет.
Андроид — совсем даже неплохая ОС для мобильных девайсов.
D>Я в Vim писал под Андроид, пока не было Андроид Студии, а на Эклипс у меня аллергия. А до этого писал в Vim практически вообще всё. Я умею в Vim, но настроить запуск разного и отладку не готов.
gdb запускается отдельно (надо пробросить порт на десктоп через adb, сервер кладется рядом вместе с нативными либами внутри apk, запускается через adb) от vim (и там есть TUI) или различные графические фронтэнды (ddd, insight).
Но ок, если не нравится — для вижуал студии есть плагины (nsight tegra например). С точки зрения пользователя проект под Андроид ничего не отличается от вендового, работа с отладчиком тоже интегрирована.
ну так чего ж ты молчал? кидай все на сервер, храни/обрабатывай там, а обратно православный JSON в формочке показывай средствами операционки. сервер он все стерпит
а если серьезно, то я бы абстрагировал и БД и xml, и юзал бы системные апи через прослойки без таскания исходников с собой. в этих либах тоже есть баги, вендор оси следит за этим и накатывает обновления. а так придется следить тебе. нафиг надо... ну разве что у тебя там реально важна производительность, но имхо это не про мобилы.
Здравствуйте, Dair, Вы писали:
C>>Ну так а сначала написать на Java, а потом посмотреть на скорость? Или вообще на JS с Electron. D>Требовать от клиента ставить Java при установке на винду — моветон.
Electron — на JS, если нужно UI.
D>Как поставить джаву на iOS, и пустят ли такое приложение в аппстор — поделись.
Kotlin, кстати, поддерживается.
C>>Ну так возьми обычный libxml2 с сайта libxml и поставь в сборку. Там будет и CMake и блэкджек. D>Найти CMake мне не удалось: https://gitlab.gnome.org/GNOME/libxml2/
CMakeFile генерируется из вот этого шаблона: https://gitlab.gnome.org/GNOME/libxml2/blob/master/libxml2-config.cmake.in
Можно просто руками его переименовать.
D>Но и это я решу. Но хотелось-то чтобы было проще. Я тут ною не от невозможности чего-то сделать, а от того что сделано сложно ну вот просто так, без каких-либо реальных причин, просто не подумали.
Нет, они подумали. Android специально ограничивает доступную поверхность доступного API для того, чтобы было проще поддерживать бинарную совместимость.
C>>А они точно нужны? UTF-8 уже доминирует везде. D>Пользовательский контент, теоретически, может быть любым. Пока это валидный XML, надо уметь парсить. В Японии "любят" родную (JIS) кодировку до сих пор, например, это про что я точно знаю.
Что-то не очень понятно, зачем это на Андроиде.
D>>>Что "зачем"? Чтобы собрать libxml2, конечно! C>>Зачем из репозитория Андроида? D>Потому что в репозитории Андроида он ровно тот, который внутри Андроида.
И что?
D>Вообще у меня была мысль с ним слинковаться, но в бандл не пихать, чтобы библиотека пользовалась системным. Но, видимо, не судьба, я уже смирился.
Вот именно поэтому и не дают таким бредом заниматься. Так как это создаёт скрытые зависимости, которые Google может совершенно случайно сломать очередным update'ом системы.
D>>>У меня бизнеслогика на С++, которая собирается и туда, и туда. C>>Вот тут-то и вопрос — если в С++ нужно чтение XML, да ещё с кодировками, то задача выглядит уж совсем точно не для С++. D>Да XML-то пример просто. Так-то, вообще, у меня есть бизнес-логика, которая: D>1. Хранит на "диске" SQLite-базы D>2. "Спрашивает" и "слушает" сеть (сеть на "родных" интерфейсах, через уровень абстракции) D>3. По этой сети получает (в т.ч.) XML определённого формата и JSON определённого формата.
Ну вот и поместить нормализацию на сервер. Но да, тогда С++ ещё как-то вменяемо выглядит. Хотя я бы всё равно писал на чём-нибудь типа Go или C#.
Здравствуйте, Dair, Вы писали:
D>Ты перечитай. Я и взял. В репе Андроида она и лежит, отличие только в наличии Android.bp.
Ну в репозитории Андроида может быть не самая свежая версия. В целом лучше всего брать исходники у изначальных авторов. Хотя к обсуждаемой проблеме это особого отношения не имеет.
D>Я и хочу теперь уже собрать и прилинковать. D>Но есть нюанс. D>Сборка нативного кода в Студии сделана на CMake, а сборка нативного кода в репах Андроида сделана на Blueprint/Soong. D>Стоит совершенно непонятно зачем задача сопряжения одного и другого.
Это ещё зачем? Для подключения сторонней библиотеки в C/C++ проект достаточно указать компилятору на папку с заголовочными файлами и на папку со скомпилированными библиотеками. Больше не требуется ничего. Причём дело не в том, что системы сборки разные — даже при одной системе сборки у проекта и библиотек нет никакого смысла в каком-то их объединение, т.к. именно ради такого разделения и придумано вообще понятие библиотек.
Здравствуйте, alex_public, Вы писали:
D>>Сборка нативного кода в Студии сделана на CMake, а сборка нативного кода в репах Андроида сделана на Blueprint/Soong. D>>Стоит совершенно непонятно зачем задача сопряжения одного и другого.
_>Это ещё зачем? Для подключения сторонней библиотеки в C/C++ проект достаточно указать компилятору на папку с заголовочными файлами и на папку со скомпилированными библиотеками. Больше не требуется ничего. Причём дело не в том, что системы сборки разные — даже при одной системе сборки у проекта и библиотек нет никакого смысла в каком-то их объединение, т.к. именно ради такого разделения и придумано вообще понятие библиотек.
А скомпилированные под 4 архитектуры библиотеки я
а) Возьму где?
б) Хранить буду как?
Здравствуйте, eskimo82, Вы писали:
CS>>Где бы были Windows, MacOS или Linux если бы из них убрать GDI, CoreGraphics и GTK. Что-бы было если убрать DrawText и его поддержку ClearType из Windows API... E>Там же. (кстати, в Linux, как в ОС, нет ни GDI ни единого прямого аналога: можете Xlib, а можете GTK, а можете и TUI — это все не части ОС, а сторонии либы).
Именно поэтому гуй под линукс такой страшнОй и неудобный.
Здравствуйте, Cyberax, Вы писали:
C>Electron — на JS, если нужно UI.
Сейчас скайп у меня занимает 800мб оперативки. Написан на электроне. Ничего нового в нём нет, и когда-то ему хватало 50 мб.
D>>Вообще у меня была мысль с ним слинковаться, но в бандл не пихать, чтобы библиотека пользовалась системным. Но, видимо, не судьба, я уже смирился. C>Вот именно поэтому и не дают таким бредом заниматься. Так как это создаёт скрытые зависимости, которые Google может совершенно случайно сломать очередным update'ом системы.
Update'иться меньше надо. В том смысле, что пить меньше надо, работать меньше надо, жрать меньше надо и т.п. Повадились господа серверные делать хреновые пользовательские продукты (time to market!1111один мы первые!!!111одинодин), а потом их обновлять по сто раз. Это подло по отношению к конечному пользователю.
Здравствуйте, eskimo82, Вы писали:
E>Пишеш / редактируеш исходный makе и добавляеш к остальным make-ам (ndk-build). Реально там совсем не сложно. E>Документации нет (на самом деле — хз, я не искал или читал), но можно посмотреть другие make-и как писать и интегрировать в ndk-build.
А нельзя ли поподробнее рассказать про этот процесс (показать пример makefile уровня "hello world")?
Сейчас я кое-как собираю программы для Андроид, использую Qt-for-android но не покидает ощущение черезжопности процесса.
Здравствуйте, Dair, Вы писали:
D>>>Сборка нативного кода в Студии сделана на CMake, а сборка нативного кода в репах Андроида сделана на Blueprint/Soong. D>>>Стоит совершенно непонятно зачем задача сопряжения одного и другого. _>>Это ещё зачем? Для подключения сторонней библиотеки в C/C++ проект достаточно указать компилятору на папку с заголовочными файлами и на папку со скомпилированными библиотеками. Больше не требуется ничего. Причём дело не в том, что системы сборки разные — даже при одной системе сборки у проекта и библиотек нет никакого смысла в каком-то их объединение, т.к. именно ради такого разделения и придумано вообще понятие библиотек. D>А скомпилированные под 4 архитектуры библиотеки я D>а) Возьму где?
Скачиваешь исходники и собираешь (с помощью системы сборки, предлагаемой автором библиотеки) под нужные тебе архитектуры. Какие проблемы то?
D>б) Хранить буду как?
В каком смысле как? На диске видимо. ))) А какие ещё варианты? )))
A>А нельзя ли поподробнее рассказать про этот процесс (показать пример makefile уровня "hello world")?
Из того что есть сейчас под рукой (первые два варианта не используют инфраструктуру NDK никак, последний вариант — стандартный для Андроида, вам он будет наиболее интересен):
Пример 1: bash 4.3
Ничего делать не надо, кроме как правильно сконфигурить и сбилдить стандартными средствами*:
./configure -prefix=/data/local --exec-prefix=/data/local/bin --host arm-linux-androideabi && make
* Пути к тулчейну для кроскомпиляции должны быть прописаны в текущем PATH:
configure:2767: checking build system type
configure:2781: result: i686-pc-linux-gnu
configure:2801: checking host system type
configure:2814: result: arm-unknown-linux-androideabi
configure:3403: checking for arm-linux-androideabi-gcc
configure:3430: result: /home/user/opt/android-ndk-r10d/toolchains/arm-linux-androideabi-4.9/prebuilt/linux-x86/bin/arm-linux-androideabi-gcc
Пример 2: самописный make для сборки динамической либы
C>>Electron — на JS, если нужно UI.
С>Сейчас скайп у меня занимает 800мб оперативки. Написан на электроне. Ничего нового в нём нет, и когда-то ему хватало 50 мб.
ладно бы нового нет
в нем и старого-то нет, во многом
версия для исправительных учереждений, карцер edition
Здравствуйте, alex_public, Вы писали:
_>Скачиваешь исходники и собираешь (с помощью системы сборки, предлагаемой автором библиотеки) под нужные тебе архитектуры. Какие проблемы то?
Когда библиотека обновится, повторить? Кто этим будет заниматься? Мыжпрограммисты, это всё должно делаться автомагически.
D>>б) Хранить буду как? _>В каком смысле как? На диске видимо. ))) А какие ещё варианты? )))
Диск — он у меня в компьютере.
А основное место кода — в репозитории. Которым пользуются другие разработчики. Разной квалификации.
Глубоко убеждён, что скомпилированные бинарники хранить в репозитории есть зло. В худшем случае для этого есть разные системы пакетов, можно хранить в них.
Задача такая: чтобы собрать проект, имея доступ к репозиторию, заняло минимальное время, и, что тоже немаловажно, было бы максимально просто. В случае разработки под Андроид — "открыть проект с помощью Android Studio, нажать "Build", подождать — готово".
Уже даже в случае с iOS у меня хуже — там cocoapods есть, и пара пакетов, ставящихся homebrew.
Я, вообще, уже сегодня всё сделал. Оно само скачивает (git submodules) нужные репы, запускает нужные скрипты. Всё работает вот как я написал. Правда, только на юниксах (ну или всякие cygwin), но у нас винды нет ни у кого, так что это ладно.
Здравствуйте, eskimo82, Вы писали:
D>>Я в Vim писал под Андроид, пока не было Андроид Студии, а на Эклипс у меня аллергия. А до этого писал в Vim практически вообще всё. Я умею в Vim, но настроить запуск разного и отладку не готов. E>gdb запускается отдельно (надо пробросить порт на десктоп через adb, сервер кладется рядом вместе с нативными либами внутри apk, запускается через adb) от vim (и там есть TUI) или различные графические фронтэнды (ddd, insight).
E>Но ок, если не нравится — для вижуал студии есть плагины (nsight tegra например). С точки зрения пользователя проект под Андроид ничего не отличается от вендового, работа с отладчиком тоже интегрирована.
Для визуал студии, предположу, нужна Винда. А её нет.
А vim/ddd — знакомый мне по десктопно-линуксовой и эмбеддед набор, да.
Но Андроид Студия уже умеет дебажить нативный код, всё и так нормально.
D>Когда библиотека обновится, повторить? Кто этим будет заниматься? Мыжпрограммисты, это всё должно делаться автомагически.
Так можно и скрипт написать.
D>Задача такая: чтобы собрать проект, имея доступ к репозиторию, заняло минимальное время, и, что тоже немаловажно, было бы максимально просто.
Пишется скриптик. (Лет 14 назад у меня на рабочем столе была такая большая кнопка для сборки продукта под WinCE ...)
D>В случае разработки под Андроид — "открыть проект с помощью Android Studio, нажать "Build", подождать — готово".
Решение по сборке не должно касаться "начать кнопочку в IDE" никаким боком. В противном случае возникает куча трудностей которые придется одолевать.
Например: автоматическая сборка в процессе непрерывной интеграции (по событию комита или фикса, либо night builds).
Здравствуйте, eskimo82, Вы писали:
D>>Когда библиотека обновится, повторить? Кто этим будет заниматься? Мыжпрограммисты, это всё должно делаться автомагически. E>Так можно и скрипт написать.
Если ты перечитаешь ветку, то я и пишу о том, как сложно оказалось этот скриптик написать.
Потому что система сборки в NDK не умеет нормально работать с autoconf'ом, поэтому я написал "закат солнца вручную", клоны проектов из репы Андроида не используют (что было бы логично) ту же систему сборки, что и NDK, а ту систему сборки, которую они используют, я не разобрался, как даже собрать.
D>>В случае разработки под Андроид — "открыть проект с помощью Android Studio, нажать "Build", подождать — готово". E>Решение по сборке не должно касаться "начать кнопочку в IDE" никаким боком. В противном случае возникает куча трудностей которые придется одолевать. E>Например: автоматическая сборка в процессе непрерывной интеграции (по событию комита или фикса, либо night builds).
Да, конечно, так и есть, я намеренно упростил. В случае Андроида это
./gradlew assembleDebug
(ну или релиз). Хорошо что ровно это происходит по кнопке "собрать" в Студии.
Здравствуйте, Dair, Вы писали:
_>>Скачиваешь исходники и собираешь (с помощью системы сборки, предлагаемой автором библиотеки) под нужные тебе архитектуры. Какие проблемы то? D>Когда библиотека обновится, повторить? Кто этим будет заниматься? Мыжпрограммисты, это всё должно делаться автомагически.
А как она обновится? Сама, неким магическим способом? Или кто-то всё же запустит ручками команду типа git pull? И что мешает тогда этому кому-то запустить помимо скачивания ещё и сборку?
D>>>б) Хранить буду как? _>>В каком смысле как? На диске видимо. ))) А какие ещё варианты? ))) D>Диск — он у меня в компьютере. D>А основное место кода — в репозитории. Которым пользуются другие разработчики. Разной квалификации. D>Глубоко убеждён, что скомпилированные бинарники хранить в репозитории есть зло. В худшем случае для этого есть разные системы пакетов, можно хранить в них.
Есть разные подходы к данной проблеме. Кто-то считает, что каждый проект должен быть самодостаточным и таскать всё своё с собой (все используемые библиотеки живут в репозитории проекта). А другим удобнее создать свою коллекцию собранных библиотек, используемую из всех проектов. Это в каком-то смысле дело вкуса в организации внутренней инфраструктуры, так что не буду даже пытаться навязывать тут свой вариант.
Но в любом случае это никак не связано с тем фактом, что объединение процессов сборки проекта и используемых им библиотек — это сомнительная идея, которая противоречит самой концепции понятия библиотек (может тогда проще вообще взять чужие hpp/cpp файлы и скопировать к своим исходникам — зачем вообще библиотека, если она всегда будет строиться вместе с проектом?).
D>Задача такая: чтобы собрать проект, имея доступ к репозиторию, заняло минимальное время, и, что тоже немаловажно, было бы максимально просто. В случае разработки под Андроид — "открыть проект с помощью Android Studio, нажать "Build", подождать — готово".
Похоже на какую-то инструкцию для "секретарши-блондинки"... ))) Мне кажется, что программисты всё же могут позволить пару дополнительных шагов по настройке своей инфраструктуры перед началом работы с новым проектом. Тем более, что в случае с тем же Андроидом им перед этим понадобилось поставить как минимум SDK и NDK.
Здравствуйте, alpha21264, Вы писали:
A>А нельзя ли поподробнее рассказать про этот процесс (показать пример makefile уровня "hello world")? A>Сейчас я кое-как собираю программы для Андроид, использую Qt-for-android но не покидает ощущение черезжопности процесса.
Использовать Qt-for-android не хочешь ты.
А то завтра Qt купит какой-нибудь негугл, и Qt перестанет выпускать обновления под андроид, и останешься у разбитого корыта.
Здравствуйте, Dair, Вы писали:
D>Нет сил держать в себе. D>Содержит субъективную ненависть к платформе Android вообще и создателям её отдельных частей в частности.
... и вот опять
None of the following functions can be called with the arguments supplied:
public open fun requestLocationUpdates(p0: Long, p1: Float, p2: Criteria!, p3: PendingIntent!): Unit defined in android.location.LocationManager
public open fun requestLocationUpdates(p0: String!, p1: Long, p2: Float, p3: PendingIntent!): Unit defined in android.location.LocationManager
public open fun requestLocationUpdates(p0: String!, p1: Long, p2: Float, p3: LocationListener!): Unit defined in android.location.LocationManager
Сука, кто так ошибки пишет? С++ уже десятки лет научился говорить, какой конкретно параметр не устраивает!
Господи, что ж за говно-то.
Предполагается, что будет использована последняя указанная сигнатура. this реализует LocationListener.
D>public open fun requestLocationUpdates(p0: String!, p1: Long, p2: Float, p3: LocationListener!): Unit defined in android.location.LocationManager[/q]
D>Предполагается, что будет использована последняя указанная сигнатура. this реализует LocationListener.
D>И вот всё у них так.
Я так понимаю, что this — это кто-то большой, типа Activity. На мой взгляд, удобнее/нагляднее создать обработчик прямо на месте параметра и вызывать из его функций все что требуется. Ибо, если this сам по себе большой и к тому же реализует еще что-то кроме LocationListener, то со временем не разберешься какая функция в этом классе от какого интерфейса и кто ее вызывает.
Здравствуйте, Cyberax, Вы писали:
C>Кто мешает взять обычную libxml, скомпилировать (можно даже статически) и прилинковать её? Кривизна рук опять?
Но вообще, согласись, это как-то неправильно, что каждая програмка под андройд должна принести свою копию libxml, sqlite и прочей мути, при том, что в андроиде все эти библиотеки присутствуют в составе операционной системы.
Здравствуйте, Dair, Вы писали:
D>StackOverflow вообще не в курсе что бывают такие проблемы.
Миллионы мух едят г... программистов пишут программы под андройд и непрерывно строчат что-то на стековерфлов, а стековерфлов о твоей проблемме не в курсе? Это наводит на мысли, что ты идешь своим самобытным путем, и борешься с проблемами, которые на стандартном пути просто не встречаются.
Отсутствие некоего стандартного подхода, позволяющего написать программу, которая с небольшим количеством условной компиляции позволяет сразу покрыть и иОс и андройд, конечно, удручает...
Здравствуйте, Pzz, Вы писали:
Pzz>Но вообще, согласись, это как-то неправильно, что каждая програмка под андройд должна принести свою копию libxml, sqlite и прочей мути, при том, что в андроиде все эти библиотеки присутствуют в составе операционной системы.
Все-таки не каждая. Официально одобренный путь — это Java и публичный API.
И тащить все подряд в публичный API — тоже как-то неправильно.
Здравствуйте, Pzz, Вы писали:
D>>StackOverflow вообще не в курсе что бывают такие проблемы. Pzz>Миллионы мух едят г... программистов пишут программы под андройд и непрерывно строчат что-то на стековерфлов, а стековерфлов о твоей проблемме не в курсе? Это наводит на мысли, что ты идешь своим самобытным путем, и борешься с проблемами, которые на стандартном пути просто не встречаются.
Не знаю как у вас, а у меня на стековерфлов находятся только те ответы, которые я и сам могу найти (затратив некоторое время). Если же я сам не могу найти ответ, то и на стековерфлов ответа не будет, в лучшем случае будет подсказка. Это говорит о том, что стековерфлов не содержит новой информации, а просто конвертирует информацию из документации в ответ. Если вы называете это самобытным путём, то — ок, вполне может быть и такое.
Здравствуйте, Pzz, Вы писали:
D>>StackOverflow вообще не в курсе что бывают такие проблемы. Pzz>Миллионы мух едят г... программистов пишут программы под андройд и непрерывно строчат что-то на стековерфлов, а стековерфлов о твоей проблемме не в курсе? Это наводит на мысли, что ты идешь своим самобытным путем, и борешься с проблемами, которые на стандартном пути просто не встречаются.
Ну, смотри. Стековерфлоу предлагает, например, собрать библиотеки и бинари ввалить в репозиторий (вариант: хранить отдельно).
Это экстенсивный путь развития, я категорически против такого.
Я хочу чтобы на новой машине и/или у нового разработчика было бы минимальное количество шагов, а так же минимальное количество зависимостей.
Для этого надо брать исходники и собирать.
Чтобы собирать, надо (а) исходники (тривиально, вот, пожалуйста, гитхаб) (б) система сборки — вот тут-то у меня и клин (был), потому что система сборки исходников Андроида отличается от системы сборки NDK.
Здравствуйте, B0FEE664, Вы писали:
BFE>Не знаю как у вас, а у меня на стековерфлов находятся только те ответы, которые я и сам могу найти (затратив некоторое время). Если же я сам не могу найти ответ, то и на стековерфлов ответа не будет, в лучшем случае будет подсказка. Это говорит о том, что стековерфлов не содержит новой информации, а просто конвертирует информацию из документации в ответ. Если вы называете это самобытным путём, то — ок, вполне может быть и такое.
Конечно. Но если проблема даже не поминается на стековерфлов, то это означает, что проблема либо очень новая, либо с ней никто никогда не сталкивался.
Здравствуйте, Pzz, Вы писали:
C>>Кто мешает взять обычную libxml, скомпилировать (можно даже статически) и прилинковать её? Кривизна рук опять? Pzz>Но вообще, согласись, это как-то неправильно, что каждая програмка под андройд должна принести свою копию libxml, sqlite и прочей мути, при том, что в андроиде все эти библиотеки присутствуют в составе операционной системы.
Это очень правильно, так как гарантирует, что обновление ОС не сломает программы.
Возможно, что конкретно sqlite и libxml стоило бы включить в официальный ABI и гарантировать стабильность, так как они достаточно стабильны.
Здравствуйте, Dair, Вы писали:
D>NDK спасибо что есть, иначе пришлось бы писать на нелепых языках Java и Kotlin, а они, кроме как в Андроид, нужны вот где:.
C++ во времена 2005 года был невероятно нелепо реализованным стандартом, напомню.
D>Есть у меня библиотека, которая парсит специфического вида XML. На С++. Зависит, как ни странно, от libxml2. Этот libxml2 внутри Андроида есть, НО его нельзя использовать в NDK, потому что нет ни заголовочных файлов, ни нужной .so D>И так с десятком библиотек общего назначения (ещё мне нужен SQLite, например), которые есть внутри Андроида как операционки
Очень и очень плохая затея. При запуске такого "оптимизированного" приложения на девайсе, который собран для каких-то вендоров с их видением libxml все просто может вывалиться.
D>виртуальное поделие ART всё равно использует опенсорсные де-факто стандарты для своей работы.
Очередное предложение написать Гуглу свой клон libxml, хмм. Чего же Линукс c iOS юзает такие неправославные протобуфы ?
D>Ещё в libxml2 есть файл Android.bp, про который гуглится, что это файл для blueprint, который как-то связан с сборочной системой с именем "soong". В документации на этот соонг написано как писать сборочные скрипты, но НИГДЕ не написано, как собрать сам, написанный на очередном нелепом языке go, этот соонг.
Рекомендую собрать через CMake Android ядро с под пяток разным платформ. Хиловат, дасс. У Гугла под все крупные проекты есть свои сборщики.
D>Как такое дичайшее, лютейшее говно собрало на себя имеющиеся 80% рынка — понимать отказываюсь.
Споры с русскими программистами, которые даже образ Андроида не могут собрать самостоятельно и удивляются тому, что он весит больше 10 Гб в архиве.
D>Я-то разберусь, не сегодня-завтра. D>А кривым в Андроиде всё останется.
Андроид решает проблему как собираться и запускаться под сотни разных железных платформ, а не то, как отдать ядерную библиотечку поюзать нативному юзерскому приложению.
Здравствуйте, Protey, Вы писали:
D>>NDK спасибо что есть, иначе пришлось бы писать на нелепых языках Java и Kotlin, а они, кроме как в Андроид, нужны вот где:. P>C++ во времена 2005 года был невероятно нелепо реализованным стандартом, напомню.
Как будто была (и есть) какая-то альтернатива
D>>Есть у меня библиотека, которая парсит специфического вида XML. На С++. Зависит, как ни странно, от libxml2. Этот libxml2 внутри Андроида есть, НО его нельзя использовать в NDK, потому что нет ни заголовочных файлов, ни нужной .so D>>И так с десятком библиотек общего назначения (ещё мне нужен SQLite, например), которые есть внутри Андроида как операционки P>Очень и очень плохая затея. При запуске такого "оптимизированного" приложения на девайсе, который собран для каких-то вендоров с их видением libxml все просто может вывалиться.
Как-то справляются как iOS, так и Linux (последние лет ндцать).
D>>виртуальное поделие ART всё равно использует опенсорсные де-факто стандарты для своей работы. P>Очередное предложение написать Гуглу свой клон libxml, хмм. Чего же Линукс c iOS юзает такие неправославные протобуфы?
Где предложение? Предложение делать по-человечески.
Как раз-таки сделали "свой клон" — у всех есть, а у них нет. Даже, вроде, в WinPhone есть.
P>Рекомендую собрать через CMake Android ядро с под пяток разным платформ. Хиловат, дасс. У Гугла под все крупные проекты есть свои сборщики.
Но тогда почему cmake используется в NDK?
D>>Как такое дичайшее, лютейшее говно собрало на себя имеющиеся 80% рынка — понимать отказываюсь. P>Споры с русскими программистами, которые даже образ Андроида не могут собрать самостоятельно и удивляются тому, что он весит больше 10 Гб в архиве.
Шта?
D>>Я-то разберусь, не сегодня-завтра. D>>А кривым в Андроиде всё останется. P>Андроид решает проблему как собираться и запускаться под сотни разных железных платформ, а не то, как отдать ядерную библиотечку поюзать нативному юзерскому приложению.
Проблему совместимости с зоопарком платформ решает ядро линукса. Много лет уже как решает.
D>>public open fun requestLocationUpdates(p0: String!, p1: Long, p2: Float, p3: LocationListener!): Unit defined in android.location.LocationManager[/q]
LB>Я так понимаю, что this — это кто-то большой, типа Activity. На мой взгляд, удобнее/нагляднее создать обработчик прямо на месте параметра и вызывать из его функций все что требуется. Ибо, если this сам по себе большой и к тому же реализует еще что-то кроме LocationListener, то со временем не разберешься какая функция в этом классе от какого интерфейса и кто ее вызывает.
Оказалось, оно 0.0 считает за Double и во Float не хочет без явного преобразования или указания типа, т.е., 0.0f.
Здравствуйте, BlackEric, Вы писали:
BE>Это наименьшая из проблем. При такой нелюбви к Java проще писать на чем-нибудь другом. Например можно заюзать Kotlin.
K>Да в гробу я видал такие шарашки!
Не лейте, пожалуйста, грязь на такое чистое и светлое слово "шарашка". В шарашках при товарище Сталине строили Кузькину маму. То, во что превратился нынешний Жужел, скорее характеризуется эпитетом порно-кибуц.
K>написали тупейшую нашлёпку на линупс
Ты слишком хорошего мнения об этой кодле рекламщиков и коллекционеров приватных данных. Купили, а не написали.
K>любой аппарат 10-летней давности СПОКОЙНО отрабатывает любое современное приложение
Именно.
D>Как такое дичайшее, лютейшее говно собрало на себя имеющиеся 80% рынка — понимать отказываюсь.
Демпинг. Изначально бесплатная ОСь, разрабатываемая добрым дядей (который потом бОльшую часть убрал в коммерческий Андроид), которую можно поставить на копеечные по стоимости аппараты.
В итоге получилась гонка на выживание, в которой очень мало победителей.
Здравствуйте, Cyberax, Вы писали:
BE>>3. Нужен мощный компьютер. Не ноутбук. C>Я пишу под Андроид на С++ и Kotlin, из Mac OS X и на ноуте. Всё работает нормально.
А сзади меня сейчас сидит человек на гиперпне и ваяет XAML в студии (ГЫ-ГЫ-ГЫ!!!). Ему тоже норм: "солдат спит — служба идёт" — он вообще никуда не торопится.
ЗЫ: Сколько зарабатывает — не знаю, но думаю, ему не сильно торопятся зряплату поднимать.
Всё сказанное выше — личное мнение, если не указано обратное.
Здравствуйте, Pzz, Вы писали:
Pzz>Миллионы мух едят г... программистов пишут программы под андройд и непрерывно строчат что-то на стековерфлов, а стековерфлов о твоей проблемме не в курсе? Это наводит на мысли, что ты идешь своим самобытным путем, и борешься с проблемами, которые на стандартном пути просто не встречаются.
Pzz>Отсутствие некоего стандартного подхода, позволяющего написать программу, которая с небольшим количеством условной компиляции позволяет сразу покрыть и иОс и андройд, конечно, удручает...
ага, ага, миллионы мух...!
я вот эту хрень надолго запомнил в своё время
You can use Enumerable.SequenceEqual method.
using System;
using System.Linq;
...
var a1 = new int[] { 1, 2, 3};
var a2 = new int[] { 1, 2, 3};
var a3 = new int[] { 1, 2, 4};
var x = a1.SequenceEqual(a2); // truevar y = a1.SequenceEqual(a3); // false
If you can't use .NET 3.5 for some reason, your method is OK.
Compiler\run-time environment will optimize your loop so you don't need to worry about performance.
SO местами просто адовая индусятина.
Всё сказанное выше — личное мнение, если не указано обратное.
Здравствуйте, Философ, Вы писали:
BE>>>3. Нужен мощный компьютер. Не ноутбук. C>>Я пишу под Андроид на С++ и Kotlin, из Mac OS X и на ноуте. Всё работает нормально. Ф>А сзади меня сейчас сидит человек на гиперпне и ваяет XAML в студии (ГЫ-ГЫ-ГЫ!!!). Ему тоже норм: "солдат спит — служба идёт" — он вообще никуда не торопится.
Может вам стоит проверить компьютер на вирусы, пойманные при поиске вареза? Так как не думаю, что вы софт покупаете.
Здравствуйте, Kolesiki, Вы писали:
K>А ещё убивает брошеный практически в стадии завершения Win Mobile — будто какая-то мразь из гугла "элопила" проект до полного фэйла, хотя практически ни одной технической причины фэйла нет!
Если имеется в виду WP10, то самому жаль — не понятно на что пересаживаться когда телефон сломается, iOS убог и неюзабелен, а андроид даже не рассматриваю, а если именно WinMobile/CE — вроде там технических проблем хватало, начиная с отсутствия защиты памяти.
Здравствуйте, Somescout, Вы писали:
S>Если имеется в виду WP10, то самому жаль — не понятно на что пересаживаться когда телефон сломается, iOS убог и неюзабелен, а андроид даже не рассматриваю, а если именно WinMobile/CE — вроде там технических проблем хватало, начиная с отсутствия защиты памяти.
WP8 (В отличие от WP7) был вполне работо- и жизнеспособен.
Здравствуйте, Dair, Вы писали:
S>>Если имеется в виду WP10, то самому жаль — не понятно на что пересаживаться когда телефон сломается, iOS убог и неюзабелен, а андроид даже не рассматриваю, а если именно WinMobile/CE — вроде там технических проблем хватало, начиная с отсутствия защиты памяти.
D>WP8 (В отличие от WP7) был вполне работо- и жизнеспособен.
У меня до сих пор WP10, так что я с этим и не спорил.
