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

Проблема: если при объявлении зависимостей вы используете "шапочку" (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. И пользуйтесь инструментом так, как это задумано его конструкцией.

Добрался почитать результаты опроса 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.

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

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

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

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

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

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

Выводы

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ну всё, теперь заживем! Завезли "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, чтобы потыкать.

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

Дебаты Flutter vs Kotlin Multiplatform

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

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

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

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

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

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