Кажется Google Oauth авторизация в WebView скоро перестанет работать. По крайней мере такое уведомление пришло от Google большинству андроид разработчиков
"не нагружать верстку" - это только про читаемость верстки. быстрее оно работать не станет. это скорее не Custom View, а Custom ViewGroup или Compound Layout
выложенная xml-верстка не соответствует тому как она используется в CustomView.kt. больше похоже на activity_main.xml. и по ней тоже есть нюансы - зачем внутри LinearLayout внутри ConstraintLayout, зачем у LinearLayout стоит width=match_parent.
подозреваю, что верстка для CustomView содержит внутри какой-то свой ViewGroup, и это все оборачивается в LinearLayout (CustomView), а оптимальнее будет делать через <merge>
насколько понимаю, тут app тоже нуждается в фиче-2, просто об этом не написано. а делать фичу-2 транзитивной зависимостью через фичу-1 будет плохо, т.к. фича-2 станет недоступна в случае отключения фичи-1 от app.
В официальной русскоязычной документации Kotlin употребляется именно слово "корутины". Слово "сопрограммы" в документации используется только для описания концепции. https://kotlinlang.ru/docs/coroutines-guide.html
Поздравляю, вы почти изобрели CollapsingToolbarLayout, который делает то же самое и даже лучше, но без единой строчки кода, только в xml. Даже с MotionLayout можно сделать такое же поведение с минимумом кода. По всей статье прослеживается очень много "плохих практик":
даже если делать такое поведение самостоятельно, то в данном случае лучше анимировать translationY контента, а не его topMargin, т.к. это приводит к re-layout/re-measure
запуск неконтролируемого потока для анимации при каждом touch up, хотя есть куча нативных инструментов для анимации
использование LinearLayout (вместо RecyclerView) для списка из элементов
необоснованный выбор min sdk аж 26 - в коде нет ничего, что требовало бы минимум эту версию
очень много мелких замечаний по коду и верстке, которые надоест тут описывать
Старпёр) Бюрократия не со стороны разработчика, а со стороны магазинов, независимо от типа приложения. Причем нередко "бюрократические затруднения" происходят в автоматическом режиме, когда приложение ревьювит бот. Каждая публикация в стор становится похожей на лотерею — приложение могут зареджектить за фичу, которая до этого пару лет спокойно присутствовала в приложении.
Не только Pixel и Fold. Споймал уменьшенную клавиатуру пару дней назад на S23 Ultra. "Вылечил" очисткой данных Gboard.
Хаб "Разработка под Android" - тут лишний
Кажется Google Oauth авторизация в WebView скоро перестанет работать. По крайней мере такое уведомление пришло от Google большинству андроид разработчиков
более того paint: Paint перезаписывается в init блоке. его вообще нужно вынести из конструктора
system раздел в read-only, ему ничего не будет. а вот userdata и cache могут не долго прожить
Видимо потому что установка в приложении локализации отличной от системной - это костыль, и не по гайдам android, по крайней мере до android 14.
"не нагружать верстку" - это только про читаемость верстки. быстрее оно работать не станет. это скорее не Custom View, а Custom ViewGroup или Compound Layout
выложенная xml-верстка не соответствует тому как она используется в CustomView.kt. больше похоже на activity_main.xml. и по ней тоже есть нюансы - зачем внутри LinearLayout внутри ConstraintLayout, зачем у LinearLayout стоит width=match_parent.
подозреваю, что верстка для CustomView содержит внутри какой-то свой ViewGroup, и это все оборачивается в LinearLayout (CustomView), а оптимальнее будет делать через <merge>
Потому что дизайнерам лень вникать в суть дизайн-систем платформ, для которых они рисуют, поэтому делают кто на что горазд.
"Выпустили" в новостях еще в начале сентября, но ее до сих пор нет в продаже
вероятно тут имелось ввиду "приложение..., которое использует Google-сервисы", а не "устройство"
насколько понимаю, тут app тоже нуждается в фиче-2, просто об этом не написано. а делать фичу-2 транзитивной зависимостью через фичу-1 будет плохо, т.к. фича-2 станет недоступна в случае отключения фичи-1 от app.
Если запрос предполагает один ответ, то flow там избыточен
К тому же doSomethingInSuccess - это лишний side effect. Зачем возвращать результат (который игнорится) отдельно через функцию и через колбэк
Зачем для разового запроса в doRequest возвращается flow (с единственным emit-ом)? почему бы не сделать просто suspend-функцию
В официальной русскоязычной документации Kotlin употребляется именно слово "корутины". Слово "сопрограммы" в документации используется только для описания концепции. https://kotlinlang.ru/docs/coroutines-guide.html
В этом плане ничего не меняется - R классы содержат всё те же final int константы и генерятся как и раньше, просто отдельно для каждого package.
А вы где-то напрямую используете "номера" (числа) ресурсов? или все же используете сгенеренные константы из класса R?
Очевидно же, что Java и Kotlin
Поздравляю, вы почти изобрели CollapsingToolbarLayout, который делает то же самое и даже лучше, но без единой строчки кода, только в xml. Даже с MotionLayout можно сделать такое же поведение с минимумом кода. По всей статье прослеживается очень много "плохих практик":
даже если делать такое поведение самостоятельно, то в данном случае лучше анимировать translationY контента, а не его topMargin, т.к. это приводит к re-layout/re-measure
запуск неконтролируемого потока для анимации при каждом touch up, хотя есть куча нативных инструментов для анимации
использование LinearLayout (вместо RecyclerView) для списка из элементов
необоснованный выбор min sdk аж 26 - в коде нет ничего, что требовало бы минимум эту версию
очень много мелких замечаний по коду и верстке, которые надоест тут описывать
Старпёр) Бюрократия не со стороны разработчика, а со стороны магазинов, независимо от типа приложения. Причем нередко "бюрократические затруднения" происходят в автоматическом режиме, когда приложение ревьювит бот. Каждая публикация в стор становится похожей на лотерею — приложение могут зареджектить за фичу, которая до этого пару лет спокойно присутствовала в приложении.
В каком месте гугл это требует?