Привет, это Катя, Flutter Dev Friflex. Сейчас расскажу про три решения: Bloc, Riverpod и yx_scope, и еще немного про альтернативные подходы.

Bloc
Bloc — это предсказуемый state-менеджмент, основанный на концепции Unidirectional Data Flow (однонаправленный поток данных).

Основные концепции
Events — действия, которые триггерят изменения
States — иммутабельные объекты, описывающие состояние приложения
Bloc — класс, который обрабатывает Events и эмитит States

Плюсы
◽️Четкое разделение логики и UI
◽️Хорошая документация и большое сообщество
◽️Поддержка Cubit (упрощенная версия Bloc)

Минусы
◽️Высокая шаблонность (много повторяющегося кода)
◽️Избыточность для простых сценариев — если состояние приложения простое, Bloc может быть слишком мощным

Пример использования

class CounterBloc extends Bloc<CounterEvent, int> {
  CounterBloc() : super(0);

  @override
  Stream<int> mapEventToState(CounterEvent event) async* {
    if (event is Increment) yield state + 1;
    if (event is Decrement) yield state - 1;
  }
}

Riverpod
Riverpod — это улучшенная версия Provider, созданная тем же автором (Remi Rousselet). Он решает проблемы Provider (например, Null safety и тестируемость).

Основные концепции
Provider — источник данных (может быть StateProvider, FutureProvider или другой)
Consumer — виджет, который читает провайдер
AutoDispose — автоматическая отписка от провайдеров

Плюсы
◽️Нет зависимости от BuildContext
◽️Лучшая поддержка тестирования
◽️Гибкость (можно использовать как DI или state-менеджмент)

Минусы
◽️Неочевидная работа с асинхронностью — AsyncValue требует дополнительной обработки ошибок и загрузки
◽️Меньше документации по сравнению с Bloc

Пример использования

final counterProvider = StateProvider<int>((ref) => 0);

class CounterWidget extends ConsumerWidget {
  @override
  Widget build(BuildContext context, WidgetRef ref) {
    final count = ref.watch(counterProvider);
    return ElevatedButton(
      onPressed: () => ref.read(counterProvider.notifier).state++,
      child: Text('Count: $count'),
    );
  }
}

yx_scope
yx_scope — это легковесная библиотека для управления состоянием, вдохновленная ScopedModel и InheritedWidget.

Основные концепции
Scope — контейнер для состояния
InheritedScope — автоматически обновляет виджеты при изменении состояния

Плюсы
◽️Простота использования.
◽️Хорошо подходит для небольших приложений.
◽️Низкая шаблонность (минимум повторяющегося кода).

Минусы
◽️Меньше возможностей, чем у Bloc/Riverpod.
◽️Меньше документации
◽️Плохая масштабируемость — в больших проектах библиотека может стать непредсказуемой

Пример использования

class CounterScope extends Scope {
  var count = 0;
  void increment() => notifyListeners(count++);
}

class CounterPage extends StatelessWidget {
  @override
  Widget build(BuildContext context) => TextButton(
    onPressed: CounterScope.of(context).increment,
    child: Text('Count: ${CounterScope.of(context).count}'),
  );
}

Добавляю в комментарии табличку сравнений state-менеджментов. Давайте обсудим!

Всем привет! С вами Анна, Friflex Flutter Team Lead.

Любой Flutter-разработчик, создавая свой первый проект задавался хоть раз вопросом — с чего начать, что делать и, главное, как упростить себе работу? Сегодня разберу основные шаги, которые позволят подготовить базу.

1 шаг. Создание проекта
Здесь все очень просто - создать проект можно всего одной командой через терминал. Достаточно выполнить:

flutter create new_app

Вуаля! Проект с названием new_app создан и готов к работе. С помощью дополнительных опций можно конфигурировать проект. Например, опция --empty создаст его пустым, без шаблонов.

О других вариантах можно прочитать здесь.

2 шаг. Настройка запуска приложения
Все знают: чтобы запустить Flutter-проект, достаточно вызвать метод main() и запустить функцию runApp() с виджетом приложения внутри. Здесь вы также можете выполнять любые настройки, которые потребуются перед запуском вашего приложения — например, устанавливать ориентацию экрана и базовую локализацию.

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

Здесь нужно инициализировать FlutterError.onError и PlatformDispatcher.instance.onError, указать, как именно приложение должно реагировать на ошибки фреймворка и платформы.

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

3 шаг. Настройка флаворов
Здесь на помощь вам придет библиотека flutter_flavorizr.

Подключаете пакет в зависимости вашего приложения, а дальше дело за малым — по примеру из документации нужно указать, какие именно флаворы необходимы, какое название и bundleId должно иметь приложение и какие плаформы оно будет поддерживать:

flavorizr:
  flavors:
    prod:
      app:
        name: "New App"
      android:
        applicationId: "com.example.prod"
      ios:
        bundleId: "com.example.prod"
    dev:
      app:
        name: "New App Dev"
      android:
        applicationId: "com.example.dev"
      ios:
        bundleId: "com.example.dev"

Далее остается только запустить кодогенерацию.

flutter pub run flutter_flavorizr

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

4 шаг. Реализовать DI
Здесь конкретных рекомендаций нет, каждый разработчик самостоятельно выбирает подход — можно сделать самописную реализацию, без кодогенерации и сторонних библиотек, можно интегрировать самые популярные пакеты, например, get_it и injectable.

Flutter тоже дает свое видение DI, можно ознакомиться с ним в документации.

5 шаг. Интегрировать роутер
Именно на этом этапе, когда в приложении нет как таковых экранов, удобно продумать подход к роутингу в проекте. В зависимости от подхода можно использовать как навигацию из коробки, так и сторонние библиотеки.

Наиболее популярные и стабильные — go_router и auto_route. Если есть необходимость и желание попробовать полноценный декларативный подход — вам подойдет octopus.

Готово! Приложение полностью подготовлено к написанию самой первой фичи.

В идеале на этом этапе настроить тему приложения и текстовые стили по дизайну, создать глобальные виджеты или даже целый UI kit, настроить http-клиент для управления запросами. Но все эти пункты зависят от вашего проекта, поэтому в основную последовательность не включаем.

Делитесь, каким было ваше первое приложение?

Привет, это Катя, Flutter Dev Friflex.

При разработке на Flutter важно не просто уметь писать рабочий код, но и понимать, как работает язык Dart, на котором он основан. Одна из базовых тем — ключевые слова final, const и var. Они отвечают за то, как переменные создаются и ведут себя в процессе выполнения программы. Давайте разберем и повторим базу😁

var (переменная)

Используется для объявления переменной, значение которой может изменяться со временем. Тип переменной определяется автоматически при присвоении значения. Но после первого присвоения типа, переменная не может быть использована с другим типом данных.

Пример:

void main() {   
   var name = 'Alice';  // Тип определяется как String   
   print(name);  // Alice      
   name = 'Bob';  // Допустимо, так как тип остаётся String   
   print(name);  // Bob 
}

Если тип данных переменной var известен при создании, Dart сам выводит тип переменной (например, String, int и т.д.).
Переменная, объявленная с var, может изменять свое значение, но не тип.

Пример попытки изменить тип переменной:

var age = 30; age = "thirty";  // Ошибка: String нельзя присвоить переменной типа int.

​​
final (константа во время выполнения)

Используется для переменных, значение которых можно установить только один раз. После инициализации переменной значение нельзя изменить. В отличие от const, переменная с final может быть инициализирована значением, которое становится известно только во время выполнения программы.

Пример:

void main() {   
    final name = 'Charlie';  // name будет неизменяемым   
    print(name);  // Charlie    
    name = 'Dave';  // Ошибка, нельзя изменить значение переменной 
}

final используется для значений, которые известны только во время выполнения программы.

Пример использования переменной, которая зависит от выполнения программы:

void main() {   
    final currentTime = DateTime.now();  // Значение определяется во время выполнения   
    print(currentTime); 
}

В этом примере время будет определено при выполнении программы и больше не изменится.

const (константа времени компиляции)

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

Пример:

void main() {   
    const pi = 3.1415;   
    print(pi);  // 3.1415   
    pi = 3.14;  // Ошибка, нельзя изменить значение константы 
}

◽️Переменные, объявленные с const, являются неизменяемыми и создаются во время компиляции программы.

◽️Если переменная const имеет сложный тип (например, список), то она становится полностью неизменяемой (не только ссылка, но и сам объект).

Пример со списком:

void main() {   
    const numbers = [1, 2, 3];   
    // numbers[0] = 10;  // Ошибка, элементы списка изменить нельзя
    print(numbers); 
}

Различия между final и const
▫️final позволяет установить значение переменной один раз, но это значение может быть вычислено во время выполнения программы.
▫️const требует, чтобы значение было известно на этапе компиляции.
▫️const можно использовать для создания неизменяемых объектов, которые становятся доступными еще до выполнения программы, в отличие от final.

Пример разницы:

final currentTime = DateTime.now();  // Работает, так как значение вычисляется во время выполнения. 
const timeConst = DateTime.now();  // Ошибка: const переменные не могут быть вычислены во время выполнения.

Итоговое сравнение:
▪️var — изменяемая переменная, тип выводится автоматически.
▪️final — неизменяемая переменная, значение можно присвоить один раз, но это может произойти во время выполнения.
▪️const — неизменяемая переменная, значение которой должно быть известно во время компиляции.

Привет, с вами вновь Катя, Flutter Dev Friflex.

Сегодня поговорим про библиотеку equatable, которая помогает упростить сравнение объектов.

Установка

Yaml
dependencies:
  equatable: ^2.0.7

Зачем нужна библиотека?
В Dart по умолчанию два объекта считаются равными, только если они ссылаются на один и тот же экземпляр в памяти. Но часто требуется сравнивать объекты по их полям. Equatable автоматически реализует методы == (оператор равенства) и hashCode, что избавляет разработчиков от написания шаблонного кода.

Без Equatable:

class Person {
  Person(this.name, this.age);

  final String name;
  final int age;
  
  @override
  bool operator ==(Object other) {
    if (identical(this, other)) return true;
    return other is Person && 
           other.name == name && 
           other.age == age;
  }

  @override
  int get hashCode => name.hashCode ^ age.hashCode;
}

С Equatable:

import 'package:equatable/equatable.dart';

class Person extends Equatable {
  Person(this.name, this.age);

  final String name;
  final int age;
  
  @override
  List<Object?> get props => [name, age]; // Поля для сравнения
}

Основные возможности
▫️Equatable переопределяет == и hashCode на основе списка полей (props)
▫️Можно использовать Equatable в иерархии классов
▫️Рекомендуется использовать с неизменяемыми (final) полями
▫️Часто применяется в State Management для эффективного сравнения состояний

Использование EquatableMixin
Если ваш класс уже наследуется от другого класса, но вам нужна функциональность Equatable, можно использовать

EquatableMixin:

import 'package:equatable/equatable.dart';

class Person extends SomeOtherClass with EquatableMixin {
  Person(this.name, this.age);
 
  final String name;
  final int age;
  
  @override
  List<Object?> get props => [name, age];
}

Преимущества EquatableMixin
▫️Позволяет добавить сравнение объектов без изменения иерархии наследования
▫️Сохраняет все возможности Equatable, но в виде миксина

Пример использования

void main() {
  final person1 = Person("Alice", 30);
  final person2 = Person("Alice", 30);

  print(person1 == person2); // true (без Equatable было бы false)
}

📎 Ссылка на библиотеку

❤️ — если используете Equatable в ваших проетах

Привет, это Роза, Flutter Dev Friflex! 👋

Рано или поздно в вашем проекте может возникнуть задача — получить скриншот конкретного виджета. Как это реализовать?

Существует несколько подходов:
▪️Готовое решение — например, пакет screenshot
▪️Более низкоуровневый подход — через RenderRepaintBoundary
    
💡Интересный факт: внутри себя screenshot использует RenderRepaintBoundary, поэтому понимание его работы будет полезным даже при использовании готового пакета.

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

1. Создаем глобальный ключ
Он нужен, чтобы получить доступ к RenderRepaintBoundary:

final GlobalKey _widgetKey = GlobalKey(); 

2. Оборачиваем нужный виджет в RepaintBoundary
Это гарантирует, что будет захвачен только нужный виджет.

RepaintBoundary(
  key: _widgetKey,
  child: const SomeWidget(),
)

3. Захватываем изображение
Метод, который преобразует виджет в Uint8List:
 

Future<void> _captureAndSave(BuildContext context) async {
  try {
    // Получаем рендер-границу по ключу
    final boundary = _widgetKey.currentContext!.findRenderObject() as RenderRepaintBoundary;

    // Захватываем изображение (можно увеличить pixelRatio для лучшего качества)
    final image = await boundary.toImage(pixelRatio: 3.0);

    // Преобразуем изображение в байты
    final byteData = await image.toByteData(format: ui.ImageByteFormat.png);
    final pngBytes = byteData!.buffer.asUint8List();

    // Тут можно сохранить файл.
    ...
  } catch (e) {
    debugPrint('Ошибка при захвате: $e');
  }
}

Вот и все! Теперь у нас есть изображение в виде байтов (Uint8List), с которым можно делать все, что угодно:
✔️сохранить в файл
✔️передать по сети
✔️вложить в PDF
✔️отобразить в UI

 🧠 Немного теории:
RepaintBoundary – важный инструмент для оптимизации производительности. Он создает «графическую границу», отделяя часть дерева виджетов от остального. Это позволяет:
▫️изолировать перерисовки
▫️ повысить производительность
▫️ использовать offscreen rendering
▫️ делать захват изображения (как в нашем примере)

Ставьте ❤️ — и в следующем посте глубже рассмотрим RepaintBoundary: как он работает,  влияет на рендеринг и какие у него есть особенности

Привет, с вами вновь Катя, Flutter Dev Friflex. Сегодня разберем основные способы декомпозиции и лучшие практики.

Декомпозиция виджетов — это процесс разделения сложного виджета на более простые и независимые компоненты.

Зачем это нужно?

▫️ Упрощение кода: когда разделяешь виджеты на более мелкие компоненты, код становится более понятным и легким для восприятия
▫️ Повторное использование: мелкие виджеты можно использовать в разных частях приложения, что снижает дублирование кода
▫️ Улучшение производительности: использование отдельных виджетов позволяет более эффективно управлять состоянием и перерисовкой интерфейса
▫️ Тестируемость: мелкие виджеты легче тестировать, что способствует созданию более надежного кода

Виды декомпозирования
1. Использование билд-методов
Вынесение частей виджета в отдельные методы внутри того же класса.

class ProductCard extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return Card(
      child: Column(
        children: [
          _buildTitle(),
          _buildPrice(),
        ],
      ),
    );
  }

  Widget _buildTitle() { ... }
  Widget _buildPrice() { ... }
}

✅ Маленький плюсик:
Мало кода — не требует создания новых классов

❌ Минусы:
▫️Нет переиспользуемости — методы привязаны к конкретному виджету
▫️Сложность тестирования — нельзя протестировать отдельно от родителя
▫️Риск создания «метод-супов» — чрезмерное количество методов ухудшает читаемость
▫️Ухудшает производительность — каждый setState в таком методе будет полностью перерисовывать виджет

2. Разделение на Stateful и Stateless виджеты
Выделение логики с состоянием в отдельные StatefulWidget, а статичной верстки — в StatelessWidget.

// Stateful часть
class Counter extends StatefulWidget {
  @override
  _CounterState createState() => _CounterState();
}

class _CounterState extends State<Counter> {
  int count = 0;
  
  void increment() => setState(() => count++);

  @override
  Widget build(BuildContext context) {
    return CounterView(
      count: count,
      onIncrement: increment,
    );
  }
}

// Stateless часть
class CounterView extends StatelessWidget {
  // Логика
}

        
✅ Плюсы:
▫️Четкое разделение ответственности — состояние отделено от представления
▫️Упрощенное тестирование — Stateless-часть можно тестировать без состояния
▫️Повышенная производительность — Stateless-виджеты не перестраиваются без необходимости
▫️Гибкость — можно менять состояние без изменения UI и наоборот

❌ Минусы:
Больше кода — требуется создание дополнительных классов

Если заметили, то плюсы и минусы у этих вариантов противоположны.

📎Есть классное короткое видео от Flutter-команды, рекомендую посмотреть его.

Всем привет! Это Анна, Friflex Flutter Team Lead👋

Сегодня затронем еще одну тему, которая в сообществе разработчиков всегда вызывает бурные обсуждения. Поговорим о документации и комментировании кода: насколько это необходимо и каких правил стоит придерживаться.

Для начала разберемся, чем отличается документация от комментария в коде.

▫️Документация — это характеристика конкретного объекта, класса, метода, описание его назначения, параметров и механики работы. Оформляется в коде через ///. Например, возьмем школьную задачку — надо написать метод, который по значениям катетов прямоугольного треугольника будет рассчитывать значение гипотенузы.



/// Метод для вычисления гипотенузы по известным значениям
/// катетов прямоугольного треугольника
///
/// Принимает:
/// - [firstLeg] - первый катет прямоугольного треугольника
/// - [secondLeg] - второй катет прямоугольного треугольника
double calculateHypotenuse(double firstLeg, double secondLeg) {
  final hypotenuse = sqrt(firstLeg * firstLeg + secondLeg * secondLeg);

  return hypotenuse;
}



Если мы добавим этот пример в любую IDE, при наведении мышью на метод будет высвечиваться наша добавленная документация. При этом специальные знаки помогают удобно форматировать описание. Например, квадратные скобки позволяют обозначить параметр, а дефисы — организовать маркированный список.

▫️Комментарий — это обычное словесное описание алгоритма действий. Если в коде встречается сложный участок, где логика не совсем очевидна, или имеются какие-то важные сведения, которые разработчик хочет передать своим коллегам и себе в будущее, оформлять их стоит именно как комментарий. Они выделяются с помощью //.

Как показывает практика, и документация, и комметрирование кода — очень удобные инструменты, которые позволяют сделать проект максимально понятным и простым для вхождения новых разработчиков.

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

Как это исправить?
Поможет соответствие ряду правил.

1. Зафиксировать в проекте порядок комментирования и документации кода.
Очень удобно на уровне всей команды заранее определить шаблоны. В будущем это позволит держать весь проект в едином формате.

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

3. Не комментировать лишнее.
Такая ошибка часто встречается, что вызывает негатив к комментированию в целом. Важно покрывать комментариями только то, что действительно нуждается в пояснении. Например, переменные с говорящими названиями или простые условия в блоке if описывать смысла нет.

4. Больше текста — не значит лучше.
Документация и комментарии должны быть емкими, простыми для восприятия. Если текста будет слишком много, вероятность, что его будут пропускать, увеличивается.

💬Делитесь своим опытом и лучшими практиками в комментариях.