Pull to refresh
2
0
Евгений @anegin

Android dev

Send message

Не только 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 там избыточен

suspend fun <T> doRequest(
		...
): Either<String, T> = withContext(Dispatchers.IO) {
		// ...
    // Either.Left() or Either.Right()
}

К тому же 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 - в коде нет ничего, что требовало бы минимум эту версию

  • очень много мелких замечаний по коду и верстке, которые надоест тут описывать

Старпёр) Бюрократия не со стороны разработчика, а со стороны магазинов, независимо от типа приложения. Причем нередко "бюрократические затруднения" происходят в автоматическом режиме, когда приложение ревьювит бот. Каждая публикация в стор становится похожей на лотерею — приложение могут зареджектить за фичу, которая до этого пару лет спокойно присутствовала в приложении.

Information

Rating
Does not participate
Registered
Activity