B>Ясно (( А можно как-то запустить программу на iOS без AppStore? (типа как apk на андроиде)
Без мака проще всего использовать Cydia impactor. Подсовываешь ему неподписанный ipa, он сам сходит на appstore, сгенерит сертификат (годовой или недельный, в зависимости от твоего аккаунта), подпишет и зальет по usb-шнурку. Но это неудобно при постоянной перезаливке. Для автоматизации этого процессов есть libimobiledevice и куча convenience-оберток вокруг него на гитхабе.

Здравствуйте, vsb, Вы писали:

vsb>Вся суть на мобильных платформах во View, класс которого прописывается во всяких конфигурационных файлах и автоматически инстанцируется.

А насколько сложно обойти весь этот автоматизм? У меня периодически чешутся руки сделать что-нибудь для Android/iOS, но меня всю жизнь воротило от стиля "запускаем студию, жмакаем на создание проекта нужного типа, она сама генерит основной код, мышкой накидываем туда типовых обработчиков, потом чуток правим этот и этот...".

Хочется, чтобы программа начинала исполняться классически — с заданной мною самим точки входа (или нескольких точек различного типа, как в драйверах или службах), и чтобы простейшая программа могла реально состоять из одной строчки типа "вывод hello, world", а при нужде вызывала бы все необходимые системные средства. То есть, чтобы не фреймворк оборачивал программу и навязывал ей свою парадигму взаимодействия, а просто исполнение программы начиналось бы с известного места, и дальнейшее ее поведение определялось бы в первую очередь самой программой (ну и системными ограничениями, само собой).

Еще раздражает принятый в андроиде подход рисовать элементы управления в отдельном редакторе, под каждый набор разрешений экрана, и подключать их к приложению через файлы описания. В винде я могу на выбор использовать редактор ресурсов, или вручную создавать в программе шаблон диалога, или вовсе создавать каждый элемент по отдельности. А в андроиде это возможно? Или тамошний гуй умеет создавать элементы только по описаниям из файлов?

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>А насколько сложно обойти весь этот автоматизм? У меня периодически чешутся руки сделать что-нибудь для Android/iOS, но меня всю жизнь воротило от стиля "запускаем студию, жмакаем на создание проекта нужного типа, она сама генерит основной код, мышкой накидываем туда типовых обработчиков, потом чуток правим этот и этот...".

ЕМ>Хочется, чтобы программа начинала исполняться классически — с заданной мною самим точки входа (или нескольких точек различного типа, как в драйверах или службах), и чтобы простейшая программа могла реально состоять из одной строчки типа "вывод hello, world", а при нужде вызывала бы все необходимые системные средства. То есть, чтобы не фреймворк оборачивал программу и навязывал ей свою парадигму взаимодействия, а просто исполнение программы начиналось бы с известного места, и дальнейшее ее поведение определялось бы в первую очередь самой программой (ну и системными ограничениями, само собой).

Насколько я знаю нельзя. main инкапсулирован внутри Dalvik VM. Поэтому полагаться можно только на компоненты приложения: Application, Activity, Service и т.д.
В андроиде свой "особенный" подход к управлению процессами и элементами приложения: приостанавливание, кеширование, убивание (иногда без колбека).
Например, правильного способа завершения процесса изнутри самого этого процесса нет, это должна сделать система, и теоретически может это сделать в любой момент. И так далее.


ЕМ>Еще раздражает принятый в андроиде подход рисовать элементы управления в отдельном редакторе, под каждый набор разрешений экрана, и подключать их к приложению через файлы описания. В винде я могу на выбор использовать редактор ресурсов, или вручную создавать в программе шаблон диалога, или вовсе создавать каждый элемент по отдельности. А в андроиде это возможно? Или тамошний гуй умеет создавать элементы только по описаниям из файлов?

Можно создавать вьюшки в рантайме.
Если не нравится XML есть Kotlin ANKO, гугл еще делает какой то Jetpack Compose.
Кстати, некоторые прутся от Flutter'овского подхода описания UI:

class MyApp extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return Container(
      decoration: BoxDecoration(color: Colors.white),
      child: Center(
        child: Text(
          'Hello World',
          textDirection: TextDirection.ltr,
          style: TextStyle(
            fontSize: 32,
            color: Colors.black87,
          ),
        ),
      ),
    );
  }
}

Но лично мне хочется блевануть
Имхо, xml — норм

>под каждый набор разрешений экрана,

Можно обойтись одним XML с описанием интерфейса одного окна на все случаи жизни, никто ни кого не заставляет.
И разные макеты делают не под разрешения экрана, а под размеры (смартфон/планшет и портрет/лэндскейп) в случае если это действительно нужно.
Под разные разрешения нужны разные картинки (mdpi, hdpi, xhdpi, xxhdpi...), но это может решаться векторными форматами картинок.

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Еще раздражает принятый в андроиде подход рисовать элементы управления в отдельном редакторе, под каждый набор разрешений экрана, и подключать их к приложению через файлы описания. В винде я могу на выбор использовать редактор ресурсов, или вручную создавать в программе шаблон диалога, или вовсе создавать каждый элемент по отдельности. А в андроиде это возможно? Или тамошний гуй умеет создавать элементы только по описаниям из файлов?

Элементы управления создавать динамически, конечно, можно. Но и в редакторе у них задают не фиксированные координаты под конкретное разрешение, а относительное положение, в привязке к остальным контролам и к краям экрана. Это и в Android, и в iOS.

Здравствуйте, Basil2, Вы писали:

B>Хочу по-быстрому сделать свое приложение для мобилок. До этого программировал только под винду на С++ с вкраплениями Python и Java Script. А хочется следующего:

B>Что посоветуете?

Когда писал приложения под Android и iOS без знания Java и Objective-C, ни одной книги так и не прочитал, т.к. тема как по мне рутинная. В интернете множество статей, по которым по необходимости можно разбираться (копи-пастить). Также есть stackoverflow, хотя там ошибок в ответах где-то 40%. У Apple документация редких фич поскуднее, чем у Android, в котором куча разборов примеров на все случаи жизни.

Здравствуйте, Евгений Музыченко, Вы писали:

vsb>>Вся суть на мобильных платформах во View, класс которого прописывается во всяких конфигурационных файлах и автоматически инстанцируется.

ЕМ>А насколько сложно обойти весь этот автоматизм?

Ну в iOS в проекте есть автосгенерированный маленький main.m. Думаю, можно всё остальное грохнуть и там писать код. Правда не знаю, как iOS отнесётся к такому приложению, которое не создаёт окон, возможно по таймауту грохнет.

Насчёт андроида не подскажу, не видел там main. Судя по всему там да, всё на фреймворке завязано, который читает XML файл манифеста и создаёт объект указанных классов Application, Activity и тд.

ЕМ>Хочется, чтобы программа начинала исполняться классически — с заданной мною самим точки входа (или нескольких точек различного типа, как в драйверах или службах), и чтобы простейшая программа могла реально состоять из одной строчки типа "вывод hello, world", а при нужде вызывала бы все необходимые системные средства. То есть, чтобы не фреймворк оборачивал программу и навязывал ей свою парадигму взаимодействия, а просто исполнение программы начиналось бы с известного места, и дальнейшее ее поведение определялось бы в первую очередь самой программой (ну и системными ограничениями, само собой).

Моё имхо, такое можно делать уже когда примерно разобрался в том, что генерируют мастеры. Тем более, что генерируют они обычно не так много. А так сходу — не уверен, что в этом можно за ощутимое время разобраться, т.к. так никто не делает и придется всё расковыривать самому. А в iOS ещё и исходников нет, придётся дизассемблером смореть.

ЕМ>Еще раздражает принятый в андроиде подход рисовать элементы управления в отдельном редакторе, под каждый набор разрешений экрана, и подключать их к приложению через файлы описания. В винде я могу на выбор использовать редактор ресурсов, или вручную создавать в программе шаблон диалога, или вовсе создавать каждый элемент по отдельности. А в андроиде это возможно? Или тамошний гуй умеет создавать элементы только по описаниям из файлов?

Конечно возможно. Многие программисты именно в коде и предпочитают создавать интерфейс, что в андроиде, что в iOS. Хотя я считаю, что типовые интерфейсы надо стараться писать декларативно, но это лишь моё мнение. Кстати мне, лично, в андроиде почти всегда было проще редактировать XML-файл, а не тыкаться в визуальном редакторе. Благо там всё прекрасно синхронизируется во все стороны и XML вполне читаемый.

Здравствуйте, Quadri, Вы писали:

Q>main инкапсулирован внутри Dalvik VM. Поэтому полагаться можно только на компоненты приложения: Application, Activity, Service и т.д.

Как элемент приложения может быть инкапсулирован в среду исполнения? Другое дело, что "main" — это элемент не приложения вообще, а прежде всего традиционной программы на C/C++. Соответственно, в Android где-то указываются точки, с которых начинается исполнение кода для каждого типа компонент, способы передачи им параметров и т.п.

Q>В андроиде свой "особенный" подход к управлению процессами и элементами приложения: приостанавливание, кеширование, убивание (иногда без колбека).
Q>Например, правильного способа завершения процесса изнутри самого этого процесса нет, это должна сделать система, и теоретически может это сделать в любой момент.

Это я знаю, но все это означает всего лишь, что андроид рассматривает приложение, как набор процедур/функций, каждая из которых вызывается в определенных условиях, получает определенные параметры, и подчиняется определенным правилам. Примерно так же любая ОС взаимодействует с любым из своих драйверов.

ЕМ>>Еще раздражает принятый в андроиде подход рисовать элементы управления в отдельном редакторе, под каждый набор разрешений экрана, и подключать их к приложению через файлы описания. В винде я могу на выбор использовать редактор ресурсов, или вручную создавать в программе шаблон диалога, или вовсе создавать каждый элемент по отдельности. А в андроиде это возможно? Или тамошний гуй умеет создавать элементы только по описаниям из файлов?

Q>Можно создавать вьюшки в рантайме.

Это радует.

Q>Если не нравится XML есть Kotlin ANKO, гугл еще делает какой то Jetpack Compose.

Мне не нравится в первую очередь сама идея непременного использования какого-либо специнструмента, помимо языка программирования и транслятора с него. Другое дело, что использование внешних инструментов может быть или проще, или надежнее, но оно не должно быть обязательным. В идеале, реализация любого универсального ЯП в любой ОС должна позволять сделать на нем любое теоретически возможное приложение без привлечения дополнительных инструментов. Если это невозможно, то и реализация ущербна.

Q>Можно обойтись одним XML с описанием интерфейса одного окна на все случаи жизни, никто ни кого не заставляет.
Q>И разные макеты делают не под разрешения экрана, а под размеры (смартфон/планшет и портрет/лэндскейп) в случае если это действительно нужно.
Q>Под разные разрешения нужны разные картинки (mdpi, hdpi, xhdpi, xxhdpi...), но это может решаться векторными форматами картинок.

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

Здравствуйте, vsb, Вы писали:

vsb>Думаю, можно всё остальное грохнуть и там писать код. Правда не знаю, как iOS отнесётся к такому приложению, которое не создаёт окон

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

vsb>Судя по всему там да, всё на фреймворке завязано, который читает XML файл манифеста и создаёт объект указанных классов Application, Activity и тд.

Получается, что минимальный комплект приложения, помимо собственно кода — это описание "активностей", вызываемых системой, а все остальное можно сделать непосредственно из кода? Или есть еще что-то, чего из кода не сделаешь, и снова потребуются дополнительные файлы?

vsb>Моё имхо, такое можно делать уже когда примерно разобрался в том, что генерируют мастеры.

Понятно, что раскопать можно. Но на ту же винду, если помните, отродясь была документация о том, как это реализовано на самом низком уровне — формат EXE-файла, параметры точки входа, тип и смысл возвращаемого значения. То есть, описание собственно ABI, как взаимодействия системы и приложения, а не того, как с помощью предлагаемых инструментов побыстрее слепить работоспособное приложение.

vsb>считаю, что типовые интерфейсы надо стараться писать декларативно

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

Здравствуйте, Евгений Музыченко, Вы писали:

vsb>>Думаю, можно всё остальное грохнуть и там писать код. Правда не знаю, как iOS отнесётся к такому приложению, которое не создаёт окон

ЕМ>О том, чтоб не создавать окон, речи не идет — винда таких приложений тоже не любит. Речь о том, чтобы все действия были описаны в коде, и управление (насколько это возможно) шло изнутри программы, а не снаружи.

Ну в iOS оно так и происходит. Там вроде есть немного магии со Storyboards но если их не использовать, можно всё делать исключительно на Objective C коде.

ЕМ>Получается, что минимальный комплект приложения, помимо собственно кода — это описание "активностей", вызываемых системой, а все остальное можно сделать непосредственно из кода? Или есть еще что-то, чего из кода не сделаешь, и снова потребуются дополнительные файлы?

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

ЕМ>Понятно, что раскопать можно. Но на ту же винду, если помните, отродясь была документация о том, как это реализовано на самом низком уровне — формат EXE-файла, параметры точки входа, тип и смысл возвращаемого значения. То есть, описание собственно ABI, как взаимодействия системы и приложения, а не того, как с помощью предлагаемых инструментов побыстрее слепить работоспособное приложение.

Не, такого современные производители не любят. Все эти описания это же как гири на ногах, которые им будут мешать переделывать это всё, если они захотят. Поэтому они максимально абстрагируют и в лучше случае остаётся совместимость на уровне публичного API, да и ту могут ломать.

vsb>>считаю, что типовые интерфейсы надо стараться писать декларативно

ЕМ>В большинстве случаев это еще и банально удобнее, но в некоторых случаях удобнее таки в коде. Например, бывает нужна серия однотипных индикаторов (скажем, показаний датчиков, уровней звука в каналах потока и т.п.), и сперва выписывать, а затем править все это становится утомительно.

Не спорю, надо делать как удобней в конкретном случае.

Здравствуйте, Евгений Музыченко, Вы писали:

Q>>main инкапсулирован внутри Dalvik VM. Поэтому полагаться можно только на компоненты приложения: Application, Activity, Service и т.д.

ЕМ>Как элемент приложения может быть инкапсулирован в среду исполнения? Другое дело, что "main" — это элемент не приложения вообще, а прежде всего традиционной программы на C/C++.

в том во что в итоге компилируется java код нет никакого main()
Вот тут какие то подробности https://android.jlelse.eu/android-application-launch-explained-from-zygote-to-your-activity-oncreate-8a8f036864b


ЕМ>Соответственно, в Android где-то указываются точки, с которых начинается исполнение кода для каждого типа компонент, способы передачи им параметров и т.п.

Application, Activity, Service имеют метод onCreate()


ЕМ>Мне не нравится в первую очередь сама идея непременного использования какого-либо специнструмента, помимо языка программирования и транслятора с него. Другое дело, что использование внешних инструментов может быть или проще, или надежнее, но оно не должно быть обязательным. В идеале, реализация любого универсального ЯП в любой ОС должна позволять сделать на нем любое теоретически возможное приложение без привлечения дополнительных инструментов. Если это невозможно, то и реализация ущербна.

Вот пример без спец инструмента:
https://medium.com/@authmane512/how-to-build-an-apk-from-command-line-without-ide-7260e1e22676
strings.xml я думаю можно тоже выкинуть


ЕМ>Возможно, у меня устаревшие сведения. Все, что мне попадалось про GUI под андроид, в обязательном порядке требовало описывать отдельную форму под каждое из набора типовых разрешений экрана.

Не очень понимаю о чем речь

Здравствуйте, vsb, Вы писали:

vsb>Ну в iOS оно так и происходит. Там вроде есть немного магии со Storyboards но если их не использовать, можно всё делать исключительно на Objective C коде.

А под iOS можно писать на чистом C/C++? Я имею в виду прежде всего Core Language и совместимость по вызовам/типам. Или нужно обязательно делать переходники на Objective?

Здравствуйте, Quadri, Вы писали:

Q>в том во что в итоге компилируется java код нет никакого main()

Дык, в исполняемом коде никогда нет никакого main — это во многих языках просто имя функции/модуля, куда передается управление при старте. Но в любой адекватной ОС должна быть четкая граница между системой и приложением, которая пересекается при активации приложения и/или его компонент. А уже дальше внутри приложения могут быть автоматически сгенерированные обертки, которые в итоге передают управление коду, который написал непосредственно программист. Вот мне и интересно, насколько близко к этой внешней границе можно подобраться в мобильных системах, и насколько сложно это сделать.

Q>Вот тут какие то подробности https://android.jlelse.eu/android-application-launch-explained-from-zygote-to-your-activity-oncreate-8a8f036864b

Спасибо, дельно написано, обязательно почитаю.

ЕМ>>Соответственно, в Android где-то указываются точки, с которых начинается исполнение кода для каждого типа компонент, способы передачи им параметров и т.п.

Q>Application, Activity, Service имеют метод onCreate()

Это, как я понимаю, обычная функция-метод класса Java. А нативный код на C/C++ напрямую из системы запустить можно, или только через переходник на Java?

ЕМ>>Все, что мне попадалось про GUI под андроид, в обязательном порядке требовало описывать отдельную форму под каждое из набора типовых разрешений экрана.

Q> Не очень понимаю о чем речь

Ну я в разное время (и пять лет назад, и год) пытался читать разные статьи/книжки о программировании под андроид. И везде писалось, что каждая экранная форма с полями, переключателями, кнопками и и т.п. должна рисоваться в редакторе форм (или как он там называется), отдельно под каждую группу типовых разрешений экрана. О том, что можно сделать одну форму и задать правила ее масштабирования, впервые узнал только сегодня из этой темы. Возможно, это доступно только в относительно новых андроидах и/или верстиях IDE.

Здравствуйте, Евгений Музыченко, Вы писали:

vsb>>Ну в iOS оно так и происходит. Там вроде есть немного магии со Storyboards но если их не использовать, можно всё делать исключительно на Objective C коде.

ЕМ>А под iOS можно писать на чистом C/C++? Я имею в виду прежде всего Core Language и совместимость по вызовам/типам. Или нужно обязательно делать переходники на Objective?

Можно. Но любой Objective C API будет мягко говоря не очень удобно вызывать. Примерно как ты COM-объекты в C будешь использовать, если делал такое. Это про C. Про C++ не знаю, но думаю, то же самое. Кроме Objective C есть и чистые C API, их, конечно, использовать несложно, собственно когда из Objective C их используешь. Но все стандартные контролы это Objective C. А вот какую-нибудь игру, от которой надо создать окно и там через Metal рисовать, думаю, можно и на C написать вполне.

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Ну я в разное время (и пять лет назад, и год) пытался читать разные статьи/книжки о программировании под андроид. И везде писалось, что каждая экранная форма с полями, переключателями, кнопками и и т.п. должна рисоваться в редакторе форм (или как он там называется), отдельно под каждую группу типовых разрешений экрана. О том, что можно сделать одну форму и задать правила ее масштабирования, впервые узнал только сегодня из этой темы. Возможно, это доступно только в относительно новых андроидах и/или верстиях IDE.

Я думаю, имеются в виду совсем разные экраны. Например телефон и планшет. Можно, конечно, форму из телефона просто смасштабировать на планшет, но обычно делают разные UI, например то, что в телефоне идёт как несоклько разных экранов, на планшете можно разместить на одном экране. Т.е. разные физические размеры экранов по-хорошему требуют разного интерфейса. Для этих случаев делают разные View. А когда просто немного отличающиеся экраны или когда у одного телефона разрешение двойное или тройное за счёт мелких пикселей, при этом физические размеры экрана одинаковые, для такого используется один экран, который по определенным алгоритмам растягивается под нужный размер.

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Дык, в исполняемом коде никогда нет никакого main — это во многих языках просто имя функции/модуля, куда передается управление при старте. Но в любой адекватной ОС должна быть четкая граница между системой и приложением, которая пересекается при активации приложения и/или его компонент. А уже дальше внутри приложения могут быть автоматически сгенерированные обертки, которые в итоге передают управление коду, который написал непосредственно программист. Вот мне и интересно, насколько близко к этой внешней границе можно подобраться в мобильных системах, и насколько сложно это сделать.

В WinAPI программах есть же функция WinMain(?) с циклом обработки очереди сообщений.
На Java уровне ничего такого нет доступного программисту нет.
В С++ коде что то похожее есть: https://github.com/googlesamples/android-ndk/blob/master/native-activity/app/src/main/cpp/main.cpp#L303
Но по сути тут используется обертка поверх все той же самой Activity, называется NativeActivity, которая в том же методе onCreate передает управление в C++ код.
Так что как ни крути, та самая четкая граница до которой можно дотянуться — это onCreate компонентов приложения.


Q>>Application, Activity, Service имеют метод onCreate()

ЕМ>Это, как я понимаю, обычная функция-метод класса Java. А нативный код на C/C++ напрямую из системы запустить можно, или только через переходник на Java?

Да, обычная Java функция — метод жизненного цикла компонента.
С++ только через JNI, то есть да переходники из Java.
Лично я не знаю других вариантов.


ЕМ>Ну я в разное время (и пять лет назад, и год) пытался читать разные статьи/книжки о программировании под андроид. И везде писалось, что каждая экранная форма с полями, переключателями, кнопками и и т.п. должна рисоваться в редакторе форм (или как он там называется), отдельно под каждую группу типовых разрешений экрана. О том, что можно сделать одну форму и задать правила ее масштабирования, впервые узнал только сегодня из этой темы. Возможно, это доступно только в относительно новых андроидах и/или верстиях IDE.

Всегда так было, это скорее речь шла про набор картинок под экрана разной плотности

Здравствуйте, Quadri, Вы писали:

Q>В WinAPI программах есть же функция WinMain(?)

Я вчера как раз подчеркивал, что точкой входа она является только в 16-разрядных процессах. В 32-разрядных точка входа в процесс вызывается без параметров (начиная с Висты добавили один параметр), а WinMain вызывает уже стандартная обертка из CRT.

Q>Так что как ни крути, та самая четкая граница до которой можно дотянуться — это onCreate компонентов приложения.

Понятно, спасибо.

Здравствуйте, Quadri, Вы писали:

Q>В WinAPI программах есть же функция WinMain(?) с циклом обработки очереди сообщений.

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