TGTGInsightтелеграм анализLIVE / telegram public index
← Такты, стеки, два колеса

TGINSIGHT SIMILAR POSTS

Намери подобно съдържание

Изходен канал @clockstackwheels · Post #295 · 10.04

Сегодня бродили по Зоологическому музею, и я не переставал удивляться, сколько способов «придумала» природа для решения схожих задач. Ну, конечно, природа не наделена разумом, и эволюционный механизм ничего не изобретает в нашем понимании этого слова: просто какие-то варианты оказываются более приспособленными. У этого механизма бывают ошибки (погуглите «возвратный гортанный нерв»), и ещё нередко он «отказывается» от собственных же решений, начиная до неузнаваемости их преобразовывать: например, камбала выглядит так, будто она сделана на коленке из обычной рыбы, плавающей горизонтально, а у нарвала рог не симметричен относительно тела и является просто излишне разросшимся зубом. Тем не менее, механизм наследования, высокая мотивация (если не приспособишься, весь твой вид умрёт) и закон больших чисел обеспечивают очень хорошее разнообразие решений. Вот есть задача, например, «не быть съеденным». Можно быть быстрым и убегать от опасности (антилопы и косули), можно быть неприятным на вкус или запах (скунс, опоссум), можно быть незаметным (палочник, листовидка), а можно быть сильнее всех остальных, чтобы на тебя никто не мог напасть (различные хищники). Задача «добыть себе еды» тоже решается множеством способов: запасать; есть то, что не едят другие; есть то, что не могут достать другие и так далее. Я защищался по эволюционным алгоритмам в программировании, и они, честно говоря, работают так себе. Хуже, чем настоящая эволюция в природе. Во-первых, многообразия и времени не хватает. Но самое главное: мы им даём мало свободы, они недостаточно гибкие и ограничиваются слишком узким набором правил. Например, если у вас есть алгоритм для поиска оптимального маршрута поездки на работу, у него никогда не возникнет решения «предложить пользователю сменить работу, чтобы вообще не ездить никуда». Возможно, мы сможем эффективнее запускать такие алгоритмы, когда появятся онтологические базы данных, описывающие достаточно большую часть вселенной. Ещё очень интересно наблюдать эволюцию в технике. Решения, которые предлагают люди для той или иной задачи, тоже со временем приходят к какому-то своему оптимальному виду. Например, у автомобилей для драг-рейсинга огромные задние колёса и маленькие передние, почти рудиментарные. По множеству других признаков это всё-таки автомобиль: двигатель, колёса, место для человека, может ехать. Но отличия драг-рейсингового автомобиля от автомобиля, решающего другую задачу, как раз очень похожи на отличия разных представителей какого-то одного класса животных. Техника одного вида от разных производителей выглядит очень похоже, потому что эволюционно путём развития и улучшения приходит к какому-то оптимальному для своей задачи образу. А вам фото китоглавов. Форма клюва у них такая, что невозможно отделаться от мысли, будто бы они улыбаются. #life

Hashtags

Резултати

Намерени 3 подобни публикации

Търсене: #viewmodel

当前筛选 #viewmodel清除筛选
Android Broadcast

@android_broadcast · Post #9572 · 18.10.2025 г., 11:35

Вот реальная история, как знание механики работы ViewModel спасло мне вечер 👇 У меня приложение на Compose и Jetpack Navigation 3 (работает на основе состояния Back Stack). Экран «Навигатор файлов» открывает папки рекурсивно: по сути это тот же экран, но с другими данными. Все данные — из одной и той же ViewModel.❗️Баг: при переходе в папку навигация срабатывает, UI не меняется. Современные ИИ подсказали общие вещи, но не помогли — промты, видимо, подвели (тут мне ещё надо прокачать знания) 🙂 Вспомнил ключевой факт про архитектуру: 👉 Все ViewModel живут в ViewModelStore. 👉 В пределах одного ViewModelStoreOwner (Activity/Fragment/NavBackStackEntry) получение ViewModel по умолчанию идёт по типу. 👉 Если нужно несколько экземпляров одного типа на одном owner’е — используем key. Решение в одну строку — привязать ключ к ViewModel, связанный с текущей папкой: @Composable fun FileNavigator( folderId: Id, modifier: Modifier = Modifier, ) { // новый folderId → новый экземпляр ViewModel → новый UI-стейт val viewModel: FileNavigatorViewModel = viewModel( key = "files(rootId='$folderId')" ) // ... } Мини-чеклист, если ловите такой баг 👉 Один экран используется повторно с разными параметрами? → Нужен key. 👉 Меняется route, но owner тот же? → key обязателен. 👉 Используете Hilt/Koin? → У этих функций тоже есть параметр key (hiltViewModel(key=...), koinViewModel(key=...)). 👉 key должен детерминированно зависеть от входных данных (например, folderId). 👉 При навигации назад убедитесь, что ViewModel освобождается ожидаемо. Ещё нюанс - если у вас сложная иерархия графов, проверьте, к какому ViewModelStoreOwner вы реально привязаны. Рекомендую посмотреть мои видео по теме: 📹Разбор Jetpack Navigation 3 🪙Полный разбор Jetpack ViewModel в Android и Kotlin Multiplatform #android#compose#androidjetpack#viewmodel#архитектура

Android Broadcast

@android_broadcast · Post #8901 · 05.04.2025 г., 10:43

🤖Альтернативный способ обработке one-off событий из ViewModel (EN, 10м) В статье рассказывается в чем сложность с обработкой одноразовых событий, которые надо передать из ViewModel в UI. Автор рассматривает способ через callback интерфейс в конструкторе ViewModel @HiltViewModel class MyViewModel @Inject constructor( // inject the interface private val toastMessages: ToastMessages, ) : ViewModel() { fun doSomething() { viewModelScope.launch { try { // execute async operation here } catch (e: CustomException) { // initiate a one-off event toastMessages.showToast(e.localizedMessage) } } } } 🔗 Альтернативная ссылка на статью #android#viewmodel#dagger#hilt

Android Broadcast

@android_broadcast · Post #9683 · 20.11.2025 г., 14:59

🚀Lifecycle 2.10.0 вышел в стабильной версии! Google выпустила мажорное обновление библиотек Lifecycle. Этот релиз сфокусирован на улучшении интеграции с Compose. ⚙️rememberLifecycleOwner для Compose Новый композабл позволяет создавать изолированные LifecycleOwner внутри UI. Идеально для компонентов, которым нужно независимое управление состоянием — например, для HorizontalPager, где только активная страница должна быть в состоянии RESUMED. @Composable fun MyComposable() { val lifecycleOwner = rememberLifecycleOwner( maxLifecycle = Lifecycle.State.RESUMED, parentLifecycleOwner = LocalLifecycleOwner.current, ) CompositionLocalProvider( LocalLifecycleOwner provides lifecycleOwner ) { // Дочерние композаблы теперь имеют собственный жизненный цикл } } 🚀 Интеграция с Navigation 3 Новый артефакт lifecycle-viewmodel-navigation3 предоставляет готовый декоратор для автоматической привязки ViewModel к отдельным экранам в Navigation 3. NavDisplay( backStack = backStack, entryDecorators = listOf( rememberSaveableStateHolderNavEntryDecorator(), rememberViewModelStoreNavEntryDecorator(), // Добавляем эту строку ), entryProvider = entryProvider { /* ... */ } ) Удобства для разработчиков: 👉 Идиоматичный Kotlin API для создания кастомных CreationExtras CreationExtras { this[MY_CUSTOM_KEY] = "myValue" } 👉 Метод savedStateHandle.saved() теперь нативно поддерживает nullable типы 👉Конструкторы SavedStateHandle помечены как @VisibleForTesting ⚠️ Важное изменение Повышение minSdk с API 21 до API 23 — убедитесь, что ваше приложение соответствует новым требованиям. #Jetpack#Lifecycle#Compose#Navigation#ViewModel#Kotlin