Android разработчик
Передача данных между фрагментом и BottomSheetDialogFragment может быть эффективно организована с использованием Dagger и Navigation Component, избегая использования передачи данных чрез конструктор или интерфейс, а также SharedViewModel и Hilt. Данный подход позволяет сосредоточиться на интеграции зависимостей и управлении состоянием через стандартные инструменты.
DI фреймворки бывают двух видов: те, что строят свой граф зависимостей во время компиляции (compile time фреймворки), и те, которые делают это уже при выполнении кода (runtime фреймворки).
Kodein — типичный представитель runtime фреймворков. Это значит, что о пропущенной зависимости вы узнаете непосредственно в процессе работы приложения, что может стать неприятным сюрпризом. Только представьте себе: вы пропустили на регрессе какой-то кейс, и у вас краш в продакшене из-за DI! Это же настоящий кошмар!
Однако отказываться от Kodein ID и других runtime фреймворков не стоит. О том, почему мы продолжаем ими пользоваться, и как их сделать более надёжными, я расскажу в третьей статье из цикла материалов про Kodein DI для Android.
Погнали.
Android-разработчиков часто спрашивают на технических собеседованиях, как запускать фрагменты, как передавать туда данные, почему нельзя класть много в аргументы, а много — это сколько, а что может пойти не так и т.д. Мы в Dodo тоже иногда такие вопросы задаём. Я думал, что понимал всё это, но оказалось, что довольно поверхностно. Всё изменилось, когда я столкнулся с частыми крашами TransactionTooLargeException в приложении Дринкит.
TransactionTooLargeException — это исключение из области IPC-вызовов (interprocess communication) и Android Binder. Но его можно получить в безобидной ситуации, когда, казалось бы, мы ничего такого не делали, и не пользовались IPC.
В этой статье предлагаю разобраться с этим крашем и поговорить про IPC-вызовы и Binder.
Привет, Хабр! Я, Алексей, ведущий разработчик в платформенной команде Альфа-Бизнес Мобайл. В этой статье речь пойдет про приложение Альфа-Бизнес и об одной из архитектурных проблем, с которой сталкиваются на любом среднем/крупном проекте, рассмотрим несколько способов, которыми можно такие проблемы решать, и расскажу почему мы выбрали именно шарить презентационный слой.
Всем привет! Я Тимур, лид одной из android-команд. Больше трех лет работаю в Тинькофф, все это время был в привлечении и занимался флоу получения разных банковских продуктов.
Расскажу, как мы сделали свой DSL для того, чтобы строить логику навигации в наших флоу.
Всем привет! Меня зовут Владислав Шиханов, я ведущий программист в CDEK. В нашей компании работает 500+ IT-специалистов, именно мы создаём продукты и сервисы, из которых и состоит СДЭК. Моя команда разрабатывает сервисы для автоматизации процессов продаж и запуска новых продуктов.
Однажды мы столкнулись с тем, что процесс проверки кода начал задерживать выполнение задач и требовал слишком много усилий от участников. На ретро мы договорились повысить приоритет этого процесса и сделать доклад с best practices. В этой статье я решил поделиться главными выводами и лучшими практиками, которые помогли нам существенно упростить проверку кода.
Работа с утечками памяти
Не так давно, в процессе разработки приложения, я столкнулся с ситуацией: на первый взгляд код был хорошо написан, однако, на этапе тестирования стали заметны зависания. Во время использования приложения и многочисленных переходов по разным экранам, производительность заметно ухудшалась с каждым разом. При анализе ситуации стало очевидно, что есть проблемы с оптимизацией. В данной статье я расскажу об основных шагах по оптимизации android приложений.
Одна из самых распространенных проблем оптимизации, с которой сталкиваются разработчики Android, это утечки памяти. Утечка памяти в Android-приложениях происходит, когда объекты, которые больше не используются, по какой-то причине не удаляются сборщиком мусора и продолжают занимать память. Это может привести к избыточному потреблению ресурсов и снижению производительности приложения.
Leak Canary
Leak Canary — это открытая библиотека для Android, которая помогает обнаруживать утечки памяти в вашем приложении. Как только утечка обнаружена, Leak Canary предоставляет уведомление с отчетом, который помогает разработчикам быстро найти и устранить причину утечки. Вся суть работы Leak Canary заключается в следующем: при добавлении зависимости в проект, в процессе его сборки интегрируется отдельный модуль. Этот модуль отслеживает жизненный цикл ссылок основных компонентов Android (и не только). Основная цель этого инструмента — обнаруживать утечки памяти, связанные с долгоживущими объектами, такими как активности, фрагменты и другие компоненты Android, которые не были корректно очищены.
Вопросы код-ревью меня интересуют очень давно. Много раз возникали те или иные проблемы то с качеством кода, то с климатом в коллективе. И действительно, code review — это если не единственное, то одно из самых главных мест для возникновения конфликтов в коллективе разработчиков.
И вот недавно при подготовке к очередному выпуску подкаста "Цинковый прод" я узнаю, что Google опубликовал свод правил по проведению Code Review, битком набитый ценными мыслями. Весь материал довольно объемный и не влезет в одну статью, поэтому я постараюсь выделить наиболее интересные (мне) мысли.
Итак, поехали
Всем привет! На связи Максим Бредихин, Android-разработчик в Тинькофф. А это — третья статья об интересных моментах из Fragment API, о которых вы, возможно, не знали.
Наливайте чай, садитесь поудобнее и приятного чтения!
Я думаю сейчас не осталось людей, незнакомых с корутинами в Kotlin. Волшебный инструмент, согласны?
На первый взгляд, Clean Architecture – довольно простой набор рекомендаций к построению приложений. Но и я, и многие мои коллеги, сильные разработчики, осознали эту архитектуру не сразу. А в последнее время в чатах и интернете я вижу всё больше ошибочных представлений, связанных с ней. Этой статьёй я хочу помочь сообществу лучше понять Clean Architecture и избавиться от распространенных заблуждений.
