Ringov

Сегодня одним постом аж два анонса!

Дебаты Flutter vs Kotlin Multiplatform

5 декабря (т.е. завтра), в 19:00 по Москве, на конференции YaTalks, в прямом эфире будут проходить дебаты между двумя хайповейшими кроссплатформенными технологиями. Выступать на стороне флаттера будут небезызвестные Гена Евстратов (Яндекс Про) и Женя Сатуров (Surf, Flutter Dev Podcast).

Независимо от результатов, это будет легендарно! Поэтому ставьте напоминалку в календарь.

Опрос по архитектурным подходам во Flutter

Думаю, не мне одному было интересно посмотреть на распределение интереса к разным подходам связывания зависимостей. Поэтому я решил пойти дальше и в целом собрать статистику по таким основополагающим темам как state-management, связывание зависимостей, работа с UI, бизнес-логика, структура проекта и т.д. Всех приглашаю проходить опрос и распространять среди всех, кто интересуется флаттером и кому есть что сказать на эту тему!

Через некоторое время я саккумулирую получившиеся результаты и замучу какую-нибудь классную инфографику — и все мы станем чуть лучше понимать друг друга: какие инструменты нам ближе, а какие вызывают больше всего противоречий.

Надеюсь, анонсы вам понравились, спасибо что читаете и вовлекаетесь в движухи! ❤️

Ringov pinned «Прошлый пин с яндексовыми материалами для погружения во Flutter немного устарел, поэтому вот обновление, чтобы всегда было под рукой. Flutter Handbook — текстовый учебник на базе Академии Яндекса Школа Мобильной Разработки 2023 — полный видео-курс из открытого…»

Прошлый пин с яндексовыми материалами для погружения во Flutter немного устарел, поэтому вот обновление, чтобы всегда было под рукой.

Flutter Handbook — текстовый учебник на базе Академии Яндекса

Школа Мобильной Разработки 2023 — полный видео-курс из открытого лектория.

Школа Мобильной Разработки 2021-2022 — публичная часть лектория прошлых лет.

Читайте и смотрите сами, советуйте друзьям ☕️

Ну всё, теперь заживем! Завезли "non-null promotion for private final fields".

Теперь по порядку: дропнулся Flutter 3.16, а вместе с ним и Dart 3.2.

И помимо кучи прочих крутых штук, полечили старую боль, от которой у всех рано или поздно припекало: даже если ваше поле final и вы проверили его на non-null, то ниже дарт всё равно требовал проверять опять 🗿 И приходилось извращаться и присваивать это final-поле в локальное final-значение, и дальше работать с ним — только тогда тот самый non-null promotion начинал работать.

class A {
  final int? _nullableField;
  
  const A(this._nullableField);
  
  check() {
    if (_nullableField == null) {
       return;
    }
    // Тут _nullableField уже никогда не будет null, 
    // но в версиях ниже 3.2 всё равно будет ошибка компиляции.
    int nonNullVar = _nullableField; 
  }
}

Но если у вас вдруг припекает не только от final-полей, но и от var-полей, которые не умеют в non-null promotion, то придется вас разочаровать — var так промоутить нельзя: вот gist с примером, а вот такой же dartpad, чтобы потыкать.

Заглянул тут случайно в один из самых первых проектов, которые писал на флаттере, и увидел там ошибку, от которой лучше постараться избавиться как можно раньше. Я там написал абстрактный виджет, а потом от него отнаследовался!

"Composition over inheritance" (композиция вместо наследования). Во флаттере это не просто технически более гибкое решение — это своего рода философия, которая лежит в основе всего фреймворка.

Как избежать ошибки? Ну, собственно, не делать как делал я:
1. Не писать виджетов с модификатором abstract
2. Не делать extends ни от каких виджетов, кроме базовых Stateful/Stateless

У этих правил есть несколько исключений, но в подавляющем большинстве случаев они не нужны. Когда-нибудь напишу про них отдельно.

Если нужны детали и причины, то вот несколько ссылочек:
1. Про композицию в доке флаттера
2. Кусочек из видео 6-летней давности про эту философию
3. Можно загуглить фразу "Composition over inheritance", там много материалов помимо флаттера

P.S. Я хоть и немного загружен в последнее время, но про канал не забываю, и уже есть несколько черновиков, о чём бы ещё хотел рассказать — так что не теряйте.

Андроидеры тут? Как вам идея Dagger 2, но на Dart?

С приятным удивлением узнал, что в Яндексе есть и затаившиеся дарт/флаттер-разработчики, которые хоть и работают в другом стеке, но в свободное время и для дарта что-то поделывают.

Как раз на прошлой неделе один из таких коллег-разработчиков показывал свой пакет: jugger.

Честно, сам пока не добрался попробовать, только доку почитал — ну это реально Dagger, круто. Так что если у вас есть большое и теплое чувство к андроидному DI, то может быть jugger — это кандидат на ваше сердечко. Ещё есть статья на хабре от автора.

И раз уж такая песня, то давайте-ка обсудим: какие (можно несколько) способы связывать зависимости в проекте вам нравятся больше всего?

Ну чо, почалось, погнали бустить канал!

Для этого нужно обновить телегу — и тогда сможете тыкнуть по ссылке и респектнуть каналу, а за это я смогу постить тут сториз 💅

На Стачке был круглый стол, на котором обсуждали тренды в мобильной разработке, в том числе и кроссплатформу.

Среди участников были и ребята из аутсорс компаний (в частности Agima и MadBrains). И они в один голос сказали, что сейчас новым заказчикам уже не нужно продавать флаттер — они уже сами всё почитали, изучили, и сами приходят с запросом “давайте нам ваш флаттер”.

Для меня это стало откровением — я думал, что в заказной разработке просвещение заказчиков про флаттер всё ещё требует некоторого усилия, а оказывается уже всё продано — бери и делай.

Плюс звучали тоже любопытные числа, что штат Flutter разработчиков за последний год (вроде бы) вырос на 50%, в то время как мобильных — на 10-15%.

Так что можете пересказывать это flutter-скептикам вокруг вас, если таковые имеются — а то они всё проспят! 🥱

Можете официально считать это фишкой канала: когда мне лень некогда писать полезные посты, я просто прошу ChatGPT сгенерить какую-нибудь дичь на тему флаттера.

На этот раз всратые советы по написанию кода:

☝️ Переменные, объявленные внутри StatefulWidget, должны быть объявлены с приставкой "внутри_".

☝️ Если вы хотите использовать async/await в Flutter, то вы должны совершить жертвоприношение в виде некоторого количества капель крови каждый раз, когда используете эту конструкцию.

☝️ Никогда не делайте бэкапы своего кода на Dart и Flutter. Это займет слишком много места на вашем жестком диске, а вам все равно не пригодится.

☝️ Если вам нужно протестировать свой код на Flutter, сделайте это на живом питоне. Никаких виртуальных машин и эмуляторов - только настоящий змей.

☝️ Для того, чтобы гарантировать эффективность вашего кода, каждый аргумент функции должен иметь уникальный идентификатор, который был сгенерирован на основе вашего хронотипа.

☝️ Если ты пишешь на Dart, то всегда начинай свой код со слов "import 'dart:math';", чтобы дать своей программе более математический характер.

☝️ Если ты пишешь на Dart, то всегда используй const, даже когда это не имеет смысла, чтобы показать свое уважение к памяти и оптимизации.

А ещё завтра выступаю на Стачке в Ульяновске, так что если вы внезапно тоже там будете — ловите в местах, где базарят за флаттер.

А вот и результат работы двух десятков людей из нескольких команд: Flutter Handbook!

Вся команда постаралась на славу, такие все котики! 😇

Читайте сами и делитесь с друзьями, кто заглядывается на флаттер, но всё никак не решится. И делитесь впечатлениями в группе в телеге!

А мы продолжим развивать хэндбук и делать его ещё круче 😎

Вышел новый выпуск Flutter Dev Podcast про FlutterFlow.
Про него я знаю уже давно, но руки не доходили попробовать. Но тут послушал подкаст и решил устроить себе челлендж — максимально быстро сделать простенькое приложение из говна и палок на No-Code.

Взял идею, которую часто даю студентам как первую домашку: есть открытая апишка — chucknorris.io — она возвращает рандомную шутку о Чаке Норрисе. Задача — сделать тиндер с такими шутками. Ну или хотя бы отображать одну шутку на экране и обновлять её по нажатию на кнопку.

Я сразу зачем-то решил делать свайпающиеся карточки (ну а чо, там был готовый элемент!), ничего не вышло, я забил, решил сделать хотя бы просто загрузку ОДНОЙ шутки на инициализации, тоже сходу не получилось, но к тому моменту я уже провозился целый час и мне стало очень жалко этот час, поэтому я категорически забил, чтобы потом не очнуться в полночь с жоским чувством вины за продолбанную субботу.

Выводы

1. Даже No-Code — это всё ещё новый инструмент, с которым нужно разбираться. Я вот достаточно много времени потратил просто на то, чтобы понять, где я вообще. Документацию я конечно же не читал, иначе какой это челлендж. Но я уверен, что если сесть возиться в следующий раз, то будет уже сильно проще.

2. Возможно плохо искал, но я не нашел инструментов для дебага. Вот если у меня приложение тупа не работает ведет себя не так, как я ожидаю — мне как понять, что именно я сделал не так?! Цените ваши дабеггеры, девтулзы и конечно же логгер, пацаны и пацанессы.

3. Оправдываюсь первыми пунктами, надеясь, что это не я просто тупой.

Спасибо сёрфам за мотивационный пинок, хоть попробовал, кто такой этот ваш FlutterFlow.

Я ещё молодой, шутливый, поэтому вскрою одну тему. Что правильнее: кидать исключения или возвращать Either?

Коротко про суть: исключения основаны на "бросании" (throw) и "перехватывании" (catch) ошибок во время выполнения, минуя возвращаемое значение. Either — это и есть возвращаемое значение, которое явно содержит два возможных результата: ошибка (left) или успех (right). Иногда используют Result(ok, error).

Несколько раз в рабочих чатах разгоралась эта тема, поэтому я решил перечитать аргументы обеих сторон и выделил ключевые.


Исключения
➕ Не нужен дополнительный класс/библиотека, от которых будет зависеть вся кодовая база, потому что исключения — это встроенный механизм языка.
➕ Сохраняется полная цепочка методов из стектрейса, можно от и до проследить, кто-кого-откуда вызвал и упал.

➖ Неявное ветвление кода из-за неожиданных исключений ухудшает понимание потока программы. А это может усложнить отладку и тестирование.

Either
➕ Обязывает обработать возвращаемое значение на уровне компиляции как в случае успеха, так и в случае ошибки.
➕ Есть удобные утилитарные методы для обработки результата, типа map/flatMap/fold.

➖ Ухудшает читаемость кода: обрабатывать оба сценария (успех и ошибку) нужно в каждом методе, что нагромождает логику. Проще читать код, когда нормальный процесс работы приложения описан в одном месте, а обработка ошибок — в другом.


Вот ещё несколько статей и обсуждений (в том числе в комментариях) на эту тему с аргументами как за, так и против:

- Тип данных Either как альтернатива выбрасыванию исключений
- Either vs Exception Handling
- Обсуждение на StackOverflow

Предлагаю голосовать: кому что ближе?

Держите пятничный анекдот:

В одной IT компании долгие годы работал один старый flutter разработчик. Перед началом каждого рабочего дня он доставал из ящичка в своем столе бумажку, читал ее и убирал назад. После его ухода на пенсию, все сотрудники кинулись смотреть, что же написано в той бумажке. Разворачивают, а там "--no-sound-nullsafety — без налсейфти, flutter pub run build_runner build --delete-conflicting-outputs --verbose — запустить кодген"

Кстати, автор этого анекдота Никита — позавчера рассказывал лекцию в ШМР про девтулзы во флаттере.

Добрался почитать результаты опроса Q1 2023 от Flutter team. Краткий пересказ, если ещё не успели ознакомиться:

1. 93% разрабов (здесь и далее — среди тех, кто прошёл опрос) довольны флаттером, из них половина — очень довольны.

2. На 24% увеличилось количество флаттер-разработчиков.

3. И Flutter-разрабы по результатам опроса, и Flutter team по своим метрикам сходятся во мнении, что флаттер растет очень быстро.

4. Те, кто не согласен с этим мнением, в основном аргументируют это отсутствием вакансий/кандидатов, либо отсутствием примеров внедрения Flutter в крупных компаниях.

5. Половина разрабов столкнулись с той или иной миграцией за последний год из-за breaking changes, 44% разрабов грустили и страдали по этому поводу, однако больше 60% сказали, что код стал чище и вообще изменения полезные.

6. В ответ на это Flutter team пообещала делать меньше ломающих изменений, т.к. флаттеру пора взрослеть и заводить семью становиться устойчивым в том числе и в плане API.

7. Firebase Dynamic Links закапывают в пользу нативных App Links и Universal Links, но на миграцию будет минимум 12 месяцев. Особенно забавно этот пункт выглядит, если перечитать предыдущий. Но на самом деле они ж не виноваты, это всё Firebase.

У Сёрфов дропнулся свежий пост про версионирование, а я давно подумывал написать про эту тему, так что идеальнее момента придумать сложно. Для контекста стоит прочитать их пост, там есть необходимая теория, а я сделаю несколько, на мой взгляд, важных дополнений.

Проблема: если при объявлении зависимостей вы используете "шапочку" (caret syntax), то при вызове flutter pub get версия таких зависимостей может обновляться автоматически вплоть до ближайшего мажора. А это мало того, что неявно, так ещё и разработчики этих библиотек могут ненароком сломать совместимость даже в рамках текущего мажора.

Ребята предлагают решать это радикально — не использовать шапочку и жестко связывать все зависимости руками. Тогда pub get никогда не сделает что-то самовольно. Это было бы хорошим решением, если бы не ломало всю концепцию версионирования по констрейнтам — давать графу зависимостей гибкость при изменении версий.

А описанная проблема решается так — в проект приложения коммитится pubspec.lock. Так нужно делать. Об этом прям курсивом сказано в документации, вот тут в последнем абзаце. Всё, вы восхитительны и вызов flutter pub get никогда ничего вам самовольно не обновит.

Ежели вы пишете не приложение, а пакет, то вы обязаны использовать "шапочку", иначе вашим пакетом будет невозможно пользоваться — наличие его в проекте как ломом заклинит все версии зависимых пакетов и они просто не будут резолвиться, если эти же пакеты есть в самом проекте-потребителе и их версии отличаются от ваших. И в этом случае правильно — не коммитить pubspec.lock. Это обязывает вас проверять свой пакет на самых свежих версиях зависимостей, потому что ваши пользователи потенциально будут использовать их в связке с вашим пакетом.

Ну и использовать dependency_overrides — это как держать паяльник за стержень, потому что так удобнее и даёт вам больше контроля над процессом. dependency_overrides — это инструмент для исключительных кейсов, когда зависимости по каким-то причинам не имеют пересекающихся констрейнтов — а это всегда не очень хорошая ситуация и всегда связано с риском огрести несовместимость интерфейсов и вообще не собрать проект.

Короче, чтобы подробнее разобраться в теме:
1. Прочитайте внимательно доку (все ссылки выше).
2. Посмотрите видосик с последнего Google I/O.
3. Посмотрите свежую лекцию с ШМР.
4. И пользуйтесь инструментом так, как это задумано его конструкцией.

В недрах флаттер-трека Школы Мобильной Разработки всплыл вечный спор за/против GetX. Решил пересмотреть легендарный баттл по этому поводу, а потом ещё наткнулся на закреп в одном из чатиков по флаттеру. Ну и, так как я свою сторону уже давно выбрал, держите небольшую выжимку из этих источников на тему "почему GetX — это плохо":

1. Переизобретает и копирует как сам флаттер, так и другие устойчивые пакеты, заточенные под разные задачи. MaterialApp, http, ChangeNotifier, стримы, MobX, GetIt и ещё массу других инструментов.

2. Нарушает буковки из SOLID; лишен абстракций и расширяемости; протекает доступ к внутренним методам; использует и поощряет антипаттерны; противоречит парадигмам, диктуемым флаттером; слабая (а иногда и "чересчур приукрашивающая") документация; нарушения кодстайла флаттера и дарта.

3. Работает хуже аналогов. Хуже перфоманс, больше багов, минимум тестов. GetX пытается быть всем и сразу, но получается у него строго хуже, чем у конкретных инструментов для конкретных задач.

4. GetX — это абстракция над абстракцией. Из-за этого чисто GetX-разработчика сложно назвать Flutter-разработчиком, потому что при использовании GetX от флаттера в коде практически не остается и следа.

5. Жесткий vendor lock. По итогу всё ваше приложение пронизано фреймворком, чего (при правильном использовании) не позволяет себе даже флаттер. При этом огромное количество копирования и дублирования вкупе с наличием всего одного главного ментейнера даёт очень высокие риски остаться с неподдерживаемым инструментом в вашем проекте.

Единственная причина, хоть как-то оправдывающая использование GetX — возможность сверхбыстро наклепать прототип, который в будущем обязательно нужно выбросить и переписать с нуля.

И давайте договоримся, что эмоджи какашки под этим постом будет означать “Мне НЕ нравится GetX!”.

Всем привет, я тут немношк пропал из-за отпуска, но зато теперь принёс вам сразу две классные штуки (и кучу ссылок).

Первая классная штука: выложили видео с нашей конференции Go Mobile. Конечно же обязательно смотрите мой доклад про то, как мы пишем полсотни приложений (это даже почти не байт).

Но вообще все доклады крутые:
1. Про важность понимания натива во флаттере
2. Про переход на Flutter от руководителей разных команд
3. Про настройку собственного pub сервера и зачем это нужно

Вторая классная штука: завтра (8 июня) в 19:00 по Москве я прямо лайв буду читать первую лекцию нашего открытого лектория Школы Мобильной Разработки по направлению Flutter. Немножко расскажу про текущее состояние дел флаттера, плюс по классике небольшое повторение базы.

Ну и в целом вот весь открытый лекторий, там ещё пачка разных направлений — записывайтесь и зовите друзей 💃

Вот вам любопытная задачка. Какой будет результат выполнения?

void main() {
  a();
  b();
  print('main');
}


Future<void> a() async {
  print('A');
  await Future.microtask(() => print('microA'));
}

Future<void> b() async {
  await null;
  print('B');
}

Насторожились из-за await null? А первым у вас выводится "main" или "A"?

Короче, две не самые очевидные вещи, которые можно взять из этого кода:
1. Асинхронная функция выполняется синхронно до первого встреченного await, т.е. весь синхронный код выполняется сразу же.
2. Если вам нужно осознанно обойти это поведение и заставить ваш синхронный код внутри асинхронной функции сразу уйти на следующую итерацию Event Loop'а — конструкция await null внезапно считается вполне каноничным вариантом.

Ну и ссылочка на почитать про async/await. Ну и ответ:
A - main - microA - B