Блок и кубит — это сущности для управления состоянием, обе поставляются из пакета bloc. Фундаментально, блок и кубит — это одно и то же — они наследники BlocBase. Это сущность, хранящая в себе состояние и стрим с изменениями этого состояния. И единственный инструмент изменения этого состояния — метод emit. В аргумент методу мы передаём новое состояние, и метод синхронно изменяет его и отправляет в стрим. Отличие блока и кубита лишь в том, как мы будем вызывать метод emit.
Кубит — это, буквально, BlocBase. Следовательно, единственный способ вызывать метод emit — просто напрямую. Но, он protected — значит его можно вызывать только внутри класса или внутри дочерних классов. Поэтому в каждом конкретном кубите мы описываем наши собственные публичные методы с нужным набором аргументов, и уже внутри них вызываем метод emit, чтобы обновить состояние по результатам выполнения.
Блок — это BlocBase на стероидах. Ключевое отличие — в блоке появляется стрим событий. В блоке мы описываем события (базовый класс + дочерние) с набором аргументов и кидаем их в блок через единственный метод add. А логику обработки событий описываем в методах, которые регистрируем в конструкторе блока через метод on. Кайф в том, что этот метод принимает коллбек EventHandler, который может быть асинхронным. И все события, которые попадают в один и тот же обработчик, будут обрабатываться асинхронно, но последовательно, образуя очередь событий. Ну и чтобы обновить состояние блока из EventHandler'а, у него в аргументах есть Emitter, в который мы по готовности закидываем новое состояние.
Короче, что кубит, что блок — это просто класс с мутабельным полем (стейтом) и стримом. В кубите мы обновляем это поле через метод emit, а в блоке — через отправку событий в отдельный стрим, обработка которого происходит в обработчике EventHandler. В нём написана асинхронная логика обновления состояния.
Кубит — это, буквально, BlocBase. Следовательно, единственный способ вызывать метод emit — просто напрямую. Но, он protected — значит его можно вызывать только внутри класса или внутри дочерних классов. Поэтому в каждом конкретном кубите мы описываем наши собственные публичные методы с нужным набором аргументов, и уже внутри них вызываем метод emit, чтобы обновить состояние по результатам выполнения.
Блок — это BlocBase на стероидах. Ключевое отличие — в блоке появляется стрим событий. В блоке мы описываем события (базовый класс + дочерние) с набором аргументов и кидаем их в блок через единственный метод add. А логику обработки событий описываем в методах, которые регистрируем в конструкторе блока через метод on. Кайф в том, что этот метод принимает коллбек EventHandler, который может быть асинхронным. И все события, которые попадают в один и тот же обработчик, будут обрабатываться асинхронно, но последовательно, образуя очередь событий. Ну и чтобы обновить состояние блока из EventHandler'а, у него в аргументах есть Emitter, в который мы по готовности закидываем новое состояние.
Короче, что кубит, что блок — это просто класс с мутабельным полем (стейтом) и стримом. В кубите мы обновляем это поле через метод emit, а в блоке — через отправку событий в отдельный стрим, обработка которого происходит в обработчике EventHandler. В нём написана асинхронная логика обновления состояния.
👍6
Лысый чувак в левом нижнем углу фотографии — это Роман Назаров. Насколько я понял, здесь он впервые услышал про флаттер. Зато он — офигенный тренер по публичным выступлениям. На ютубе у него есть гигантский трехчасовой прямой эфир по подготовке к публичным выступлениям, ну или есть часовая лекция поменьше, если вы очень торопитесь.
А ещё на этой фотке есть я — рассказываю чистовой прогон своего доклада Роману. Потому что через 2 недели, 22 апреля, команда Яндекс Go и Яндекс Pro проведёт большую конференцию по мобильной разработке! И там целый трек будет посвящен Flutter-разработке. Ну и я тоже там докладываюсь.
Конференция будет оффлайн в Москве и без live-трансляции, поэтому если у вас есть возможность поприсутствовать физически — срочно регистрируйтесь вот прям щас! Потому что количество мест ограничено. А конфа будет космическая, уж поверьте😎
А когда придёте на конфу — ловите меня после доклада, поболтаем🙃
#event
А ещё на этой фотке есть я — рассказываю чистовой прогон своего доклада Роману. Потому что через 2 недели, 22 апреля, команда Яндекс Go и Яндекс Pro проведёт большую конференцию по мобильной разработке! И там целый трек будет посвящен Flutter-разработке. Ну и я тоже там докладываюсь.
Конференция будет оффлайн в Москве и без live-трансляции, поэтому если у вас есть возможность поприсутствовать физически — срочно регистрируйтесь вот прям щас! Потому что количество мест ограничено. А конфа будет космическая, уж поверьте
А когда придёте на конфу — ловите меня после доклада, поболтаем
#event
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥7❤3👍2🤩1💩1
Последние 2 недели были насыщены активностями, поэтому писать что-то сюда сил уже не хватало. Зато мы провели офигенный интенсив в Сириусе по флаттеру и iOS, а сразу после него — конфу по мобилке от Яндекс Go.
Поэтому, чтобы вы меня не совсем теряли, держите напоминание: уже ровно через 2 недели пройдет Google I/O, так что не забывайте регистрироваться. Будем надеяться, что генеративные нейросетки не займут весь эфир и флаттеру тоже достанется🫥
Поэтому, чтобы вы меня не совсем теряли, держите напоминание: уже ровно через 2 недели пройдет Google I/O, так что не забывайте регистрироваться. Будем надеяться, что генеративные нейросетки не займут весь эфир и флаттеру тоже достанется
Please open Telegram to view this post
VIEW IN TELEGRAM
👍8❤6🔥3
В Dart очень изящно избавились от ключевого слова interface, а теперь снова его добавляют (и, на мой взгляд, не зря). Но независимо от его наличия/отсутствия мне всегда немножко грустно от избыточного использования сущности интерфейсов в любой непонятной ситуации. Потому что пользы это не добавляет, зато добавляет много бесполезного кода, который точно никогда не пригодится.
В дарте любой класс — это уже неявный интерфейс. Поэтому по умолчанию у класса уже есть интерфейс, его не нужно писать дополнительно! А выделять в отдельный класс-интерфейс его имеет смысл в трех случаях:
1. Когда есть несколько реализаций одного и того же публичного API класса.
2. Когда у реализации публичный интерфейс для “потребителя” шире, чем для внутреннего использования, и его нужно сузить.
3. Когда реализации в принципе не существует и её должен написать сам "потребитель".
И вот ещё статейка на эту тему (правда не про Dart).
В дарте любой класс — это уже неявный интерфейс. Поэтому по умолчанию у класса уже есть интерфейс, его не нужно писать дополнительно! А выделять в отдельный класс-интерфейс его имеет смысл в трех случаях:
1. Когда есть несколько реализаций одного и того же публичного API класса.
2. Когда у реализации публичный интерфейс для “потребителя” шире, чем для внутреннего использования, и его нужно сузить.
3. Когда реализации в принципе не существует и её должен написать сам "потребитель".
И вот ещё статейка на эту тему (правда не про Dart).
👍6🔥6⚡3
Пятничный серьезный пост про Google I/O
Google I/O состоялся, там объявили о релизах и рассказали про новые возможности в Dart 3 и в Flutter 3.10. Почитать про них вы можете и в приведенных статьях, а вот про секретные неанонсированные возможности вы нигде, кроме как тут, не узнаете! Итак, вот они:
Dart 3
👩💻 Добавлены ключевые слова
👩💻 Теперь в Dart есть ключевое слово
👩💻 Введен новый оператор
👩💻 Dart теперь позволяет использовать магические заклинания вместо ключевых слов, которые упрощают синтаксис и делают код более читабельным. Например, вместо
👩💻 Добавлена возможность создавать асинхронные функции, которые работают только по выходным дням.
👩💻 Введена функция
👩💻 Появился новый модификатор доступа
👩💻 Добавлен оператор
👩💻 Добавлен модификатор
👩💻 Dart 3.0 теперь позволяет программистам использовать печенье вместо переменных.
Flutter 3.10
👩💻 Теперь для создания кнопок в Flutter нужно использовать не
👩💻 Flutter 3.10 позволяет создавать анимации с помощью жестов тела, включая танцы.
👩💻 Теперь вы можете использовать
👩💻 Flutter 3.10 позволяет создавать пользовательский интерфейс, который изменяется в зависимости от фазы луны.
👩💻 В Flutter 3.10 появился новый виджет "Кричащий текст", который автоматически изменяет размер шрифта, чтобы привлечь внимание пользователя. Доступен только в ярко-розовом цвете.
👩💻 Добавлен новый виджет
👩💻 В Flutter появился виджет
👩💻 В Flutter 3.10 добавлена новая опция для виджетов "невидимое нажатие", которая позволяет пользователям нажимать на несуществующие элементы экрана.
👩💻 Flutter добавил новый виджет для создания духовных мантр под названием
👩💻 В Flutter 3.10 появилась новая функция
Да, это ChatGPT сгенерировал
Google I/O состоялся, там объявили о релизах и рассказали про новые возможности в Dart 3 и в Flutter 3.10. Почитать про них вы можете и в приведенных статьях, а вот про секретные неанонсированные возможности вы нигде, кроме как тут, не узнаете! Итак, вот они:
Dart 3
maybe, probably, и who-knows для более точного описания неопределенных переменных. sarcasm, которое позволяет писать саркастический код, который будет компилироваться только в случае, если в вашей команде есть программисты с достаточным уровнем чувства юмора. ??!, который выбрасывает случайное исключение. if можно написать abra cadabra. magic(), которая автоматически исправляет все ошибки в коде, используя магию. invisible, который делает переменную невидимой для всех, кроме тебя. maybeNull, который возвращает null с вероятностью 50%. awesome, который делает функцию более крутой. Flutter 3.10
ElevatedButton и не TextButton, а EmojiButton и GifButton. FlutterTeleportation для перемещения виджетов из одного места в другое без анимации! FlutterSocialDistancer, который автоматически раздвигает элементы UI на безопасное расстояние друг от друга. MemeGenerator, который автоматически создает мемы на основе данных, полученных от пользователя. PrayerWidget, который позволяет пользователям создавать свои собственные мантры и повторять их в своих приложениях. shakePhone(), которая вызывает случайные вибрации на устройстве пользователя.Please open Telegram to view this post
VIEW IN TELEGRAM
😁15🤣8🫡2❤1💩1👻1
Вот вам любопытная задачка. Какой будет результат выполнения?
Насторожились из-за
Короче, две не самые очевидные вещи, которые можно взять из этого кода:
1. Асинхронная функция выполняется синхронно до первого встреченного await, т.е. весь синхронный код выполняется сразу же.
2. Если вам нужно осознанно обойти это поведение и заставить ваш синхронный код внутри асинхронной функции сразу уйти на следующую итерацию Event Loop'а — конструкция
Ну и ссылочка на почитать про async/await. Ну и ответ:
A - main - microA - B
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. Ну и ответ:
👍7🔥3✍2💩2🌭2👨💻2😱1
Всем привет, я тут немношк пропал из-за отпуска, но зато теперь принёс вам сразу две классные штуки (и кучу ссылок).
Первая классная штука: выложили видео с нашей конференции Go Mobile. Конечно же обязательно смотрите мой доклад про то, как мы пишем полсотни приложений (это даже почти не байт).
Но вообще все доклады крутые:
1. Про важность понимания натива во флаттере
2. Про переход на Flutter от руководителей разных команд
3. Про настройку собственного pub сервера и зачем это нужно
Вторая классная штука: завтра (8 июня) в 19:00 по Москве я прямо лайв буду читать первую лекцию нашего открытого лектория Школы Мобильной Разработки по направлению Flutter. Немножко расскажу про текущее состояние дел флаттера, плюс по классике небольшое повторение базы.
Ну и в целом вот весь открытый лекторий, там ещё пачка разных направлений — записывайтесь и зовите друзей💃
Первая классная штука: выложили видео с нашей конференции Go Mobile. Конечно же обязательно смотрите мой доклад про то, как мы пишем полсотни приложений (это даже почти не байт).
Но вообще все доклады крутые:
1. Про важность понимания натива во флаттере
2. Про переход на Flutter от руководителей разных команд
3. Про настройку собственного pub сервера и зачем это нужно
Вторая классная штука: завтра (8 июня) в 19:00 по Москве я прямо лайв буду читать первую лекцию нашего открытого лектория Школы Мобильной Разработки по направлению Flutter. Немножко расскажу про текущее состояние дел флаттера, плюс по классике небольшое повторение базы.
Ну и в целом вот весь открытый лекторий, там ещё пачка разных направлений — записывайтесь и зовите друзей
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥13❤4⚡1🤡1🤗1
В недрах флаттер-трека Школы Мобильной Разработки всплыл вечный спор за/против GetX. Решил пересмотреть легендарный баттл по этому поводу, а потом ещё наткнулся на закреп в одном из чатиков по флаттеру. Ну и, так как я свою сторону уже давно выбрал, держите небольшую выжимку из этих источников на тему "почему GetX — это плохо":
1. Переизобретает и копирует как сам флаттер, так и другие устойчивые пакеты, заточенные под разные задачи. MaterialApp, http, ChangeNotifier, стримы, MobX, GetIt и ещё массу других инструментов.
2. Нарушает буковки из SOLID; лишен абстракций и расширяемости; протекает доступ к внутренним методам; использует и поощряет антипаттерны; противоречит парадигмам, диктуемым флаттером; слабая (а иногда и "чересчур приукрашивающая") документация; нарушения кодстайла флаттера и дарта.
3. Работает хуже аналогов. Хуже перфоманс, больше багов, минимум тестов. GetX пытается быть всем и сразу, но получается у него строго хуже, чем у конкретных инструментов для конкретных задач.
4. GetX — это абстракция над абстракцией. Из-за этого чисто GetX-разработчика сложно назвать Flutter-разработчиком, потому что при использовании GetX от флаттера в коде практически не остается и следа.
5. Жесткий vendor lock. По итогу всё ваше приложение пронизано фреймворком, чего (при правильном использовании) не позволяет себе даже флаттер. При этом огромное количество копирования и дублирования вкупе с наличием всего одного главного ментейнера даёт очень высокие риски остаться с неподдерживаемым инструментом в вашем проекте.
Единственная причина, хоть как-то оправдывающая использование GetX — возможность сверхбыстро наклепать прототип, который в будущем обязательно нужно выбросить и переписать с нуля.
И давайте договоримся, что эмоджи какашки под этим постом будет означать “Мне НЕ нравится GetX!”.
1. Переизобретает и копирует как сам флаттер, так и другие устойчивые пакеты, заточенные под разные задачи. MaterialApp, http, ChangeNotifier, стримы, MobX, GetIt и ещё массу других инструментов.
2. Нарушает буковки из SOLID; лишен абстракций и расширяемости; протекает доступ к внутренним методам; использует и поощряет антипаттерны; противоречит парадигмам, диктуемым флаттером; слабая (а иногда и "чересчур приукрашивающая") документация; нарушения кодстайла флаттера и дарта.
3. Работает хуже аналогов. Хуже перфоманс, больше багов, минимум тестов. GetX пытается быть всем и сразу, но получается у него строго хуже, чем у конкретных инструментов для конкретных задач.
4. GetX — это абстракция над абстракцией. Из-за этого чисто GetX-разработчика сложно назвать Flutter-разработчиком, потому что при использовании GetX от флаттера в коде практически не остается и следа.
5. Жесткий vendor lock. По итогу всё ваше приложение пронизано фреймворком, чего (при правильном использовании) не позволяет себе даже флаттер. При этом огромное количество копирования и дублирования вкупе с наличием всего одного главного ментейнера даёт очень высокие риски остаться с неподдерживаемым инструментом в вашем проекте.
Единственная причина, хоть как-то оправдывающая использование GetX — возможность сверхбыстро наклепать прототип, который в будущем обязательно нужно выбросить и переписать с нуля.
И давайте договоримся, что эмоджи какашки под этим постом будет означать “Мне НЕ нравится GetX!”.
💩32🤡5❤4👍2🔥2👌2💯2😎1
У Сёрфов дропнулся свежий пост про версионирование, а я давно подумывал написать про эту тему, так что идеальнее момента придумать сложно. Для контекста стоит прочитать их пост, там есть необходимая теория, а я сделаю несколько, на мой взгляд, важных дополнений.
Проблема: если при объявлении зависимостей вы используете "шапочку" (caret syntax), то при вызове
Ребята предлагают решать это радикально — не использовать шапочку и жестко связывать все зависимости руками. Тогда
А описанная проблема решается так — в проект приложения коммитится pubspec.lock. Так нужно делать. Об этом прям курсивом сказано в документации, вот тут в последнем абзаце. Всё, вы восхитительны и вызов
Ежели вы пишете не приложение, а пакет, то вы обязаны использовать "шапочку", иначе вашим пакетом будет невозможно пользоваться — наличие его в проекте как ломом заклинит все версии зависимых пакетов и они просто не будут резолвиться, если эти же пакеты есть в самом проекте-потребителе и их версии отличаются от ваших. И в этом случае правильно — не коммитить pubspec.lock. Это обязывает вас проверять свой пакет на самых свежих версиях зависимостей, потому что ваши пользователи потенциально будут использовать их в связке с вашим пакетом.
Ну и использовать dependency_overrides — это как держать паяльник за стержень, потому что так удобнее и даёт вам больше контроля над процессом. dependency_overrides — это инструмент для исключительных кейсов, когда зависимости по каким-то причинам не имеют пересекающихся констрейнтов — а это всегда не очень хорошая ситуация и всегда связано с риском огрести несовместимость интерфейсов и вообще не собрать проект.
Короче, чтобы подробнее разобраться в теме:
1. Прочитайте внимательно доку (все ссылки выше).
2. Посмотрите видосик с последнего Google I/O.
3. Посмотрите свежую лекцию с ШМР.
4. И пользуйтесь инструментом так, как это задумано его конструкцией.
Проблема: если при объявлении зависимостей вы используете "шапочку" (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. И пользуйтесь инструментом так, как это задумано его конструкцией.
👍19❤2
Добрался почитать результаты опроса 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 .
1. 93% разрабов (здесь и далее — среди тех, кто прошёл опрос) довольны флаттером, из них половина — очень довольны.
2. На 24% увеличилось количество флаттер-разработчиков.
3. И Flutter-разрабы по результатам опроса, и Flutter team по своим метрикам сходятся во мнении, что флаттер растет очень быстро.
4. Те, кто не согласен с этим мнением, в основном аргументируют это отсутствием вакансий/кандидатов, либо отсутствием примеров внедрения Flutter в крупных компаниях.
5. Половина разрабов столкнулись с той или иной миграцией за последний год из-за breaking changes, 44% разрабов грустили и страдали по этому поводу, однако больше 60% сказали, что код стал чище и вообще изменения полезные.
6. В ответ на это Flutter team пообещала делать меньше ломающих изменений, т.к. флаттеру пора взрослеть и
7. Firebase Dynamic Links закапывают в пользу нативных App Links и Universal Links, но на миграцию будет минимум 12 месяцев. Особенно забавно этот пункт выглядит, если перечитать предыдущий.
👍4👌4❤1
Держите пятничный анекдот:
В одной IT компании долгие годы работал один старый flutter разработчик. Перед началом каждого рабочего дня он доставал из ящичка в своем столе бумажку, читал ее и убирал назад. После его ухода на пенсию, все сотрудники кинулись смотреть, что же написано в той бумажке. Разворачивают, а там "--no-sound-nullsafety — без налсейфти, flutter pub run build_runner build --delete-conflicting-outputs --verbose — запустить кодген "
Кстати, автор этого анекдота Никита — позавчера рассказывал лекцию в ШМР про девтулзы во флаттере.
В одной IT компании долгие годы работал один старый flutter разработчик. Перед началом каждого рабочего дня он доставал из ящичка в своем столе бумажку, читал ее и убирал назад. После его ухода на пенсию, все сотрудники кинулись смотреть, что же написано в той бумажке. Разворачивают, а там "
Кстати, автор этого анекдота Никита — позавчера рассказывал лекцию в ШМР про девтулзы во флаттере.
🤣20👍7😁3🤮1🤡1🙈1
Я ещё молодой, шутливый, поэтому вскрою одну тему. Что правильнее: кидать исключения или возвращать Either?
Коротко про суть: исключения основаны на "бросании" (throw) и "перехватывании" (catch) ошибок во время выполнения, минуя возвращаемое значение. Either — это и есть возвращаемое значение, которое явно содержит два возможных результата: ошибка (left) или успех (right). Иногда используют Result(ok, error).
Несколько раз в рабочих чатах разгоралась эта тема, поэтому я решил перечитать аргументы обеих сторон и выделил ключевые.
Исключения
➕ Не нужен дополнительный класс/библиотека, от которых будет зависеть вся кодовая база, потому что исключения — это встроенный механизм языка.
➕ Сохраняется полная цепочка методов из стектрейса, можно от и до проследить, кто-кого-откуда вызвал и упал.
➖ Неявное ветвление кода из-за неожиданных исключений ухудшает понимание потока программы. А это может усложнить отладку и тестирование.
Either
➕ Обязывает обработать возвращаемое значение на уровне компиляции как в случае успеха, так и в случае ошибки.
➕ Есть удобные утилитарные методы для обработки результата, типа map/flatMap/fold.
➖ Ухудшает читаемость кода: обрабатывать оба сценария (успех и ошибку) нужно в каждом методе, что нагромождает логику. Проще читать код, когда нормальный процесс работы приложения описан в одном месте, а обработка ошибок — в другом.
Вот ещё несколько статей и обсуждений (в том числе в комментариях) на эту тему с аргументами как за, так и против:
- Тип данных Either как альтернатива выбрасыванию исключений
- Either vs Exception Handling
- Обсуждение на StackOverflow
Предлагаю голосовать: кому что ближе?
Коротко про суть: исключения основаны на "бросании" (throw) и "перехватывании" (catch) ошибок во время выполнения, минуя возвращаемое значение. Either — это и есть возвращаемое значение, которое явно содержит два возможных результата: ошибка (left) или успех (right). Иногда используют Result(ok, error).
Несколько раз в рабочих чатах разгоралась эта тема, поэтому я решил перечитать аргументы обеих сторон и выделил ключевые.
Исключения
Either
Вот ещё несколько статей и обсуждений (в том числе в комментариях) на эту тему с аргументами как за, так и против:
- Тип данных Either как альтернатива выбрасыванию исключений
- Either vs Exception Handling
- Обсуждение на StackOverflow
Предлагаю голосовать: кому что ближе?
Please open Telegram to view this post
VIEW IN TELEGRAM
👍6👨💻3❤1👻1
Вышел новый выпуск Flutter Dev Podcast про FlutterFlow.
Про него я знаю уже давно, но руки не доходили попробовать. Но тут послушал подкаст и решил устроить себе челлендж — максимально быстро сделать простенькое приложениеиз говна и палок на No-Code.
Взял идею, которую часто даю студентам как первую домашку: есть открытая апишка — chucknorris.io — она возвращает рандомную шутку о Чаке Норрисе. Задача — сделать тиндер с такими шутками. Ну или хотя бы отображать одну шутку на экране и обновлять её по нажатию на кнопку.
Я сразу зачем-то решил делать свайпающиеся карточки (ну а чо, там был готовый элемент!), ничего не вышло, я забил, решил сделать хотя бы просто загрузку ОДНОЙ шутки на инициализации, тоже сходу не получилось, но к тому моменту я уже провозился целый час и мне стало очень жалко этот час, поэтому я категорически забил, чтобы потом не очнуться в полночь с жоским чувством вины за продолбанную субботу.
Выводы
1. Даже No-Code — это всё ещё новый инструмент, с которым нужно разбираться. Я вот достаточно много времени потратил просто на то, чтобы понять, где я вообще. Документацию я конечно же не читал, иначе какой это челлендж. Но я уверен, что если сесть возиться в следующий раз, то будет уже сильно проще.
2. Возможно плохо искал, но я не нашел инструментов для дебага. Вот если у меня приложениетупа не работает ведет себя не так, как я ожидаю — мне как понять, что именно я сделал не так?! Цените ваши дабеггеры, девтулзы и конечно же логгер, пацаны и пацанессы.
3. Оправдываюсь первыми пунктами, надеясь, что это не я просто тупой.
Спасибо сёрфам за мотивационный пинок, хоть попробовал, кто такой этот ваш FlutterFlow.
Про него я знаю уже давно, но руки не доходили попробовать. Но тут послушал подкаст и решил устроить себе челлендж — максимально быстро сделать простенькое приложение
Взял идею, которую часто даю студентам как первую домашку: есть открытая апишка — chucknorris.io — она возвращает рандомную шутку о Чаке Норрисе. Задача — сделать тиндер с такими шутками. Ну или хотя бы отображать одну шутку на экране и обновлять её по нажатию на кнопку.
Я сразу зачем-то решил делать свайпающиеся карточки (ну а чо, там был готовый элемент!), ничего не вышло, я забил, решил сделать хотя бы просто загрузку ОДНОЙ шутки на инициализации, тоже сходу не получилось, но к тому моменту я уже провозился целый час и мне стало очень жалко этот час, поэтому я категорически забил, чтобы потом не очнуться в полночь с жоским чувством вины за продолбанную субботу.
Выводы
1. Даже No-Code — это всё ещё новый инструмент, с которым нужно разбираться. Я вот достаточно много времени потратил просто на то, чтобы понять, где я вообще. Документацию я конечно же не читал, иначе какой это челлендж. Но я уверен, что если сесть возиться в следующий раз, то будет уже сильно проще.
2. Возможно плохо искал, но я не нашел инструментов для дебага. Вот если у меня приложение
3. Оправдываюсь первыми пунктами, надеясь, что это не я просто тупой.
Спасибо сёрфам за мотивационный пинок, хоть попробовал, кто такой этот ваш FlutterFlow.
👨💻8😁3🥴3👏2💩2👍1🤓1
А вот и результат работы двух десятков людей из нескольких команд: Flutter Handbook!
Вся команда постаралась на славу, такие все котики!😇
Читайте сами и делитесь с друзьями, кто заглядывается на флаттер, но всё никак не решится. И делитесь впечатлениями в группе в телеге!
А мы продолжим развивать хэндбук и делать его ещё круче 😎
Вся команда постаралась на славу, такие все котики!
Читайте сами и делитесь с друзьями, кто заглядывается на флаттер, но всё никак не решится. И делитесь впечатлениями в группе в телеге!
А мы продолжим развивать хэндбук и делать его ещё круче 😎
Please open Telegram to view this post
VIEW IN TELEGRAM
education.yandex.ru
Flutter — Хендбук от Яндекс Образования
Этот хендбук позволит вам разобраться в устройстве Flutter, особенностях его компонентов, языке Dart и паттернах проектирования современных приложений
🔥29❤6👏2❤🔥1🎉1
Можете официально считать это фишкой канала: когда мне лень некогда писать полезные посты, я просто прошу ChatGPT сгенерить какую-нибудь дичь на тему флаттера.
На этот раз всратые советы по написанию кода:
☝️ Переменные, объявленные внутри StatefulWidget, должны быть объявлены с приставкой "внутри_".
☝️ Если вы хотите использовать async/await в Flutter, то вы должны совершить жертвоприношение в виде некоторого количества капель крови каждый раз, когда используете эту конструкцию.
☝️ Никогда не делайте бэкапы своего кода на Dart и Flutter. Это займет слишком много места на вашем жестком диске, а вам все равно не пригодится.
☝️ Если вам нужно протестировать свой код на Flutter, сделайте это на живом питоне. Никаких виртуальных машин и эмуляторов - только настоящий змей.
☝️ Для того, чтобы гарантировать эффективность вашего кода, каждый аргумент функции должен иметь уникальный идентификатор, который был сгенерирован на основе вашего хронотипа.
☝️ Если ты пишешь на Dart, то всегда начинай свой код со слов "import 'dart:math';", чтобы дать своей программе более математический характер.
☝️ Если ты пишешь на Dart, то всегда используй const, даже когда это не имеет смысла, чтобы показать свое уважение к памяти и оптимизации.
А ещё завтра выступаю на Стачке в Ульяновске, так что если вы внезапно тоже там будете — ловите в местах, где базарят за флаттер.
На этот раз всратые советы по написанию кода:
А ещё завтра выступаю на Стачке в Ульяновске, так что если вы внезапно тоже там будете — ловите в местах, где базарят за флаттер.
Please open Telegram to view this post
VIEW IN TELEGRAM
😁13🦄6🔥4🌭2✍1💩1
На Стачке был круглый стол, на котором обсуждали тренды в мобильной разработке, в том числе и кроссплатформу.
Среди участников были и ребята из аутсорс компаний (в частности Agima и MadBrains). И они в один голос сказали, что сейчас новым заказчикам уже не нужно продавать флаттер — они уже сами всё почитали, изучили, и сами приходят с запросом “давайте нам ваш флаттер”.
Для меня это стало откровением — я думал, что в заказной разработке просвещение заказчиков про флаттер всё ещё требует некоторого усилия, а оказывается уже всё продано — бери и делай.
Плюс звучали тоже любопытные числа, что штат Flutter разработчиков за последний год (вроде бы) вырос на 50%, в то время как мобильных — на 10-15%.
Так что можете пересказывать это flutter-скептикам вокруг вас, если таковые имеются — а то они всё проспят!🥱
Среди участников были и ребята из аутсорс компаний (в частности Agima и MadBrains). И они в один голос сказали, что сейчас новым заказчикам уже не нужно продавать флаттер — они уже сами всё почитали, изучили, и сами приходят с запросом “давайте нам ваш флаттер”.
Для меня это стало откровением — я думал, что в заказной разработке просвещение заказчиков про флаттер всё ещё требует некоторого усилия, а оказывается уже всё продано — бери и делай.
Плюс звучали тоже любопытные числа, что штат Flutter разработчиков за последний год (вроде бы) вырос на 50%, в то время как мобильных — на 10-15%.
Так что можете пересказывать это flutter-скептикам вокруг вас, если таковые имеются — а то они всё проспят!
Please open Telegram to view this post
VIEW IN TELEGRAM
👍12🔥10💯3😱1😈1😴1
Ну чо, почалось, погнали бустить канал!
Для этого нужно обновить телегу — и тогда сможете тыкнуть по ссылке и респектнуть каналу, а за это я смогу постить тут сториз💅
Для этого нужно обновить телегу — и тогда сможете тыкнуть по ссылке и респектнуть каналу, а за это я смогу постить тут сториз
Please open Telegram to view this post
VIEW IN TELEGRAM
Telegram
Flutter Bro
Проголосуйте за канал, чтобы он получил больше возможностей.
💅10❤2👎2⚡1🔥1😁1
Андроидеры тут? Как вам идея Dagger 2, но на Dart?
С приятным удивлением узнал, что в Яндексе есть и затаившиеся дарт/флаттер-разработчики, которые хоть и работают в другом стеке, но в свободное время и для дарта что-то поделывают.
Как раз на прошлой неделе один из таких коллег-разработчиков показывал свой пакет: jugger.
Честно, сам пока не добрался попробовать, только доку почитал — ну это реально Dagger, круто. Так что если у вас есть большое и теплое чувство к андроидному DI, то может быть jugger — это кандидат на ваше сердечко. Ещё есть статья на хабре от автора.
И раз уж такая песня, то давайте-ка обсудим: какие (можно несколько) способы связывать зависимости в проекте вам нравятся больше всего?
С приятным удивлением узнал, что в Яндексе есть и затаившиеся дарт/флаттер-разработчики, которые хоть и работают в другом стеке, но в свободное время и для дарта что-то поделывают.
Как раз на прошлой неделе один из таких коллег-разработчиков показывал свой пакет: jugger.
Честно, сам пока не добрался попробовать, только доку почитал — ну это реально Dagger, круто. Так что если у вас есть большое и теплое чувство к андроидному DI, то может быть jugger — это кандидат на ваше сердечко. Ещё есть статья на хабре от автора.
И раз уж такая песня, то давайте-ка обсудим: какие (можно несколько) способы связывать зависимости в проекте вам нравятся больше всего?
👍4🔥3👌2🤷♂1
Мои любимые способы связывать зависимости во Flutter
Anonymous Poll
4%
GetX
19%
GetIt
25%
GetIt + Injectable
26%
Provider
25%
Riverpod
16%
Просто класс с полями-зависимостями
8%
Синглтоны
2%
jugger
16%
Любой, главное чтобы проект был душевный
6%
Всё это хайп, я пользуюсь андеграундными решениями
Заглянул тут случайно в один из самых первых проектов, которые писал на флаттере, и увидел там ошибку, от которой лучше постараться избавиться как можно раньше. Я там написал абстрактный виджет, а потом от него отнаследовался!
"Composition over inheritance" (композиция вместо наследования). Во флаттере это не просто технически более гибкое решение — это своего рода философия, которая лежит в основе всего фреймворка.
Как избежать ошибки? Ну, собственно, не делать как делал я:
1. Не писать виджетов с модификатором abstract
2. Не делать extends ни от каких виджетов, кроме базовых Stateful/Stateless
У этих правил есть несколько исключений, но в подавляющем большинстве случаев они не нужны. Когда-нибудь напишу про них отдельно.
Если нужны детали и причины, то вот несколько ссылочек:
1. Про композицию в доке флаттера
2. Кусочек из видео 6-летней давности про эту философию
3. Можно загуглить фразу "Composition over inheritance", там много материалов помимо флаттера
P.S. Я хоть и немного загружен в последнее время, но про канал не забываю, и уже есть несколько черновиков, о чём бы ещё хотел рассказать — так что не теряйте.
"Composition over inheritance" (композиция вместо наследования). Во флаттере это не просто технически более гибкое решение — это своего рода философия, которая лежит в основе всего фреймворка.
Как избежать ошибки? Ну, собственно, не делать как делал я:
1. Не писать виджетов с модификатором abstract
2. Не делать extends ни от каких виджетов, кроме базовых Stateful/Stateless
У этих правил есть несколько исключений, но в подавляющем большинстве случаев они не нужны. Когда-нибудь напишу про них отдельно.
Если нужны детали и причины, то вот несколько ссылочек:
1. Про композицию в доке флаттера
2. Кусочек из видео 6-летней давности про эту философию
3. Можно загуглить фразу "Composition over inheritance", там много материалов помимо флаттера
P.S. Я хоть и немного загружен в последнее время, но про канал не забываю, и уже есть несколько черновиков, о чём бы ещё хотел рассказать — так что не теряйте.
👍16❤5🔥4😈2💩1