• Комфортная работа с Android Studio
    0
    Спасибо большое. Думаю многим эти замеры пригодятся.
    По поводу мини на m1 — при том же энергопотреблении и тепловыделении на x86, наверно, ничего собрать не получится. Однако, если не учитывать этот параметр, правильно подобранная машина на NVME будет быстрее за те же деньги.
    Мини хорош для небольших и средних проектов. Единственный минус, который вижу — максимальный объем RAM в 16GB. Для крупных долгостроев этого уже будет мало.
  • Почему я не использую SharedViewModel для фрагментов?
    0
    Предпочитаю логику отделять от Android.
    В данном конкретном случае адаптер, скорее, часть механики View. А вот дочерние фрагменты уже подключены к логике. В этом кейсе как раз и выгодно использовать Shared ViewModel — родительский фрагмент ее порождает, дочерние (из ViewPager) подключаются. При этом ничто Вам не мешает в дочерних порождать собственные ViewModel для, например, поставки данных.
    Так или иначе, всю логику за пределы Android Вы не сможете вынести, как бы Вам не хотелось.
    Такие же проблемы могут быть и у Safty args
    Не могу представить себе такого кейса. Safe Args — просто обертка над аргументами. А один инстанс аргументов приходится на один инстанс фрагмента.
    то эту breadcrumb логику я бы тоже перенес в сервис
    Как говорится, «у любой задачи есть минимум 3 решения». Можно и по-Вашему, а можно взять готовое решение — Navigation Component + Safe Args, что обойдется дешевле во всех смыслах.
    что я пытаюсь максимально абстрагироваться от Android, делая акцент на логике. Это помогает в тестировании и переходу к новым инструментам.
    Ну вот для этого пакеты AndroidX поставляются с зависимостями для тестирования. Navigation Component не исключение.
  • Почему я не использую SharedViewModel для фрагментов?
    +1
    Согласен с тем, что Shared ViewModel — не идеальное решение. Всё взаимодействие на нем завязывать не стоит. Но оно вполне применимо, например, в каких-нибудь пошаговых визардах. Это скорее полезный инструмент для определенного круга ситуаций.

    Но и предложенный Вами сервис Shared ViewModel полностью не заменяет. Это уже отдаленно напоминает redux или mvi.
    Остальное тоже не идеально. Опишу подробнее:

    Мы строим ViewModel для конкретной View.
    Не обязательно. В идеале ViewModel не должна знать о View, которая ее использует. Так мы разделяем логику (ViewModel) и механику (View) работы презентационного слоя. Таким образом, можно переиспользовать ViewModel на нескольких экранах схожего назначения. Например, можно использовать один и тот же тип ViewModel как в мобильной версии, так и в версии для Android TV.

    Мы не можем просто взять такой фрагмент и добавить в ViewPager, например
    И не нужно. Этим и распределением параметров должен заниматься наследник FragmentStateAdapter (или FragmentStatePagerAdapter). В идеале, по мере пролистывания, фрагменты должны создаваться и уничтожаться чтобы не мусорить в памяти. Решение этого вопроса сложнее, чем «просто добавить», и аргументы вполне подходят как часть решения.

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

    ViewModel запрашивает параметры у сервиса по типу класса параметров.
    И это порождает проблемы с уникальностью. Если у Вас в стэке несколько экземпляров одного и того-же фрагмента или фрагментов, которые используют один и тот-же тип параметров — после восстановления стейта Вы можете получить стопку одинаковых экранов.
    Пример — экран профиля пользователя с параметром userId. Вы смотрите на профиль 3, в который попали из друзей профиля 2, в который попали так же из профиля 1. И в любой момент хотите вернуться к предыдущему. Да, в случае сервиса это решаемо, но в аргументах это всё уже решено.

    Если объем передаваемых данных свыше 500 кб., то приложение может аварийно завершиться
    Потому не стоит хранить в аргументах и saved state контент. Здесь надо хранить только параметры, и, в этом случае, лимит исчерпать довольно сложно.

    Простите за большое количество текста. В паре строк эти вещи не опишешь.
  • Rx головного мозга
    0
    Простите. Не уточнил. Имелось ввиду, что если с помощью FlowBindings реализовать подход пассивных view и им подобные. То есть сделать то же самое, что в примерах.
    С одной стороны удобно, view можно переиспользовать. С другой — презентер жестко связан с тем набором методов и контролов, которые декларирует view и к другой view с другой механикой его уже не подключишь.
    Как примеры жестких ситуаций — смена конфигурации или версия для AndroidTV. В обоих случаях может кардинально меняться не только интерфейс, но и механика работы. В идеале, об этих нюансах презентеру лучше не знать.
  • Rx головного мозга
    +1
    Есть вот такая реализация, но сырая.
    Но многим (включая меня) подобные подходы не нравятся по причине того, что частично или полностью переносят механику view на presenter\view model.
  • Rx головного мозга
    0
    Кажется, что они решают больше локальные чёткие задачи
    Не совсем. По факту та же реактивщина, просто из коробки меньше конструктов и операторов. Как заявлено на странице Flow, главные цели — проще дизайн, дружественность к прерываниям и структурному параллелизму.
    Да, есть конвертация в RxJava и обратно. Однако, на IO19 было объявлено, что для Jetpack первоочередной будет всё-таки поддержка корутин, а RxJava будет поддерживаться на уровне документации. Там же назвали корутины рекомендованным решением.
    То есть те расширения RxJava, которые из коробки есть для Room и других компонентов — не понятно, насколько долго они будут существовать.
  • Архитектура и дизайн Android приложения (мой опыт)
    0
    Имею много позитивного опыта по прикручиванию нового функционала на корутинах, архитектурных компонентах и так далее к легаси различной древности и размерности. Но да, это не всегда целесообразно.
    Но речь шла именно о новых проектах. Тут, скорее, либо инерция, либо попытка доказывать профессионализм на волне чьего-то успеха.
  • Архитектура и дизайн Android приложения (мой опыт)
    0
    Rx я думаю, тоже скоро начнут забывать…
    Если Вы о RxJava от ReactiveX, то не скоро. Я хоть и сам широко использую Flow и корутины, но вакансий, где требуют RxJava и ее сторонников на руководящих должностях еще много. Людям не просто отпускать привычное.
    Зачем этот промежуточный слой хранения?
    Потому, что нужно разделять бизнес-логику и презентационную логику. Состояние далеко не всегда хорошо хранить в репозитории из-за того, что большинство операций повторяемые. Иначе это мало будет отличаться от поделок на EventBus 5 летней давности.
    на мой взгляд не совсем верная формулировка
    Тут согласен. LiveData, скорее, работает с ЖЦ Observer. Обычно это View, однако та же Navigation Library предлагает интересные приемы с LiveData.
    Оценивайте тенденции)
    Да, есть такая тенденция. Но до ее реализации еще далеко. А до тех пор стабильнее LiveData для выше обозначенных задач нет ничего, и с ней в прод еще ходить как минимум год.
  • Архитектура и дизайн Android приложения (мой опыт)
    +1
    Не в любой, но есть. Однако, все эти реализации интегрируются с жизненным циклом гораздо хуже LiveData. По своему опыту могу сказать, что со сторонними реактивными реализациями пока слишком много проблем.
    Плюс ко всему, LiveData используется не только как прокладка между Rx и Flow.
    Например, как управляющая компонента. Или в составе той же paging library.
    ConflatedBroadcastChannel и скорый StateFlow
    В них еще не скоро будет интеграция с LifeCycleOwner и прочими вещами. Всё-таки Flow — часть Kotlin Coroutines, а не Android. А даже если появится, то будем использовать прокладку в виде еще одного Flow вместо LiveData так как хранить состояние в UseCase не всегда нужно и редко полезно.
    К тому же есть ViewModel
    Вы опять смешиваете инструменты)
    ViewModel сама по себе не решает задачу управления View в рамках жизненного цикла. Этим и занимается LiveData. На ViewModel же ложится задача переносить эти LiveData и содержать логику, которая управляет данными в LiveData.
  • Архитектура и дизайн Android приложения (мой опыт)
    0
    Он не решает задачи смены конфигурации и хранения состояния. В ветке выше описал подробнее.
  • Архитектура и дизайн Android приложения (мой опыт)
    +3
    Потому, что Вы забываете про смену конфигурации. Она произойдет, хотите Вы этого или нет. В этом случае активити или фрагмент (View) будут пересозданы. Задача ViewModel в этом случае — перенести данные и отдать последние известные состояния View.
    Здесь и видна разница между Flow и LiveData. Это разного порядка инструменты.
    Flow — просто реактивный поток, способ организации следующих друг за другом событий. Он ничего в себе не хранит и при следующей подписке, в общем случае, запустит заложенный в него код заново.
    LiveData — это mutable storage (цитата с IO19). Его задача — отдать последнее известное ему значение. В случае конвертации toLiveData() — последний отданный flow результат.
    Итого, предположим, у Вас сетевой запрос завернут в flow{}. Без конвертации в LiveData внутри ViewModel, этот запрос будет выполняться при каждом, например, повороте экрана. LiveData решает в том числе и эту проблему.
    а LiveData они задиприкейтят через какое-то время..
    Нет. На IO уже не один раз говорили, что это разного рода инструменты с разным назначением. Потому деприкейт если и будет, то очень не скоро.
  • Декларативное программирование клиент-серверных приложений на андроид
    +1
    По поводу RN полностью согласен. Потому и написал про технически несложную идею. Но, в случае DePro, всё так же может упереться в наличие подходящего компонента. В обоих случаях его разработать относительно не сложно, но проблема одного порядка — нехватка гибкости и вариативности. При том, что RN работает на 2х платформах.
  • Декларативное программирование клиент-серверных приложений на андроид
    0
    Вот как раз у бизнеса подобные решения не востребованы. Это не кардинально новая идея и ей не один год. Более того, существуют e-commerce платформы, которые нативные, гибкие и код практически писать не надо. Очередей за ними не видно.
    Одно дело упрощать разработку, другое- уменьшать гибкость, вариативность и ухудшать UX.
    Решение, конечно, само по себе интересное. Оно пойдет для того, чтобы пощупать рынок с технически несложной идеей. Только зачем, когда для этого есть Flutter и Reасt Native?
  • Декларативное программирование клиент-серверных приложений на андроид
    0
    Сколько этих приложений? Просто, чтобы работать с таким, заказчик либо должен быть совсем нетребовательным, либо Вам придется подгонять компоненты или саму DePro под него. С этой стороны 85-90% уже крайне преувеличенная цифра. Вы просто судите только по той массе проектов, что прошли через Вас.
    Если Ваш компонент покрывает группу View, то, если его механика хоть немного не совпадает с ТЗ — придется писать кастом. Примеров масса — списки с несколькими типами ячеек, пагинация через paging library, интерактивные списки (не только кнопочки), биллинг с библиотеками провайдеров. Список может быть большим, я только привел самое часто востребованное.
    Если предлагаете покрывать каждую View компонентом — то это ничем не лучше слегка продвинутой вариации Data Binding, а современная MVVM на AAC будет гораздо компактнее и гибче (если знать как писать).
  • Декларативное программирование клиент-серверных приложений на андроид
    0
    Решение безусловно интересное, но, увы, 85-90%, о которых Вы говорите, очень призрачны. Как и утверждение про «в 40-50 раз меньше кода». Это больше похоже на ошибку выжившего.
    Всё дело в мелочах — для разных сервисов и приложений нужен разный UX, который тоже надо построить и прорабатывать. Это относится как к бизнес-логике, так и к механике интерфейса даже на типовых решениях.
    Сведя всё к наборам поставляемых компонент теряется гибкость и вариативность. Для одних и тех же компонент механика может быть очень разной. Да, можно написать кастомные компоненты. А сколько их в итоге понадобится? Гибкости при этом не прибавится.
    Так же есть вопросы к качеству выходного приложения. Например, как здесь работать с сменой конфигурации и восстановлением состояния?
    Вы не первый, кто предлагает подобное и не только на Android. Такие решения так и не стали массово востребованными как раз по подобным причинам.
    «А что мы, программисты, будем делать?». Он увидел минус в том, что при переходе на работу с библиотекой его могут сократить.
    Если и сократят — значит он и раньше не был нужен. По-настоящему же стоит вопрос о востребованности DePro.
  • Summer MVP. Насколько гибок Kotlin?
    +1
    Спасибо! На самом деле примерно из-за подобных проблем с Moxy давно перешел на MVVM на компонентах. Но, конечно, о kmultiplatform тут говорить не приходится. И решений по выносу презентера на кроссплатформенную часть до этого момента не видел.
    Но сразу напрашиваются два вопроса:
    1. Как быть с сохранением состояния. Ну то есть, для примера, в компонентах для тяжелых случаев есть SavedStateHandle.
    2. Если презентер на стороне kmultiplatform, выходит нельзя воспользоваться, например, paging library и придется городить велосипеды для пагинации?

    P.S.
    Было время, когда я пробовал Google MVVM, но как-то слишком много кода получается для решения, казалось бы, простых задач
    На самом деле объемы кода те же, просто не все смотрят на практики.
  • 30+ лаконичных профессиональных рекомендаций для Android разработчика
    0
    Совет: вот отличная серия для того, чтобы узнать основы разработки RxJava для Android.
    Довольно странный совет с учетом того, что официально рекомендованным решением для построения асинхронности являются kotlin coroutines. А для поточной реактивщины там есть kotlin flow.

    В остальном согласен.
  • Разработчик оценил сложность современных браузеров
    +1
    Skype и VSCode — это веб-приложения
    Я бы не назвал их эталонами качества, хоть и пользуюсь последним довольно часто.

    Потому что веб лучше во всех отношениях
    React Native с вебом очень слабо связаны. В общем то это даже не веб-фреймворк, так как презентационная часть у него нативная. Он просто позволяет управлять нативными интерфейсами через js.

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

    Такая большая и богатая компания, а пишет своё мобильное приложение на веб-технологиях. Почему?
    Об истинных мотивах мы можем только гадать. Но многие богатые компании RN в итоге выкинули, что тоже показатель.

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

    Вот веб и есть самый привычный и распространённый интерфейс
    Почему же тогда у инстаграма основной интерфейс именно нативный, а веб сильно обрезан? Вы рассуждаете о теплом и мягком. Вэб у натива тоже много перетянул. В частности и Material Design, и hot reload (он появился на андроиде (и не только) в разных реализациях далеко до RN).

    веб всё равно развивается быстрее всех этих платформ, это он задаёт им тренды
    Очень спорно. Те же Google Pay и Apple Pay на вэбе стали доступны не сразу. Как и мультитач, работа с гео и прочее.
  • Разработчик оценил сложность современных браузеров
    +2
    Даже десктопные и мобильные приложения легче и эффективнее писать на всяких Иониках и Электронах, а не на WinAPI
    Не проще, а дешевле. При том скупой платит дважды так как выходное качество часто оставляет желать лучшего. Начиная от расхода памяти, заканчивая проблемами рендера.
    миллионы сайтов с навороченным дизайном, адаптивностью, реактивностью, анимациями и прочими ништяками, о которых другие платформы могут только мечтать
    Поверьте, популярные платформы в нативе позволяют гораздо больше если у Вас достаточно опыта. Только никому не нужны навороченные интерфейсы. Есть такие штуки, как гайдлайны и пользовательский опыт. И они говорят о том, что людям проще и эффективнее использовать уже привычные интерфейсы.
    благодаря этому он превратился в Самую Главную платформу
    Если бы это было возможно — это бы уже произошло. Самое близкое к тому, о чем Вы говорите — ChromeOS, популярность которой далека от высокой. А, по факту, бОльшая часть пользовательского трафика сейчас идет с мобильных устройств, где доминируют приложения а не сайты из браузера.

    В целом, может автор и не прав по поводу спецификации. Но то, что вэб переусложнен, неповоротлив и расходует неоправданно много ресурсов, сегодня замечают многие.
  • В большинстве случаев сериализация в Андроиде не нужна
    0
    Вы упускаете контекст. В приведенном Вами примере речь идет о взаимодействиях между процессами, что позволяет использовать Binder в качестве идентификатора или механизма авторизации. Это выгодно, когда оба процесса живы- запрашиваемый процесс отдал данные, а если надо- его разбудят еще раз. Правда, для подобного есть более правильный путь — Account Manager. Но это не меняет основной сути.

    А она заключается в том, что Binder и IBinder — части одного и того же RPC-механизма. А значит порождают строгую ссылочную зависимость.

    Не надо путать RPC с remote storage.
  • В большинстве случаев сериализация в Андроиде не нужна
    0
    Но я навскидку привёл реальную проблему, типичный юзкейс с навигацией opportunity, для которой хорошего решения не существует
    Показывать что-либо на старте экрана — нормальная практика. В том числе и другой экран через directions. Можно использовать одни и те же фрагменты в разных графах, что увеличивает систематизацию. Почему данные подходы Вам не нравятся — для меня загадка.

    Но количество дурацких решений в архитектуре Андроида по-прежнему велико.
    Любому решению есть причина. Например, многие ругают Android за пересоздание активити при повороте и прочих сменах конфигурации. В то же время это — хорошая возможность смены лейаута и его поведения для конкретных условий. Вспомните тот же master-detail.

    Моё мнение, что-то у них там в Андроидном подразделении Гугла фундаментально сломано.
    Я часто присутствовал на презентациях о Jetpack и других решениях. Так же, на них присутствовали iOS-разработчики с большим опытом. В последний год от них всё чаще слышу возгласы вроде «почему у нас так нельзя» или «почему у нас такого нет». На мой взгляд, это о многом говорит.

    Да, Android не идеален. Но не более, чем что-либо еще.

    В то же время Вы ругаете Android и его практики и предлагаете не целевое использование Binder — технически опасное решение, которое снижает качество приложения на выходе.

    Мне кажется, что проблема тут совсем не в Android…
  • В большинстве случаев сериализация в Андроиде не нужна
    0
    Как-то не конструктивно с Вашей стороны.

    Оно хорошее, но почему-то хромает
    Ну это, на мой взгляд, точно лучше хаоса в навигации.

    Спасибо вам большое за обсуждение!
    Имелось в виду, что я не хочу тратить время на просмотр исходников Ваших проектов. А вводных данных, что Вы описали, возможно, недостаточно для подбора наиболее подходящего решения.
  • В большинстве случаев сериализация в Андроиде не нужна
    0
    Это уже- вкусовщина. Вы не можете гарантировать, что в будущем к Account не добавятся дополнительные параметры. Так же, как и одинаковые наборы параметров для разных фрагментов. В этом случае обертка- более выгодное решение.
    В случае Safe Args наличие обертки за один аргумент- небольшая плата за расширяемость и вариативность. И с type safe там тоже всё в порядке. Даже поддержка Null Safety есть.
  • В большинстве случаев сериализация в Андроиде не нужна
    0
    Поймите правильно- здесь проблема не в наличии практик. Проблема в том, что Вы предлагаете использовать Binder для тех целей, для которых он не разрабатывался и не предназначен. Читайте про золотой молоток.
    При этом Вы лишаете пользователя довольно ценного функционала- восстановления состояния.
    Это механизм для удаленного вызова процедур, о чем написано в документации. Он не предназначен для хранения и передачи данных. Там же есть напоминание о смерти процесса.
  • В большинстве случаев сериализация в Андроиде не нужна
    0
    OpportunitiesFragment не должен быть в стеке, при нажатии на Back должны возвращаться обратно на главный экран
    Тогда сделайте главный экран частью графа и переходите оттуда- для Вас есть Nested navigation graphs.

    OpportunitiesFragment не должен заниматься маршрутизацией, это вообще задача не View, а ViewModel
    Я это и мел в виду- решение о переходе принимает ViewModel, но саму команду отдает View-слой. Navigation component предполагает использование view-driven архитектуры. Собственно, как и большинство рекомендуемых реализаций.

    Как видите, решения есть. Я не вижу исходников Вашего проекта (да и не хочу тратить на это время), чтобы порекомендовать наиболее подходящее. Нужно уметь находить и правильно применять решения, а не сводить к несвязанному хаосу.
  • В большинстве случаев сериализация в Андроиде не нужна
    0
    о возможностях, открывающихся, если отказываемся от восстановления состояния после рестарта процесса
    UX важнее проблем разработки. За некоторыми исключениями. Нужно решать проблемы пользователей, а не собственные.

    вроде бы ничего не утекает
    Вы так можете случайно передать в долгоживущую часть приложения (или даже часть системы) сильную ссылку на объект с коротким жизненным циклом. Может даже и не один и не маленький в плане потребления памяти. Вот Вам и утечка.
  • В большинстве случаев сериализация в Андроиде не нужна
    0
    С точки зрения описания в языке- разницы нет.
    С точки зрения проектирования- сгенерированный args-класс инкапсулирует в себе набор параметров различных типов. Если (а точнее- когда) этот набор будет меняться со временем- содержать его внутри одного класса-обертки будет выгоднее.
  • В большинстве случаев сериализация в Андроиде не нужна
    0
    Если Вам нужно, чтобы opportunities_fragment остался в стэке и пользователь мог на него вернуться- что мешает сразу в нем вызвать переход по нужному Вам destination? Например, в onActivityCreated() (предварительно обезопасив себя от повторения).
    В остальном Вам сюда или сюда.
  • В большинстве случаев сериализация в Андроиде не нужна
    0
    По поводу потенциала ) Обнаружил в закромах интерфейс, который делает любой класс Parcelable-ом.
    Вы же понимаете, что такая реализация не переживет перезапуск?.. А, при неумелом использовании, еще и спровоцирует утечки.
  • В большинстве случаев сериализация в Андроиде не нужна
    0
    Так же открывается история. На устройстве Android One версии 10. У Вас может быть либо другая версия приложения, либо баг прошивки вендора Вашего устройства.
  • В большинстве случаев сериализация в Андроиде не нужна
    0
    Если гуглокодеры предлагают инструмент для решения некой задачи, то это не значит, что необходимо использовать именно этот инструмент. Особенно учитывая низкое качество создаваемых инструментов и вообще принимаемых решений (что касается Андроида).
    Верно, не обязательно. Но есть рекомендуемые подходы. Это означает, что предлагаемый инструмент прошел UX-тестирование и имеет высокую степень совместимости с самим Android framework и сопутствующими инструментами.
    Пример- Coroutines.

    По поводу качества не согласен. Ранее была такая проблема, но новые инструменты радуют (если, конечно, Вы ознакомились с практиками их использования). Да, баги есть. Но их в среднем не больше, чем у других известных инструментов. Просто внимания больше, от того находят быстрее.

    В итоге всё приходит к несвязанным fragment
    Это говорит о непродуманности UX Вашего приложения. И об отношении к пользователям…
    По опыту скажу, что при рефакторинге даже весьма хаотичных b2b-проектов, они, по итогу, прекрасно укладывались в навигационную диаграмму.

    В Safe Args смысла не вижу
    А он есть. Вы показали сторону вызова, а посмотрите на принимающую сторону:
    class AaaFragment : Fragment() {
        private val args: AaaFragmentArgs by navArgs()
    }
    AaaFragmentArgs- это сгенерированный класс. В нем свойства, которые Вы укажете в navigation.xml (или в граф.редакторе). Не надо возиться с ключами и есть гарантия того, что Вы передадите в фрагмент то, что он ожидает. AaaFragmentArgs будет восстанавливаться при смене конфигурации и перезапуске. Минимальный набор для восстановления экрана с вводными.
    В отдельных случаях Вам даже экшены использовать не обязательно.

    как часто бывает в Андроиде, недоделанности и недопродуманности
    Предполагаю, что Вы просто мало работали с другими ОС и фреймворками. Там разных недопониманий тоже хватает. Но, что в Android, что в других ОС, такие проблемы чаще возникают от незнания good practices.
  • В большинстве случаев сериализация в Андроиде не нужна
    0
    Даже если так- хранить состояние в статике- плохая практика. Если не учитывать рестарт, то это будет работать так, как Вы ожидаете, только до тех пор, пока у Вас на одного наследника активити\фрагмента приходится один инстанс в стэке. Если инстансов несколько- начинаются проблемы. Например, когда пользователь из одного профиля соцсети через список друзей попадает в другой профиль.
    ViewModel или аргументы\SavedInstanceState эти проблемы решают.
  • В большинстве случаев сериализация в Андроиде не нужна
    +1
    но в большинстве приложений это нецелесообразно
    Это всегда и везде целесообразно. Если, конечно, Ваше приложение не состоит из одного экрана или вообще не имеет основного UI. Ну или если есть жесткие требования к безопасности.
    Тот же навигатор- будет неприятно если ОС, по каким-либо веским причинам, решит выкинуть его из памяти. Например, во время достаточно долгого разговора.
    YouTube проверил- перезапускает с сохранением, показал то же видео. Возможно, есть разница в версии ОС и приложений.
    На моем наборе приложений те, что перезапускаются- в меньшинстве. И это всегда неприятно- на превью мультитаска видишь один контент, а после выбора- всё сначала.
    Да, таких приложений просто много. Но это точно не норма и практиковать такой подход без веских причин не стоит.
  • В большинстве случаев сериализация в Андроиде не нужна
    +6
    Печально такое читать в 2020 году. При всём уважении, есть несколько замечаний
    В большинстве приложений имеет смысл принять явное осознанное архитектурное решение, что в случае смерти процесса приложение просто перезапускается с нуля, не пытаясь восстанавливать состояние
    Есть причины отказа от сохранения состояния, которые не зависят от самого разработчика. Они могут быть разными- использование сторонних кроссплатформенных движков, криво выстроенная логика сервиса\бэкенда\авторизации, прямое указание начальства\заказчика, куча легаси и прочее. Таких приложений совсем не большинство.

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

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

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

    Раньше можно было в любом месте воткнуть статическое поле и хранить в нём состояние
    Это когда? Признаюсь честно- я мало писал под версии старше 2. Но уже 2.1 выкидывал процессы из памяти по причине нехватки, что, в последствии, приводило к перезапуску с, возможно, не пустым SavedInstanceState.

    Такой подход имеет большой потенциал. Можно красиво обернуть и использовать во многих местах. Например, для передачи произвольных аргументов во фрагменты.
    Простите, нет. Раз Вы в примерах используете Navigation component (или что-то очень на него похожее)- специально для этого придумали Safe Args. Это дополнение генерирует классы для аргументов фрагмента, которые, в свою очередь, сохраняются при смене конфигурации и перезапуске. Не факт, что Вам придется делать для этого много кастомных Parcelable\Serializable (в этом, кстати, тоже нет проблемы- студия для большинства типов генерирует реализацию Parcelable нажатием одной кнопки).

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

    Если Вам нужно сохранять более подробное состояние и Вы эти данные обрабатываете во ViewModel- для Вас есть SavedStateHandle и AbstractSavedStateViewModelFactory.
  • Переупаковка пакетов в Gradle
    +1
    Сложно сказать. Надо сравнивать конфигурации Ваших проектов и что в них происходит. Если даже дело не в самом Gradle- могу предположить, что какой-то плагин, который уже содержит asm, подключается раньше Вашего.

    Быстрый гуглеж подсказывает, что это весьма вероятно. Например, вот так подключается asm в kotlin-android-extensions. И, судя по всему, по этой зависимости подключается версия asm с патчами для IntelliJ.

    Я не уверен, но, возможно, это может стать решением и для Вас
  • Переупаковка пакетов в Gradle
    +1
    Спасибо за статью. Тоже решал данную проблему лет 5 назад, но в рамках android и пользовался jarjar вручную. Сегодня, конечно, сама проблема уже не актуальна если говорить о android.
    В Вашем случае другая ситуация, но по той же причине.
    Я так и не смог выяснить точную причину, почему не получается зафорсить версию asm-а, хотя команда ./gradlew app:dependencies показывает, что версия заменилась на 7.2
    То, с чем Вы столкнулись- перегрузка классов. Если Ваше приложение\плагин имеет классы, которые по именам и пакетам совпадают с теми, которые уже содержит рантайм (в Вашем случае- Gradle)- они не будут грузиться в память так как они там уже есть. Иными словами- конфликты классов решаются в сторону рантайма и, как итог, Ваш плагин обращается к классам Gradle, а не к классам Вашей библиотеки.

    Зафорсить не получится потому, что байткод Gradle уже собран с зависимостью от asm 6 (по ссылке уже 7.1). Тут либо самому собирать Gradle из исходников c нужной зависимостью в надежде ничего не сломать, либо искать версию Gradle с asm 7.2 из коробки (если такая есть), либо пользоваться той версией asm, что поставляется с Gradle.

    Ну или можно поступить так, как Вы- перепаковать либу или подвергнуть ее обфускации
  • GridmiAPI — простая и гибкая библиотека Android для работы с REST&RPC
    0
    Альтернативы- это всегда хорошо. А есть ли у этой библиотеки преимущества в сравнении с OkHttp? Он стал сейчас практически стандартом в разработке под Android. Например, если смотреть на создание запросов- я большой разницы не вижу
  • Сборка Android-приложения. Задачка со звёздочкой
    0
    Это критично для любой системы сборки. Ведь весь процесс сборки упирается в произвольное чтение\запись, ресурсы CPU и насколько составляющие системы доработаны и оптимизированы
  • Google закручивает гайки
    +1
    Заказчик несет риски на любом аккаунте. Только рисков больше он несет при публикации на аккаунте разработчика. Ведь если аккаунт разработчика забанят из-за приложения заказчика- виноват заказчик, так как всё делалось исключительно по его ТЗ и указаниям. Потому да, на такой случай надо сразу оговаривать неустойку в пользу разработчика
  • Google закручивает гайки
    +8
    приложения, выполненные на заказ (бесплатные для пользователей) теперь неразумно разработчику (владельцу аккаунта Play Store) публиковать в своем аккаунте, предоставляя услугу (бесплатно, или за дополнительные деньги)
    Вообще то так было всегда. Причем касательно любого маркета. И это нормально. Разработчик только реализует проект по ТЗ, дальнейшее его волновать не должно. Если заказчик хочет публиковаться в аккаунте разработчика- по этому поводу заключается дополнительное соглашение с условиями, которые устраивают обе стороны. Ведь, публикуя на своем аккаунте приложение заказчика, разработчик несет дополнительные риски.

    А если Вы пишете свой проект- то Вы сам себе заказчик, а значит, несете риски обеих сторон.
    выполнение требований Google теперь все больше зависит от заказчика приложения, от контента приложения, а не от разработчика
    И так тоже было всегда. И это тоже правильно. Более того, если разработчик видит проблему с выполнением требований маркета- он должен поставить в известность заказчика, чтобы тот принял решения по устранению проблемы. В идеале на этапе рассмотрения ТЗ перед принятием в работу. Ведь хотелки заказчика, а не разработчика.
    И получается, что теперь любой заказчик приложения, если думать головой заранее – обязан заводить себе аккаунт сам, заниматься его поддержкой, обновлением описаний приложений, скриншотов…
    Конечно, ведь это не задачи разработки. Это задачи маркетинга, дизайна, копирайта, CEO и прочих смежных сфер. Если заказчик не в состоянии нанимать одного или нескольких людей с нужными навыками- значит он берет на себя риски, связанные с публикацией, и ему необходимо самому постигать навыки вышеперечисленных сфер.

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

    С Вашей точки зрения разработчик и реализует, и следит за копирайтом, и продвигает приложение. А заказчик- абстрактное лицо, которое излагает идею, заплатит денег, снимает сливки с продукта и при этом не берет на себя никаких рисков. Тогда зачем в этой схеме заказчик? Ведь все риски несет разработчик.