Как быстро войти в тему Android и iOS? - Мобильные устройства

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

1. Чтобы пошагово (и со ссылками на софт) показали, какой софт надо ставить, как закинуть готовый код на мобильник, как потом выложить в магазин — всю технологическую цепочку.

2. Как устроена main() у мобилок, и какие есть особенности разработки. А еще лучше чтобы вообще избежать особенностей. Мне просто надо получить поток байтов с компа и вывести на экран в мобилке.

3. Желательно не изучать новые языки. Ну и код желательно между платформами чтобы совпадал. Это, вроде бы, из перечисленного только для JS возможно?

4. Желательно вообще изучать все по-минимуму, лишь бы сделать proof-of-concept с сетью (или обменом по проводу) и выводом на экран.

Я посмотрел бегло существующие курсы, но там все чересчур основательно: основы Java, работа с данными, все дела. А хочется быстро запилить main() и потраить платформу

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

main в мобилках вызывает библиотечную функцию, ничего интересного в нём нет, обычно он просто автосгенерирован и никто туда не смотрит. Вся суть на мобильных платформах во View, класс которого прописывается во всяких конфигурационных файлах и автоматически инстанцируется. Для iOS поищи простейшие туториалы, создай в Xcode проект на основе простого шаблона с одним View и всё. Для того, чтобы сделать PoC, много изучать не надо. Для Android вроде то же самое. На JavaScript всё будет ещё проще, если примерно представляешь, как оно всё устроено. Если не представляешь и надо веб-технологии учить с нуля, возможно проще будет сразу начать с мобилок. Имей в виду, что приложения для iOS нормально писать можно только на маке.

B>Я посмотрел бегло существующие курсы, но там все чересчур основательно: основы Java, работа с данными, все дела. А хочется быстро запилить main() и потраить платформу

попробуй гугловый flutter

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

B>Хочу по-быстрому сделать свое приложение для мобилок. До этого программировал только под винду на С++ с вкраплениями Python и Java Script. А хочется следующего:
B>1. Чтобы пошагово (и со ссылками на софт) показали, какой софт надо ставить, как закинуть готовый код на мобильник, как потом выложить в магазин — всю технологическую цепочку.
B>2. Как устроена main() у мобилок, и какие есть особенности разработки. А еще лучше чтобы вообще избежать особенностей. Мне просто надо получить поток байтов с компа и вывести на экран в мобилке.
Если хочется main то надо смотреть в сторону SL4A (пример пример обмнена на lua)
B>3. Желательно не изучать новые языки. Ну и код желательно между платформами чтобы совпадал. Это, вроде бы, из перечисленного только для JS возможно?
B>4. Желательно вообще изучать все по-минимуму, лишь бы сделать proof-of-concept с сетью (или обменом по проводу) и выводом на экран.
B>Я посмотрел бегло существующие курсы, но там все чересчур основательно: основы Java, работа с данными, все дела. А хочется быстро запилить main() и потраить платформу

B>Что посоветуете?
Для proof-of-concept не важно на чем писать. так чото пишите на jave в android studio. после c++ будет всё элементарно: java runtime, android os, публикация
retrofit можно испольовать что бы по быстрому данные по сети получать.

ps: про ios ничего не скажу, но для "вообще изучать все по-минимуму, лишь бы сделать proof-of-concept с сетью (или обменом по проводу) и выводом на экран" можно игровой движок использовать libgdx

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

vsb>Имей в виду, что приложения для iOS нормально писать можно только на маке.

А можно тут поподробнее? Мне только сделать клон андроидовского приложения (получить данные по проводу/WiFi и отобразить картинку на экране).

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

vsb>>Имей в виду, что приложения для iOS нормально писать можно только на маке.

B>А можно тут поподробнее? Мне только сделать клон андроидовского приложения (получить данные по проводу/WiFi и отобразить картинку на экране).

Для сборки, запуска, посылки в AppStore нужен Xcode, который есть только для macOS. macOS можно теоретически запускать в виртуалке на обычном компьютере, но это немного нелегально и может быть геморройно. Проще всего это делать на нормальном маке.

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

B>>А можно тут поподробнее? Мне только сделать клон андроидовского приложения (получить данные по проводу/WiFi и отобразить картинку на экране).

vsb>Для сборки, запуска, посылки в AppStore нужен Xcode, который есть только для macOS.

Ясно (( А можно как-то запустить программу на iOS без AppStore? (типа как apk на андроиде)

vsb> macOS можно теоретически запускать в виртуалке на обычном компьютере, но это немного нелегально и может быть геморройно. Проще всего это делать на нормальном маке.

Насколько старый мак подойдет для этих целей? (Новые что-то дорогие для proof-of-concept)

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

B>>>А можно тут поподробнее? Мне только сделать клон андроидовского приложения (получить данные по проводу/WiFi и отобразить картинку на экране).

vsb>>Для сборки, запуска, посылки в AppStore нужен Xcode, который есть только для macOS.

B>Ясно (( А можно как-то запустить программу на iOS без AppStore? (типа как apk на андроиде)

Конечно можно. Подключаешь айфон к маку, запускаешь Xcode, он всё сам сделает. Приложение подписывается твоей подписью разработчика и может работать вроде 15 дней, для разработки/демонстрации/ограниченного тестирования вполне хватает. Для широкого тестирования есть TestFlight, там приложение надо залить в AppStore, они его даже как-то проверят, но в публичном магазине оно не появится, можно будет добавить много тестеров, они его смогут установить.

vsb>> macOS можно теоретически запускать в виртуалке на обычном компьютере, но это немного нелегально и может быть геморройно. Проще всего это делать на нормальном маке.

B>Насколько старый мак подойдет для этих целей? (Новые что-то дорогие для proof-of-concept)

Ну мой 6-летний макбук поддерживает последнюю macOS, думаю 5-10 летний должен работать, но лучше погуглить. Последняя macOS не обязательна вроде, обычно последний Xcode работает на предпоследней версии, но точно не проверял.

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

B>>Насколько старый мак подойдет для этих целей? (Новые что-то дорогие для proof-of-concept)

vsb>Ну мой 6-летний макбук поддерживает последнюю macOS, думаю 5-10 летний должен работать, но лучше погуглить. Последняя macOS не обязательна вроде, обычно последний Xcode работает на предпоследней версии, но точно не проверял.

Спасибо. Я тут подумал, что проще наверное будет купить "облачный" мак. Хотя непонятно, как в этом случае подключать телефон.

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

B>>2. Мне просто надо получить поток байтов с компа и вывести на экран в мобилке.
B>>Что посоветуете?

Z>А зачем вообще что-то знать про "мобилки" в вашем случае?
Z>Просто отправляй поток байт на сервер, на мобилке открывай браузер,
Z>подключайся к серверу и с помощью javascript отображай данные в нужном виде.
Z>python на сервер, javascript на клиенте, ничего нового учить не надо.

Я думал о таком варианте, но у него есть два недостатка:

1. Нужен сервер.
2. Нужно разделять пользователей, т.к. данные у каждого пользователя свои.

Т.е. придется делать авторизацию, следить чтобы сервер не проседал под нагрузкой и т.п. Я решил что сервер тут точно лишний, хотя да, технически это более стандартное решение.

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

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

B>>>2. Мне просто надо получить поток байтов с компа и вывести на экран в мобилке.
B>>>Что посоветуете?

Z>>А зачем вообще что-то знать про "мобилки" в вашем случае?
Z>>Просто отправляй поток байт на сервер, на мобилке открывай браузер,
Z>>подключайся к серверу и с помощью javascript отображай данные в нужном виде.
Z>>python на сервер, javascript на клиенте, ничего нового учить не надо.

B>Я думал о таком варианте, но у него есть два недостатка:

B>1. Нужен сервер.
B>2. Нужно разделять пользователей, т.к. данные у каждого пользователя свои.

B>Т.е. придется делать авторизацию, следить чтобы сервер не проседал под нагрузкой и т.п. Я решил что сервер тут точно лишний, хотя да, технически это более стандартное решение.

сервер как еще один второй компьютер не нужен. Делаешь сервер на том компе с которого надо передавать данные
можно встроенными средсвами виндов можно любой другой самый простой
Если сервер будет работать на локальном адресе типа 127.0.0.0 то авторизации не надо при условии, что с одного компа одному мобильнику
(вай-фай роутер или встроенный в нотубук нужен)

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

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

На компе поднять сервер с WebSockets, на мобилке заюзать их через JavaScript. Вроде, должно работать и не очень сложно. При этом JS можно отлаживать на том же компе, а приложение на мобилки сгенерировать при помощи PhoneGap. Даже по идее ничего нового учить не придется

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

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

Возможно, поможет Qt Mobile. Это кроссплатформенный фреймфорк на C++, которое умеет под мобильные.

Сам не пробовал, но, возможно, будет проще всего въехать.

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

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

B>>>2. Мне просто надо получить поток байтов с компа и вывести на экран в мобилке.
B>>>Что посоветуете?

Z>>А зачем вообще что-то знать про "мобилки" в вашем случае?
Z>>Просто отправляй поток байт на сервер, на мобилке открывай браузер,
Z>>подключайся к серверу и с помощью javascript отображай данные в нужном виде.
Z>>python на сервер, javascript на клиенте, ничего нового учить не надо.

B>Я думал о таком варианте, но у него есть два недостатка:

B>1. Нужен сервер.
B>2. Нужно разделять пользователей, т.к. данные у каждого пользователя свои.

B>Т.е. придется делать авторизацию, следить чтобы сервер не проседал под нагрузкой и т.п. Я решил что сервер тут точно лишний, хотя да, технически это более стандартное решение.

Можно Progressive Web Apps (PWA) посмотреть и firebase для хранения данных например вместо сервера и авторизации.

Никаких сторв, при этом фуллскрин на мобиле и шорткат как для нормального приложения.

Сам ещё не пробовал но собираюсь

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

bnk>Можно Progressive Web Apps (PWA) посмотреть и firebase для хранения данных например вместо сервера и авторизации.
bnk>Никаких сторв, при этом фуллскрин на мобиле и шорткат как для нормального приложения.

Интересно, но чем они лучше PhoneGap?

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

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

bnk>>Можно Progressive Web Apps (PWA) посмотреть и firebase для хранения данных например вместо сервера и авторизации.
bnk>>Никаких сторв, при этом фуллскрин на мобиле и шорткат как для нормального приложения.

B>Интересно, но чем они лучше PhoneGap?

Это не фреймворк, это стандарт (драфт) W3C для браузеров.
Реализаций/библиотек/поддержка есть уже много где, например angular 6 (google), pwa builder (microsoft)

Про angular 6 например
https://medium.com/@joseant.ruizsantiago/building-a-pwa-with-angular-6-5735d7308d25

"Киллер фича" PWA, его можно "установить" на телефон в обход всех сторов, в один клик из браузера.
По сути, речь просто про новый файл-манифест, минимально его можно хоть в index.html прописать <link rel="...">, и будет тебе приложение на телефоне

То есть, без каких-либо фреймворков.

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

bnk>"Киллер фича" PWA, его можно "установить" на телефон в обход всех сторов, в один клик из браузера.
bnk>По сути, речь просто про новый файл-манифест, минимально его можно хоть в index.html прописать <link rel="...">, и будет тебе приложение на телефоне

bnk>То есть, без каких-либо фреймворков.

А продавать тогда как?

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

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

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

D>Возможно, поможет Qt Mobile. Это кроссплатформенный фреймфорк на C++, которое умеет под мобильные.

D>Сам не пробовал, но, возможно, будет проще всего въехать.

Адобовский Флекс-билдер, работает на андроид (лично проверено) и на ай-ос и винде и мак-ос
и Дельфи
Также есть много онлайн конструкторов, и полу-онлайн, например IntelXDK
Также игровые фреймворки как правило имеют средства GUI, конструкторы и подходят — Unreal и юнити
хорошая документация, видео уроки, примеры кода. живые форумы. Сетевые игры на них делают
так что с обменом данными не должно быть проблем.

Если предположить наличие интернета хотя бы на мобилке то с нее раздаем вай-фай или юсб на ПК
обмен можно тогда на стороннем сервисе типа pusher — своего сервера не надо, либы на все языки включая ява-скрипт

vsb>Для сборки, запуска,
Строго говоря не нужен. Всё прекрасно собирается-подписывается под линухой (theos) и заливается по шнурку на девайс (libimobiledevice).

vsb>посылки в AppStore нужен Xcode,
Пока еще нужен, но над этим создатели неофициального toolchain'а theos тоже работают.

Для чего действительно нужен — так это для удобной навигации по проекту в Xcode, для отладки, и для формошлепства xib/storyboard.

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.

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

От:	Basil2	https://starostin.msk.ru
Дата:	16.08.18 14:56
Оценка:

	От:	vsb
	Дата:	16.08.18 15:06
	Оценка:	2 (1)

	От:	std.denis
	Дата:	16.08.18 16:48
	Оценка:	4 (1)

	От:	kov_serg
	Дата:	16.08.18 20:02
	Оценка:	6 (1)

От:	Basil2	https://starostin.msk.ru
Дата:	21.08.18 15:47
Оценка:

От:	Dair	https://dair.spb.ru
Дата:	03.09.18 17:44
Оценка:	2 (1)

От:	bnk	http://unmanagedvisio.com/
Дата:	03.09.18 17:56
Оценка:	4 (1)

От:	Евгений Музыченко	https://software.muzychenko.net/ru
Дата:	24.09.19 11:42
Оценка:	1 (1)

	От:	loginx
	Дата:	26.08.18 12:09
	Оценка:	+1

	От:	Ops
	Дата:	01.10.19 11:39
	Оценка:	+2