К слову, на каждой конференции хипстерские дядьки со сцены

Водовозы в очередной раз льют в уши лохам гамно, вот это да. Пряи америку открыл.

Понимаю твою боль.

Ответа пока на твой вопрос нет. Та,гугловая библиотека, которая ещё в альфе, тоже не панацея по ходу..
До этого, всё тот же гугл сапортил и продолжает это делать небольшой проект с примерами хеловорда (TODO приложения): https://github.com/googlesamples/android-architecture
Глянь на досуге бранчи.

Прямо сейчас пытался вкурить свеженький курс на Линде по этой теме. Чувак вроде не ас, но уверенно рассказывает свой подход. Что-то в этом есть. Ссылка на курс (если чё - могу сбросить код примеров): https://www.lynda.com/Android-tutorials/Android-App-Development-Design-Patter...

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

PS: Вот ребята ещё показывали свой альтернативный подход к решению этой задачи на Котлине, присмотрись: https://youtu.be/M3fTMBfmBqU?t=25m26s
Код их примера: https://github.com/stepango/Archetype

Я думаю, нужно воскресить JavaME и вдохнуть в неё жизнь. Мощности мобильных процессоров и рамы это сделать позволяют. А грядущая модульная Java9 позволит отказаться от суффикса «ME».

А что если взять нормальную ИДЕ (visual studio) и нормальный Фреймворк (xamarin)? За пару лет - полёт нормальный.

На мой взгляд люди часто упарываются архитектурами вместо того, чтобы писать простой работающий код. Мобильные приложения в 99% случаев это очень маленькие проекты, в них обычно нет и 100 000 строк, а если и есть, то они обычно или равномерно размазаны между несвязанным функционалом, либо все сидят в какой-то чётко выделенной библиотеке, поэтому достаточно просто писать стандартный говнокод с какими-то минимальными стандартами (тестирование, выделение всякого сетевого и хранилищ в сервисы и тд). А если всё совсем плохо, может быть стоит переделать сам UI, может экран перегружен, всё взаимодействует друг с другом и тд.

Qt/QML

А на деле получается какой-то треш

Вся суть, каждый раз как смотришь на реализацию clean arch ужасаешься количество костылей и файлов на каждое действие

если хочешь нормальной архитектуры, смотри в сторону react native / flutter

Есть популярные Android-приложения на Qt/QML? (кроме 2GIS)

понятия не имею, я говорю с позиции разработчика, очень удобная технология.

Я конечно касаюсь Android только в Android NDK и практически не пишу на Java.

Однако я тем не менее считаю, что люди слишком много говорят и не пишут код. А когда дело доходит до написания кода, для одного метода, которого нет для старых API, они прикручивают жырный Android Support или ещё что-нибудь похуже. Я думаю, что всегда есть возможность оставаться в минимуме зависимостей(а по сути, только от android.jar ;)). И всегда есть возможность не накручивать минимальный API level и делать софт рабочим даже для Android 2.3.

Да, код сначала надо делать рабочим, а потом уже красивым.

удобная технология

40 MB APK с либами для ARMv6 и x86

Очень удобно, согласен. Всеми руками за!

апк для всех архитектур, это зло

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

апк для всех архитектур, это зло

Google так не считает. И поэтому у него до сих пор в его же Play Market нельзя залить разные APK для разных архитектур. И вообще они NDK совсем не уважают, даже нормальный компилятор Си и крестов оттуда выбросили, неосилили hardfp и тоже выбросили, на очереди выбрасывания и ndk-build.

Qt хотя бы работает над этой проблемой

Таки да. Вот недавно выкатили Qt Lite.

https://developer.android.com/google/play/publishing/multiple-apks.html
а это что?

А, я попутал. Там нельзя отдельно залить APK для разных ARM. Я хотел залить отдельный APK для девайсов с Tegra 2, где нет idiv. Оказалось, нельзя. :)

Я на мобиусе был и там, емнип, про это говорили. Не зашло. Очередной велосипед с костылями. Гугловские arch blue prints тоже смотрел и вообще не понял, почему они там при выборе пунктов в nav drawer'e запускают новое активити, а не меняют фрагмент с контентом.

С зависимостями согласен. Без support'a жить, конечно, совсем тяжело, но для большинства клиент-серверных приложений хватит своих фасадов для сети и БД.

Просто когда библиотека больше самого приложения, не проще из этой библиотеки(а они почти всегда опенсорц же) перетянуть один-два класса, если так влом писать?

а не меняют фрагмент с контентом.

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

NDK совсем не уважают

Так у них же теперь Go, Java, XML во все поля.

Короче, андроед превращается в унылое говно, как и всё созданое С++хейтерами. У нас жаба быстрее процессора считает, кококо. Рефлексия, все дела, завидуй, вата. При этом поворот экрана - это проблема.

Очень характерно для всех «убийц С++»: визгу много, шерсти мало. У них С++ глючит потому что проектировать ПО не желают в принципе. А гуйные приложения нельзя просто взять и накорябать на коленке. Надо именно что проектировать. А как, когда в башке это не реализовано? Хоть ты сто тыщ раз идиоматически паттерны примени.

библиотека шарится. если бы гуй андроида был на Qt, вес библиотеки бы был равен размеру её .bss+.data+.got

Зачем делать логику дата-соурсов в контроллерах, а асинхронные задачи в презентерах или вьюхах? Это уровень модели, которому надо быть глубоко запрятанным, и работать вне зависимости от поворотов экрана вообще.

Это касается любого UI и любого MV* вообще, это банальщина.

если бы гуй андроида был на Qt, вес библиотеки бы был равен размеру её .bss+.data+.got

Был проект который раньше назывался Qtopia:

https://www.google.com/search?q=qtopia&safe=off&source=lnms&tbm=isch

Теперь он на помойке истории и никому не пригодился.

библиотека шарится

В Java? Ничего подобного.

в С++ же.

если бы гуй андроида был на Qt

в жабе то понятно, что страдание заложено by design

Спасибо кэп.

то что он «на помойке» не означает, что он был плох.

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

у меня был телефон на баде и он блин просто работал. ты такаешь и он тут же реагирует. все вертится, крутится, работает короче. а сейчас у мну андроид, телефон говно конечно, ибо нормальный разбил а этот держит уже 100й удар. но все таки. 15 секунд из браузера в смс например. там же нет ничего-ни 3д-графона, и биткоины не считаются.

бада тоже тупила на смс когда их было много, но это очевидный глюк - надо было загрузить немного смс, а остальные докачивать. рукожопы-с.

а вот андроид тупит эпически и всегда! не только с смс, но вообще в принципе когда требуется оперативка. и слабым процом это не объяснимо - бада на таком же железе просто работала.

я даже догадываюсь как это происходит. в андроиде есть драйвер который ловит out of memory и стучит по процессам с просьбой освободить память. а в линуксе память выделяется оптимистично и out-of-memory возникает на ходу и часто. то есть выделив 10 мегабайт ты не триггернешь процессы в бэкграунде. но на каждые N килобайт (причем N~=32) ты будешь дергать gc.collect() во всех процессах. вот он и тупит как проклятый.

я даже догадываюсь как это происходит.

Зачем гадать, если можно взять и почитать?
И раз https://developer.android.com/topic/performance/memory-overview.html
И два https://developer.android.com/topic/performance/memory.html

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

http://elinux.org/Android_Kernel_Features

Клоун, ёпт

обиделся за ссылочки на оф документацию? Мамкин догадыватель ты наш.

ты их сам то читал, свои «ссылочки»?

Отдельно стоит упомянуть тот момент, что при повороте экрана в Android Activity пересоздается, и ваша недавно запущенная асинхронная задача уходит в ад...

Ээ а что мешает стоить архитектуру не вокруг view? Будет в фоне болтаться SomeDispatcher которому новосозданный View посылает сообщение «есь чо»? Ну и дальше получает все данные для отображения. Контроллер и модель идут как «модули» к этому диспетчеру

этот подход работает для десктопа но не для мобил, там зело упоротая модель, с одной стороны view - может быть убит извне по поводу и без, с другой унутри него statefull компоненты, архитектурно это говнище наподобие рендеров в swing (кто ковырялся тот поймет)

Почти все предложения по архитектуре более или менее следуют этим путём. Но ещё никто не предложил вменяемого подхода. Об этом и спрашивает ТС

перечитай ТСа, он пишет про банановый mvc и какието детские проблемы