Изначально Dagger — это DI фреймворк для Java. В андроид он заходит с кучей бойлерплейта.
Hilt сделал Dagger дружественнее в плане инжекта зависимостей в андроид-компоненты. Теперь достаточно одной таблэтки аннотации. Раньше это выглядело как куча модулей и фабрик.
Koin — это только про котлин, он чуть менее функционален, и больше смахивает на Service Locator, чем на DI. Но для небольших проектов заходит отлично.
Есть какие пруфы, анализ алгоритмов для того, чтобы утверждать, что это «недокриптомессенджер»? В указанной статье просто сопли размазываются о том, каким образом распространяется приложение.
Не разрешают форкам подключаться к своим серверам? Так что это за полумеры — форкнуть сигнал и собрать себе билд (видимо для того, чтобы убедиться, что нет закладок), но при этом подключаться к серверам сигнала? Подними свой сервер и подключайся к нему.
Вместо github.run_number можно использовать кол-во коммитов в текущей ветке.
Плюсы — это значение не зависит от используемой CI, и с любого коммита всегда собирается билд со строго фиксированным номером.
Можно воспользоваться, например, gradle-плагином grgit, чтобы во время сборки брать инфу о коммитах и заменять versionCode приложения.
С этим же плагином мы у себя на проекте еще и простенькие release-notes для тестировщиков генерим на основе имен коммитов.
Кажется стоит добавить кэширование gradle-зависимостей, иначе они скачиваются заново при каждом билде.
Проблема с необходимостью скачивать NDK, даже если она не используется, появилась с Gradle Android Plugin 3.6.
В build.gradle нужно явно указать версию NDK, например
defaultConfig {
ndkVersion '21.2.6472646'
}
Если ее не указывать, то будет использоваться версия по-умолчанию (20.0.5594570).
В образе ubuntu-latest на данный момент предустановлена версия NDK 21.2.6472646
Если не лень, то можно собрать и использовать свой docker-image с нужной версией NDK.
Приходит менеджер и говорит — разработчик, сделай нам функциональность… Разработчик заводит новую ветку… декомпозирует на более мелкие задачи, которые заводит в трекере.
Т.е. задачи (хотелки, юзер-стори) ставятся устно? Требования, UI/UX и т.п. нигде не документируются и разработчик ищет их сам, чтобы потом декомпозировать и самому себе написать задач в тасктрекере?
Возврат результата из фрагмента часто используется, например, в DialogFragment'ах. Они могут быть вызваны из разных экранов и поэтому не могут быть привязаны к какой-то одной shared ViewModel'и. Приходилось изворачиваться с getActivity/getParentFragment + кастинг к интерфейсу. А с Navigation Component и это не прокатывает, приходилось использовать костыли с nav back stack.
Ну как бы взаимодействие между фрагментами — это не только отправка аргументов и получение результата. Часто нужно и во время работы фрагмента что-то дергать или получать в других фрагментах.
Не только стартанет. С whenStarted корутина переходит в suspended-состояние, когда lifecycle уходит в onStop, и (State)Flow.collect() перестает получать изменения. Т.е. получаем поведение аналогичное LiveData
Так LiveData сам по себе тоже ничего не знает о сменах состояния lifecycle, пока ему явно не передашь LifecycleOwner, подписавшись на него вызовом метода observe().
Похожая (но немного перевернутая) ситуация и со StateFlow — сам StateFlow ничего не знает о lifecycle, но подписавшись на него вызовом collect() в рамках «нужного» coroutine-контекста мы обеспечим его правильную работу с lifecycle
Андроид проектировался таким с расчетом на девайсы с ограниченными количеством оперативки и вычислительных ресурсов. Тогда еще не было смартов с несколькими гигами оперативки и многоядерными процессорами.
Билд происходит на чистом образе Ubuntu? Gradle, Android SDK и все зависимости будут скачиваться заново при каждом билде или можно настроить кэширование?
Бинарники движка могут компилиться из исходников при сборке приложения, и в процессе модифицироваться так, чтобы работать только с этим приложением.
А еще само приложение может содержать свой c/c++ код. В этом случае негде будет взять нужные *.so, кроме как просить разработчиков приложения.
Например, прослушивание файла будет выглядеть примерно так:
button.setOnClickListener
что?
почему фильтрация отдельным пунктом, почему не любая другая extenstion-функция для коллекций из десятков имеющихся?
геттеры/сеттеры, дата классы, делегаты — это же просто базовый синтаксис котлина, а не какие-то пасхалки, скрытые в недрах
Изначально Dagger — это DI фреймворк для Java. В андроид он заходит с кучей бойлерплейта.
Hilt сделал Dagger дружественнее в плане инжекта зависимостей в андроид-компоненты. Теперь достаточно одной
таблэткианнотации. Раньше это выглядело как куча модулей и фабрик.Koin — это только про котлин, он чуть менее функционален, и больше смахивает на Service Locator, чем на DI. Но для небольших проектов заходит отлично.
Не разрешают форкам подключаться к своим серверам? Так что это за полумеры — форкнуть сигнал и собрать себе билд (видимо для того, чтобы убедиться, что нет закладок), но при этом подключаться к серверам сигнала? Подними свой сервер и подключайся к нему.
Плюсы — это значение не зависит от используемой CI, и с любого коммита всегда собирается билд со строго фиксированным номером.
Можно воспользоваться, например, gradle-плагином grgit, чтобы во время сборки брать инфу о коммитах и заменять versionCode приложения.
С этим же плагином мы у себя на проекте еще и простенькие release-notes для тестировщиков генерим на основе имен коммитов.
Проблема с необходимостью скачивать NDK, даже если она не используется, появилась с Gradle Android Plugin 3.6.
В build.gradle нужно явно указать версию NDK, например
Если ее не указывать, то будет использоваться версия по-умолчанию (20.0.5594570).
В образе ubuntu-latest на данный момент предустановлена версия NDK 21.2.6472646
Если не лень, то можно собрать и использовать свой docker-image с нужной версией NDK.
Т.е. задачи (хотелки, юзер-стори) ставятся устно? Требования, UI/UX и т.п. нигде не документируются и разработчик ищет их сам, чтобы потом декомпозировать и самому себе написать задач в тасктрекере?
И да, StateFlow без coroutine-контекста не знает об изменениях состояния, так же как и LiveData без LifecycleOwner
Похожая (но немного перевернутая) ситуация и со StateFlow — сам StateFlow ничего не знает о lifecycle, но подписавшись на него вызовом collect() в рамках «нужного» coroutine-контекста мы обеспечим его правильную работу с lifecycle
А еще само приложение может содержать свой c/c++ код. В этом случае негде будет взять нужные *.so, кроме как просить разработчиков приложения.
Пожалуйста, не продолжайте больше.
"Слухач кликов" — это вообще шедевр.
что?
почему фильтрация отдельным пунктом, почему не любая другая extenstion-функция для коллекций из десятков имеющихся?
геттеры/сеттеры, дата классы, делегаты — это же просто базовый синтаксис котлина, а не какие-то пасхалки, скрытые в недрах