Архив недели
Понедельник
Всем привет! Меня зовут Панов Алексей и эту неделю мы посвятим мобильной разработке будущего.
Очень кратко обо мне. Я живу в Екатеринбурге и работаю в Контуре в должности ведущего инженера-программиста, и в основном пишу под Android.
Люблю изучать новые технологии и рассказывать о них. Так, например, вы могли видеть меня на Подлодке, других онлайн конференциях и митапах с докладами про Flutter и Kotlin.
План на эту неделю:
В ПН расскажу про свой путь в IT, поведаю забавную историю про свое первое мобильное приложение.
Во ВТ обсудим тренды Android разработки прошлых лет, узнаем чего вы лишились, не используя DataBinding.
СР посвятим декларативному описанию UI. Поговорим про плюсы и минусы Jetpack Compose в сравнении с Flutter.
В ЧТ поговорим про типичные ошибки при работе с корутинами. Сравним возможности Coroutines Flow и RxJava.
В ПТ попробуем решить основные проблемы при работе с Kotlin Multiplatform.
В СБ будем вместе с вами тусить на крутом воркшопе по мобильной разработке будущего (о нем расскажу чуть позже).
В ВС устроим день отдыха, ответим на возникшие вопросы, подведем итоги.
Тред (Алексей Панов)
Расскажу немного про мой путь в IT
Впервые я познакомился с программированием в 12 лет. Все началось с того, что мы с другом захотели создавать свои игры, но не знали с чего начать. И тут мы узнали, что у меня в школе проходили вечерние занятия по паскалю, и мы решительно записались на них.
Нам попалась очень хорошая преподавательница, которая умела все объяснять простым языком, так через некоторое время мы даже вполне успешно участвовали в городских олимпиадах по программированию.
Но, к сожалению, паскаль не помогал в создании игр. И тут мы открыли для себя конструктор 2D игр Game Maker. Это был простой в освоении инструмент, который позволял создавать игры даже без строчки кода, используя логические блоки.
Так, с его помощью, я даже создал аналог своей любимой Dendy игры — Танчики!
Но после создания пары тройки простых игрушек, интерес к созданию игр у меня немного угас, и я понял, что мне больше нравится ломать, чем строить...
Тогда я увлекся созданием различных скриптов на Visual Basic Script, которые позволяли делать всякое забавное с компьютером, например, отрубать клавиатуру, заставлять дисковод в компьютере сходить с ума и так далее. И я даже писал об этом статьи на каком-то профильном сайте.
Так я и занимался всякой фигней, за место того, чтобы учить алгоритмы... То делал моды для майнкрафта, то занимался созданием карт и кастомных сборок для CS 1.6, но одно я понял точно, что хочу связать свою будущую профессию с программированием.
С выбором университета у меня тоже не было проблем, так как я жил в небольшом городе Свердловской области и далеко уезжать не хотел, то из университетов Екатеринбурга для меня был лишь один вариант — УрФУ.
Я выбрал кафедру радиоэлектроники и информационных технологий, был ли это правильный выбор или стоило идти на матмех сейчас сказать сложно, но может быть тогда бы у меня не было времени создать свое первое мобильное приложение и моя судьба сложилась бы иначе.
А про то, как создавал я это приложение, абсолютно не умея в Android, расскажу вам чуть позже.
Тред (Алексей Панов)
Расскажу о своем первом мобильном приложении. Эта история об упорстве, ужасных костылях и успехе.
Устраивайтесь поудобнее и запасайтесь фейспалмами
История началась в далеком 2015 году, когда я обучался на втором курсе в УрФУ и меня окончательно достало каждый раз логиниться на сайте университета, чтобы посмотреть расписание или баллы за сданную работу, к тому же у сайта не было мобильной верстки!
Это все натолкнуло меня на мысль создать свое мобильное приложение, где можно было бы узнать все то же, что и на сайте, только намного быстрее и с дополнительными фичами, вроде уведомления о следующей паре.
И так как смартфон у меня был Android, и на тот момент я уже немного знал Java, то выбор платформы был очевиден. Проблема была в том, что я совершенно не знал Android и пришлось изучать его уже в бою.
Как говорится вижу цель, не вижу препятствий. Осталось придумать как же получать данные для приложения. И путем не долгих исследований я осознаю, что у университетского сервиса нет публичного апи…
Я понимаю, что никто в здравом уме скорее всего не стал делать то же, что и я. Поэтому приведу другие варианты, чтобы бы выбрали вы в такой ситуации?
🤔
57.0% Сделал бы свой бекенд🤔
29.0% Попросил бы публичное апи🤔
14.0% Нет API — нет приложенияНо я пошел своим путем и решил парсить сайт прямо с мобилки🤦♂️ Казалось бы бери обычный http клиент, делай запрос и парси сайт, но тут я встретился с главной проблемой — аутентификацией.
Я перепробовал все адекватные варианты, отчаялся и перешел к неадекватным, а именно к использованию web view, и я сейчас не говорю про отображение верстки сайта в приложении...
Так как же залогиниться на сайте, используя webview, но при этом с нативной версткой приложения? Все очень просто: ищем поля логина и пароля в DOM-дереве, вбиваем данные и нажимаем на кнопку “войти” 🤗
Ну ладно, допустим мы зашли, а дальше что? А дальше нам необходимо как-то передать данные из webview в приложение и в этом нам поможет JavaScriptInterface.
Как ни странно, все работало как часы: я дожидался загрузки страницы, парсил данные из html и отображал их нативно. Проблема началась тогда, когда страница не перезагружалась при клике на новую неделю расписания.
Мне удалось сделать JS инъекцию и отслеживать изменения DOM поддерева, но по какой-то причине этот колбэк вызывался несколько раз и получить измененную страницу мы могли только после трех вызовов этой функции.
Ну и я недолго думая просто зафигачил счетчик вызовов функции, который обнулялся после трех вызовов. Удивляюсь как после этого я вообще не бросил программирование…
Проблем с получением данных я больше не испытывал, зато испытывал проблемы с Android, и моими лучшими друзьями стали StackOverflow и другие русскоязычные сайты по Android разработке. С такими друзьями качество кода было скажем не лучшим…
Я решил что-то с этим сделать, прочитал две крутые книжки: Effective Java и Чистый код, преисполнился и понял, что мой код максимально ужасен, но все попытки что-либо улучшить были тщетны.
Но благодаря моим врожденным навыкам к тестированию, приложение работало без нареканий, оно могло работать даже в отсутствии интернета, правильно сохраняло стейт при изменении конфигурации и так далее.
Таким образом, спустя несколько месяцев разработки, я выпустил первую версию приложения и выглядела она следующим образом. Для того времени дизайн приложения выглядел вполне сносно.
Я сделал плакаты с рекламой приложения, расклеил их в общаге и универе, рассказал о приложении всем знакомым, тем самым запустил сарафанное радио и приложение стало достаточно популярным.
Приложение было бесплатным, и мне захотелось хотя бы отбить стоимость аккаунта разработчика. Таким образом я сделал премиум доступ и даже запилил свою виртуальную валюту💵
Премиум доступ включал в себя оффлайн расписание с возможностью редактирования. И это было хорошей идеей, несмотря на то, что стоимость была всего 50 рублей, я в несколько раз окупил стоимость аккаунта разработчика.
А вот виртуальная валюта не принесла мне ничего… Чтобы ее заработать нужно было либо смотреть рекламу, либо скачивать приложения по реферальной ссылке. Это приносило очень мало денег, а вывести их можно было только после $250, которые я так и не заработал😿
Самое смешное, что для того, чтобы никто не взломал мой премиум доступ я реализовал какое-то шифрование на коленке для проверки покупки, но при этом флаг премиум доступа хранился в открытом виде в Shared Preferences...
Ну ладно, будем подводить итоги. Как думаете сколько раз за 4 года существования приложения я был вынужден переделать парсер верстки сайта? Правильно, ни разу!
С — значит стабильность.
Приложение имело более 10 тысяч установок и 800 отзывов, при этом средний рейтинг был в районе 4.8. Это очередной раз говорит, что пользователей не волнует, что у вас под капотом, главное, чтобы приложение было удобным и хорошо работало.
Также это приложение помогло мне защитить диплом, устроиться на первую работу в качестве Android разработчика. Поэтому не бойтесь экспериментировать, делать что-то новое, будьте настойчивым и у вас обязательно все получится!
Тред (Алексей Панов)
@mobileunderhood А сесия где хранилась? В куке? Кука была привязана к браузеру или ип?
Не хотел про это писать, меня точно читатели проклянут, ну да ладно. Сессия хранилась в куках WebView, но на шаге логина я запоминал логин и пароль в SharedPreferences🤫 и если тебя разлогинивало, я просто под капотом заново проставлял эти данные и логинился👌 twitter.com/pingwinator/st…
Вторник
Прежде чем перейдем к теме дня, я хочу немного рассказать про мою текущую компанию. Тред о том, почему я работаю в Контуре.
Контур — это крупная IT компания с более чем 9000 сотрудниками по всей России, и мы в Контуре создаем экосистему продуктов для бизнеса. В частности, мы в команде помогаем запускать мобильные приложения для различных продуктов компании.
Я успел поработать с несколькими продуктовыми командами, как с мастодонтами, которые на рынке уже не один год, так и со стартапами, которые еще ищут себя и пытаются создать новый успешный продукт.
Первое, что мне нравится в Контуре и в нашей команде — это процессы. Мы в команде работаем в режиме полного доверия и ориентированности на результат, и наши процессы можно четко описать фразой из скрама: “возьмите мотивированных профессионалов и оставьте их в покое”.
Когда тебе доверяют, а не постоянно следят за тобой, работается гораздо комфортнее и тебе уже не хочется как-то обмануть систему, позалипать в соц. сетях и так далее, ты стараешься работать максимально эффективно, когда находишься за компом.
Вторым безусловным плюсом для меня является офис, ведь он по факту является для меня вторым домом. В офисе есть еда, спортивный зал, вкусный кофе и конечно же кикер и живое общение. Это все способствует эффективной работе и здоровому отдыху без выгораний и стресса.
Без минусов разумеется тоже не обошлось, мобильные приложения в B2B сегменте как правило не выделяются чем-то особенным и количество пользователей в разы ниже, чем в B2C сегменте.
Но благодаря нашей специфике, я успел запустить уже несколько мобильных приложений, поработал с разными бизнес областями и разными стеками. Поэтому на этой неделе хотелось бы поделиться с вами этим опытом и рассказать об инструментах, которые мы используем.
Тред (Алексей Панов)
Сегодня хотел рассказать о том как менялась Android разработка, как угасали тренды и лучшие практики. Но давайте лучше поговорим про то, как наши деды решали главную проблему мира Android — проблему обработки конфигурации устройства.
И самым популярным вариантом решения этой проблемы была простая фиксация ориентации устройства, но почему-то многие разработчики до сих пор думают, что этого достаточно…
Но это никак не решает проблему, а лишь избавляет дизайнеров и разработчиков от продумывания дизайна приложения в ландшафтной ориентации. Ведь переворот экрана является лишь частным случаем изменения конфигурации устройства.
Следующим способом является самостоятельная обработка конфигурации. Этот способ тоже не является серебряной пулей, вы лишитесь возможности автоматической подмены ресурсов, например для ландшафтной ориентации.
Но этот механизм может помочь, если вы, например, показываете видео и хотите, чтобы при переходе в ландшафтную ориентацию оно не было приостановлено.
Еще один способ, который все еще остается актуальным — это сохранение состояния с помощью механизма SavedInstanceState. Сейчас напрямую его почти не используют, однако, в случае если необходимо восстановить данные после смерти процесса — это все еще единственный рабочий способ.
И если первые три способа все еще могут быть актуальны даже сейчас, то следующие подходы, которые считались раньше best practices вы уже вряд ли найдете в современных проектах.
Например, можно было сохранять данные с помощью Retain Fragment, у таких фрагментов колбэк onDestroy не вызвался при перевороте экрана, что позволяло сохранять данные. Какое-то время назад даже ранняя версия ViewModel использовала этот механизм для сохранения состояния.
Сейчас же ViewModel для сохранения состояния использует древний механизм lastNonConfigurationInstance. Вы можете даже сейчас легко повторить это поведение, используя кастомную конфигурацию, однако эти методы уже deprecated.
Ну а еще одним интересным способом решения проблемы являлось использование лоадеров. Вообще Loader, судя по названию, был предназначен для загрузки данных, однако он также мог переживать смерть Activity или Fragment.
Использование лоадеров ранее считалось рекомендуемым подходом, однако на сегодняшний день вряд ли кто-то из молодых разработчиков вообще о них что-либо слышал. Использовали ли лоадеры вы?
🤔
57.4% Да, было дело🤔
42.6% Первый раз слышуПроблему изменения конфигурации все решали как могли, еще одним интересным решением являлся подход в библиотеке Moxy. Там эта проблема решалась с помощью паттерна Команда, повторно проставляя нужный стейт вьюшке.
Собственно и сейчас с приходом Jetpack Compose и Kotlin Multiplatform мы до конца не избавились от этой проблемы. Кто-то переходит на Redux подход, кто-то создает библиотеки, позволяющие сохранить стейт и при этом переиспользовать код между платформами.
Таким образом мы до сих пор решаем одну и ту же задачу, что была актуальной с самого рождения Android. Со временем подходы меняются, библиотеки устаревают, но одно остается вечным — это умирающая Activity при перевороте экрана!
Тред (Алексей Панов)
Обещал еще сегодня рассказать про DataBinding, но в топку его, не использовали, значит уже и не надо. Туда же мы отправляем и новоиспеченный ViewBinding, ведь будущее за Jetpack Compose, о котором мы и поговорим завтра.
Расскажу про обещанный субботний воркшоп по мобильной разработке будущего. Мы будем рассказывать про Jetpack Compose, Kotlin Multiplatform и Swift UI, а также в прямом эфире будем делать красивое приложение на новых технологиях, запустим его под Android, iOS и даже Desktop!
Воркшоп будет проходить в двух форматах: онлайн и оффлайн. Всех, кто живет в ЕКБ или готов приехать будем ждать лично, остальных приглашаю присоединиться онлайн, будет классно!
Подробности здесь eventskbkontur.timepad.ru/event/1836080/…
@mobileunderhood По-моему, проблема уже решена: в манифесте задаём в configChanges все возможные значения, и вуаля - активити не уничтожается. Jetpack Compose будет сам обновлять UI при смене ориентации, языка, темной темы и т. д.
Интересное замечание, но кажется будут нюансы, что где-то не отработает так как нужно. Например, если работать с ресурсам не только из Compose, то может стрельнуть. Как вариант темная тема приложения в values-night не поменяется и цвет иконок в статус баре останется прежним. twitter.com/ArturArtikov1/…
Среда
Итак сегодняшний день мы посвятим декларативному UI. И начну я с истории как я чуть не стал Flutter разработчиком, расскажу что же мне в нем так понравилось, что я был готов предать нативную разработку...
Все началось с выхода первой релизной версии Flutter, тогда я наконец решился попробовать что же это такое. Поначалу писать UI в коде мне показалось странной затеей, но затем я проникся этим подходом и любовью к Flutter.
Самое первое, что подкупило меня при знакомстве с новым фреймворком — это документация. Такой отличной доки я никогда в жизни не видел, на официальном сайте была куча статей, коделабов и каждый виджет сопровождался примером использования!
Следующей киллер фичей для меня стали Hot Reload и Hot Restart, они позволяли без перезапуска приложения обновлять верстку, причем первый даже сохранял текущее состояние экрана! Я радовался как ребенок...
Подкупали меня еще возможности кастомизации UI, как же теперь было легко после Android полностью кастомизировать TextField вплоть до цвета курсора, реализовать кастомную вьюшку и так далее.
Ну а самое главное, что чтобы запустить приложение под iOS нужно было нажать всего одну кнопку и твое приложение отлично себя чувствовало на другой платформе🤩
Так я создал несколько простых приложений на Flutter и мне захотелось сделать на нем что-то серьезное. Я потихоньку начал продавать Flutter своей команде, разумеется сложнее всего было убедить iOS разработчиков, но все же многие заинтересовались этим фреймворком.
Мы с @Neil_Tirell загорелись идеей сделать крутой ивент по Flutter. Мы обратились к нашей команде за помощью, продумали доклады и структуру мероприятия. Так мы провели Флаттертон в Екатеринбурге, это был мой первый публичный опыт выступления! Эх, хорошие были доковидные времена..
После я продолжил углубляться во Flutter и тут, как по заказу, к нам приходит продуктовая команда и просит сделать мобильное приложение. В это время iOS команда была занята и я предложил использовать Flutter.
Мою идею одобрили и я приступил к созданию приложения. Я начал ресерчить библиотеки, углубляться в лучшие архитектурные практики во Flutter и мягко говоря офигел от обилия различных подходов. Это все напомнило мне генератор архитектурных паттернов iosarchitecture.top
Так после этого ресерча я даже подготовил доклад о том, как подготовить ваше Flutter приложение к продакшену и рассказал о других неочевидных нюансах youtube.com/watch?v=Xe3Ug3…
Мы начали разработку и тут моя любовь к Флаттеру постепенно начала сходить на нет, точнее больше не к самому Флаттеру, а к языку Dart. После Kotlin, Dart ощущался чем-то устаревшим и напоминал то JS, то Java..
Я получил кучу негатива от странной многопоточки с изолятами, где можно было передавать только примитивы или простые объекты до ужасно неудобной и долгой работы с когенерацией у различных библиотек.
Также во Flutter было максимально неудобно взаимодействовать с платформенным кодом. Нам нужно было интегрировать в приложение нативные модули, а взаимодействие через платформенные каналы с помощью строк позитивных эмоций тоже не вызывало.
Но мои мучения продлились не долго, и проект через несколько месяцев разработки закрыли... И, несмотря на то, что интерес к Флаттеру у меня еще не угас, делать собственный пет проект мне не хотелось, а на работе следующего шанса уже не представилось.
Так я отложил Flutter до лучших времен и спустя какое-то время открыл для себя Jetpack Compose, дружба с флаттер была окончена и я нашел себе нового лучшего друга!
Тред (Алексей Панов)
@mobileunderhood А вот стоит учить Flutter сейчас? Как ты думаешь?
Flutter все еще остается простым и удобным инструментом для создания мобильных приложений и не только, поэтому ответ скорее да, чем нет. Но если мы говорим о сложных мобильных приложениях, то я бы сейчас предпочел связку Jepack Compose + KMM twitter.com/aarexer/status…
@mobileunderhood Уже 4 с половины года прошло с релиза флаттера, как дела обстоят сейчас? Мне больше интереснее какие планы у гугла на будущее флаттера. Будут ли заменять им нативку?
Определенно нет, сейчас в мире сотни миллионов нативных приложений и нельзя взять и сказать, а давайте ка перепишите все на Flutter. Но в тоже время и Flutter успешно занял свою нишу, так что не думаю, что от него откажутся. Скорее так все и будет развиваться в параллель. twitter.com/zhanyeskendir/…
Сегодня обещал поговорить про плюсы и минусы Jetpack Compose, но давайте сделаем так, про плюсы вы узнаете из доклада в субботу, а про минусы поговорим сейчас. Один лайк — один твит о том, что меня бесит при работе с Compose
Первое, что меня бесит в Compose — это отсутствие нормального Hot Reload. Даже при малейшем изменении структуры виджета, необходимо заново билдить проект, чтобы обновить Preview и в зависимости от сложности виджета это может быть очень долго...
Второе — это импорты! Так как в Compose практически все является экстеншенами, необходимо импортировать буквально каждую строчку. Также очень легко импортнуть что-нибудь не то, например, другой Color и сидеть втыкать почему у тебя ничего не работает.
К теме импоротов, больше всего бесит следующая ситуация. Если вы забыли импортировать androidx.compose.runtime.getValue, то делегат для стейта работать не будет. И при этом исправить ситуацию автоимпортом не получится.
Также бесит предоставлять какие-то дефолтные параметры для Composable функции, чтобы показать Preview, особенно если вы передаете в функцию сложный объект. С XML версткой в этом плане было намного проще.
Не хватает возможностей модификаций виджетов из коробки, без использования сложных базовых реализаций. Ярким примером является TextField, в котором почему-то забыли запилить текст ошибки под импутом.
К теме кастомизации, просто только из-за того, что в CircularProgressIndicator захардкожен cap (он позволяет сделать прогресс закругленным или тупым), мне пришлось создавать свою реализацию.
Что еще приходит на ум, но не связано с Compose напрямую, это форматирование кода. Во Flutter, чтобы параметры в виджете расположились друг под другом, достаточно добавить запятую, в Compose же все приходится делать руками.
Бесит каждый раз писать кучу бойлерплейта, чтобы показать SnackBar, это решаемо, но все же бесит.
Чтобы показать ModalBottomSheet нужно сделать его корневым виджетом экрана из-за чего передача в него данных превращается в ад, благо библиотека navigation material из Accompanist позволяет решить эту проблему, добавив его в граф навигации.
С Bottom Sheet еще есть проблема, что если контент больше половины экрана, то bottom sheet откроется только на половину, если же вы хотите открыть сразу на полный экран, можно написать свой экстенш, но вы никак не уберете это промежуточное состоянии при свайпе.
А это промежуточное состояние будет влиять на то, как ваша верстка будет реагировать на появление клавиатуры и уже флаги adjustResizе в манифесте вас не спасут.
В Compose все еще недостаточно возможностей из коробки, например API для анимирования изменения элементов в LazyColumn появилось совсем недавно, а вот механизма Drag&Drop еще нет и приходится реализовывать самому или же искать сторонние библиотеки.
Кажется я переоценил свои силы и надо поднапрячься, чтобы вспомнить все проблемы, с которыми пришлось сталкиваться в работе с Compose. Пока я буду вспоминать, вы можете мне помочь и написать то что вам не нравится в Compose?
Четверг
@mobileunderhood А как же бесконечная возня с градл плагинами, библиотеками, которые непонятно совместимы ли с новым компоузом, ну и вообще с гредлом в целом
О да, как же я об этом мог забыть. Игра называется угадай с какой версией Kotlin совместима версия Compose.
twitter.com/NeuraSC2/statu…
@mobileunderhood у меня один вопрос: оно того стоило, переходить на compose?
Лично для меня, разумеется, ответ ДА! Последние несколько месяцев я пишу только на Compose и возвращаться к старой верстке уже нет никакого желания. А все проблемы, что я написал в треде — это мелочи, которые явно пофиксят в ближайшем будущем. twitter.com/xotta6bl4_/sta…
Еще в Compose достаточно не очевидно происходит рекомпозиция функции, если даже параметр enabled не поменялся, то функция будет вызвана повторно, если на вызывающей стороне лямбда onClick не была обернута в remember или не использована ссылка на другую функцию.
@mobileunderhood Сколько альфа версий библиотек нужно использовать, чтобы писать проект?
Это тоже можно отнести к недостаткам, в Compose все еще приходится использовать достаточно библиотек, которые не в релизе. Но ситуация стремительно меняется и либ в альфа уже практически нет, даже navigation-compose уже обзавелся бетой.
twitter.com/Xan02/status/1…
Мне нравятся модификаторы в Compose, это гораздо лучше, чем использовать отдельный виджет для отступов как во Flutter. Но так как порядок модификаторов важен, не всегда очевидно как они будут применяться в сложных цепочках.
Кажется пора перестать докапываться до Compose, ведь все проблемы надуманные, а Compoe идеален, так и запишем.
Тред (Алексей Панов)
Что-то подустал я уже графоманить в ваших твиттерах, но не могу не рассказать вам о самых частых ошибках при работе с Kotlin Coroutines.
Я начал свое знакомство с корутинами еще 2019 году, тогда нельзя было найти о них много хороших статей и примеров, а оф. документация была написана достаточно сложно и о многом умалчивала. Но даже сейчас, смотря на чужой код, я вижу множество ошибок при работе с ними.
И самой главной проблемой является обработка исключений в корутинах. Возьму слайд из своего доклада, как думаете в каких случаях ваша программа свалится с ошибкой? GetException — это suspend функция, кидающая исключение.
Правы будет те, кто выбрал первый и третий варианты. Так как исключения в корутинах не пересылаются как в случае с обычными функциями, а распространяются вверх по иерархии Job.
Если с 1 и 3 вариантом мы разобрались, а во втором случае все просто: suspend функция пересылает исключение подобно обычной функции, то четвертый случай самый неочевидный.
В случае если top level корутина запущена с помощью async, то exception будет инкапсулирован до тех пор пока мы не вызовем метод await. Но на самом деле вряд ли вам придется это использовать, так как дожидаться результата с помощью await мы также должны в coroutine scope.
Как же тогда правильно обрабатывать любые исключения? Способов на самом деле много, но можно использовать CoroutineExceptionHandler, его обязательно нужно установить либо в сам scope, либо в top level корутину!
Ещё частенько при создании своего скоупа люди указывают Job, за место SupervisorJob. В таком случае даже если у вас проставлен exception handler, при возникновении ошибки, вы больше не сможете запустить корутину в этом скоупе!
Ещё одной распространенной ошибкой является нарушение Structured Concurrency, если вы хотите запустить дочернюю корутину, не используйте для этого top level scope, используйте специальные scope билдеры!
Также не забывайте про main safety, любая вызываемая вами suspend функция должна сама управлять тем, на каком диспетчере она будет выполняться. Так вы всегда безопасно сможете вызвать эту функцию из main потока.
Но при этом, если вы производили какую-то операцию в бэкграунд потоке, не нужно обратно свитчиться на Main dispatcher, все будет происходить автоматом! Это одна из самых распространенных ошибок.
Обратная ситуация, когда меняют диспетчер при работе с Room или Retrofit, делать этого не нужно! Эти библиотеки сами поменяют диспетчер для запросов в сеть или базу, при этом сделают это более оптимально.
Бесит каждый раз писать кучу бойлерплейта, чтобы показать SnackBar, это решаемо, но все же бесит. pic.twitter.com/KopTBPIbjq
Ну и напоследок, в этом треде я намеренно (на самом деле нет) сделал ошибку при работе с корутинами. Метод showSnackbar в этом примере является suspend функцией. Как думаете в чем здесь проблема?
twitter.com/mobileunderhoo…
Это не слишком очевидно, мы пытаемся при возникновении нового эвента убрать предыдущий snackbar, и показать новый. Однако метод showSnackbar приостанавливает вызов onEach пока не будет завершен. Чтобы это исправить нужно запустить дочернюю корутину с помощью launch.
На этом все, как говорится, не болейте и используйте корутины правильно!
Тред (Алексей Панов)
Забавно, что в аккаунте мобильного разработчика треды про мобильную разработку заходят хуже.
Был ли вам полезен тред про корутины?
🤔
31.0% Да, узнал что-то новое🤔
13.2% Нет, все знал🤔
42.6% Там что-то на эльфийском🤔
13.2% RxJava One LoveПятница
Сегодня должен был быть тред про Kotlin Multiplatform, но я что-то зашиваюсь и уверен, что вы тоже подустали за эту неделю. Так что предлагаю оставить силы на завтра, это будет насыщенный день!
Суббота
Всем доброе утро! Напоминаю, что сегодня мы проводим воркшоп по мобильной разработке будущего, начинаем в 10:00 по МСК. И первый доклад о нюансах перехода на Jetpack Compose расскажу вам я, присоединяйтесь!
youtube.com/watch?v=WMRFMP…
Всем доброе утро! Напоминаю, что сегодня мы проводим воркшоп по мобильной разработке будущего, начинаем в 10:00 по МСК. И первый доклад о нюансах перехода на Jetpack Compose расскажу вам я, присоединяйтесь! youtube.com/watch?v=WMRFMP…
Мы начали, подключайтесь😉 twitter.com/mobileunderhoo…
Алексей Гладков рассказывает доклад Kotlin for everything, не пропустите!
Мы все ещё в эфире, далее Алексей Агапов расскажет про SwiftUI и покажет как сверстать на нем ещё один экран нашего приложения!
Воскресенье
Это я, когда вернулся домой после афтепати
Сегодня будем подводить итоги недели мобильной разработки будущего и начнем с итогов вчерашнего ивента. Все мероприятие прошло по плану, мы рассказали доклады, провели воркшоп ну и классно провели время. Запись доступна на канале “Технологии в Контуре” на YouTube.
Я рассказал о всех самых важных нюансах при работе с Jetpack Compose. Если в докладе что-то было непонятно, то обязательно посмотрите часть с воркшопом, где я старался объяснить все моменты не только про Compose, но и про работу с KMM, БД (SQLDelight) и DI библиотекой (Koin).
Однако если вам не нравится видео формат, можете посмотреть проект на GitHub github.com/konturmobile/M… где можно найти простой, но интересный пример использования Kotlin Multiplatform для Android, iOS и даже Desktop!
Ну что ж будем подводить итоги самой недели. Она, на мой взгляд, получилась достаточно насыщенной, особенно ее первая половина. Продублирую ссылки на все интересные треды недели.
Расскажу о своем первом мобильном приложении. Эта история об упорстве, ужасных костылях и успехе. Устраивайтесь поудобнее и запасайтесь фейспалмами pic.twitter.com/f4t4OUqHm3
В понедельник я поделился с вами историей создания моего первого приложения twitter.com/mobileunderhoo…
Сегодня хотел рассказать о том как менялась Android разработка, как угасали тренды и лучшие практики. Но давайте лучше поговорим про то, как наши деды решали главную проблему мира Android — проблему обработки конфигурации устройства. pic.twitter.com/mLMewRpxWH
Во вторник мы поговорили о самой важной проблеме в разработке под Android
twitter.com/mobileunderhoo…
Итак сегодняшний день мы посвятим декларативному UI. И начну я с истории как я чуть не стал Flutter разработчиком, расскажу что же мне в нем так понравилось, что я был готов предать нативную разработку... pic.twitter.com/FR7zVXYuyD
Среду мы посвятили декларативному UI, я рассказал как чуть не стал Flutter разработчиком и чего мне это могло стоить twitter.com/mobileunderhoo…
Сегодня обещал поговорить про плюсы и минусы Jetpack Compose, но давайте сделаем так, про плюсы вы узнаете из доклада в субботу, а про минусы поговорим сейчас. Один лайк — один твит о том, что меня бесит при работе с Compose
А также поделился своими болями при повседневной работе с Jetpack Compose twitter.com/mobileunderhoo…
Что-то подустал я уже графоманить в ваших твиттерах, но не могу не рассказать вам о самых частых ошибках при работе с Kotlin Coroutines.
Ну и последний полезный тред этой недели мы посвятили Kotlin Coroutines, разобрав самые распространенные ошибки при работе с ними twitter.com/mobileunderhoo…
Тред (Алексей Панов)
На этом с вами будем потихоньку прощаться, но до конца дня вы можете еще задать интересующие вопросы здесь в твиттере или же пишите мне прямо в телеграм t.me/ajiekcx. Надеюсь, что вы узнали что-то новое за эту неделю и просто хорошо провели время!
