Для разделения API в двух сборках смотреть на режим сборки - плохая идея. Debug/Release - это не просто флажки, а довольно сильно отличающиеся режимы сборки конечных артефактов. Поэтому правильнее публиковать артефакты собранные в Release режиме, а разделение делать, например, через очень классный плагин https://github.com/gmazzo/gradle-buildconfig-plugin, который и генерит тот самый BuildConfig только мультиплатформенно
Дико плюсую. Сейчас пишу это сообщение из Elementary 6.0 - все отлично работает (будем считать, что повезло).
Поддержка жестов на тачпаде, полно приложений на https://flathub.org/ , которые ставятся в один клик + эксклюзивы в собственном аппцентре, темная тема, панель уведомлений, центр управления онлайн аккаунтами - все очень хорошо.
Давно пользуюсь именно этим дистрибутивом и слежу за блогом ребят, они большие молодцы
печально, ведь если смотреть внимательно, то там говорится, что клавиатура ничем не отличается от любого другого системного UI, который отрисовывается поверх вашего приложения, а следовательно надо обрабатывать только инсеты.
Да и клавиатура — это растяжимое понятие, вместо клавиатуры можно нарисовать все что угодно, хоть галерею с картинками из гугла (собственно есть такой режим у многих коавиатур)
Для тех, кому любопытно, мы столкнулись с интересной проблемой инсетов в BottomSheetDialog, когда системные компоненты не позволяют обрабатывать инсеты самостоятельно. Если кратко, то приходится руками запрещать их обрабатывать через прямое обращение к системной верстке (или библиотечной), за подробностями приглашаю к просмотру наших внутренних митапов: https://t.me/rmr_spb/66
> Важно, что после того как ViewGroup перехватывает управление событиями у дочернего View, дочерние View никак не могут вернуть себе управление.
Это реальная проблема, из-за которой нельзя, после начала скролла во вьюпейджере, вернуть жест в приближенную фотку. Тут остаётся только писать свой вьюпейджер под эту задачу.
Полностью поддерживаю предыдущего оратора!
P.S.: для составления маршрутов и просмотра их в Maps.Me использую это: share.mapbbcode.org Не знаю, что за добрый человек это сделал, но очень помогает!
Да, но тут стоит учесть, что во многих приложениях используется Toolbar, а его высота берется системой из ?attr/actionBarSize, которая, в свою очередь, достается из системных параметров, зависящих от ориентации. Поэтому Toolbar в ландшафтной ориентации узкий.
Если сделать android:configChanges=«orientation|screenSize», то пересоздания не будет
Да, вы полностью правы. Что здесь удивительного, все где-то ошибаются :)
Тем не менее я не советую не учитывать пересоздание активити, так как кроме этих случаев, есть множество других, когда это потребуется. Поэтому лучше не надеяться на меньшее, а делать сразу правильно.
В редких случаях это действительно полезно, например, экран с вебвью или картой, так как они долго создаются и инициализируются.
Этот случай я описал подробно в последнем абзаце.
Зачем вам открывать сокет, если вы открыли просмотрщик из нотификации и хотите сразу выйти по кнопке назад?
Сделайте фрагмент-просмотрщик. В основном приложении открывайте его в активити где все остальные экраны.
А для запуска извне открывайте SpecialActivity, которое будет переиспользовать ваш фрагмент-просмотрщик для внешних вызовов.
Не понимаю, как при configChanges=«orientation» вы хотите не пересоздать Activity, а только повернуть верстку? Мы обязаны вызвать super метод, а он пересоздаст все.
Почему? Одной команды достаточно:
./gradlew --write-verification-metadata pgp,sha256
Для разделения API в двух сборках смотреть на режим сборки - плохая идея. Debug/Release - это не просто флажки, а довольно сильно отличающиеся режимы сборки конечных артефактов. Поэтому правильнее публиковать артефакты собранные в Release режиме, а разделение делать, например, через очень классный плагин https://github.com/gmazzo/gradle-buildconfig-plugin, который и генерит тот самый BuildConfig только мультиплатформенно
есть еще https://github.com/yshrsmz/BuildKonfig
ну и множество других готовых решений можно найти тут https://github.com/terrakok/kmm-awesome :)
Дико плюсую. Сейчас пишу это сообщение из Elementary 6.0 - все отлично работает (будем считать, что повезло).
Поддержка жестов на тачпаде, полно приложений на https://flathub.org/ , которые ставятся в один клик + эксклюзивы в собственном аппцентре, темная тема, панель уведомлений, центр управления онлайн аккаунтами - все очень хорошо.
Давно пользуюсь именно этим дистрибутивом и слежу за блогом ребят, они большие молодцы
печально, ведь если смотреть внимательно, то там говорится, что клавиатура ничем не отличается от любого другого системного UI, который отрисовывается поверх вашего приложения, а следовательно надо обрабатывать только инсеты.
Да и клавиатура — это растяжимое понятие, вместо клавиатуры можно нарисовать все что угодно, хоть галерею с картинками из гугла (собственно есть такой режим у многих коавиатур)
Для тех, кому любопытно, мы столкнулись с интересной проблемой инсетов в BottomSheetDialog, когда системные компоненты не позволяют обрабатывать инсеты самостоятельно. Если кратко, то приходится руками запрещать их обрабатывать через прямое обращение к системной верстке (или библиотечной), за подробностями приглашаю к просмотру наших внутренних митапов: https://t.me/rmr_spb/66
Статья хорошая, но главное не перегибать, иначе можно дети до того, что "я знаю, что ничего не знаю"
Конечно https://bitwarden.com/! Можно хостить на своем сервере. Открытые исходники.
Знакомый безопасник проверял, и сказал, что все ок.
А как же Moxy и стратегии?
Это не заставляет уходить с
простогополюбившегося подхода и не париться о диалогах :)PS: спасибо, хорошая статья!
Это реальная проблема, из-за которой нельзя, после начала скролла во вьюпейджере, вернуть жест в приближенную фотку. Тут остаётся только писать свой вьюпейджер под эту задачу.
Да. Есть все вышеперечисленное.
С версии 3.1.0 github.com/sockeqwe/AdapterDelegates/releases
Полностью поддерживаю предыдущего оратора!
P.S.: для составления маршрутов и просмотра их в Maps.Me использую это: share.mapbbcode.org Не знаю, что за добрый человек это сделал, но очень помогает!
Да, но тут стоит учесть, что во многих приложениях используется Toolbar, а его высота берется системой из ?attr/actionBarSize, которая, в свою очередь, достается из системных параметров, зависящих от ориентации. Поэтому Toolbar в ландшафтной ориентации узкий.
Если сделать android:configChanges=«orientation|screenSize», то пересоздания не будет
Так, а чем тогда вам android:screenOrientation="portrait" не подходит? Если верстка не меняется, то и поворачивать не надо
Да, вы полностью правы. Что здесь удивительного, все где-то ошибаются :)
Тем не менее я не советую не учитывать пересоздание активити, так как кроме этих случаев, есть множество других, когда это потребуется. Поэтому лучше не надеяться на меньшее, а делать сразу правильно.
В редких случаях это действительно полезно, например, экран с вебвью или картой, так как они долго создаются и инициализируются.
Дополнил статью.
Этот случай я описал подробно в последнем абзаце.
Зачем вам открывать сокет, если вы открыли просмотрщик из нотификации и хотите сразу выйти по кнопке назад?
Сделайте фрагмент-просмотрщик. В основном приложении открывайте его в активити где все остальные экраны.
А для запуска извне открывайте SpecialActivity, которое будет переиспользовать ваш фрагмент-просмотрщик для внешних вызовов.
Не понимаю, как при configChanges=«orientation» вы хотите не пересоздать Activity, а только повернуть верстку? Мы обязаны вызвать super метод, а он пересоздаст все.
внутри диалога есть возможность указать любую тему
retained фрагменты как работали, так и работают. мы их правда не используем, достаточно Toothpick с простым управлением DI-скоупами