Flutter required что это
Flutter: @required keyword
I don’t really understand how @required works. For example I’ve seen this code:
But what should @required do here? Seems like it makes an optional parameter a non optional parameter.
5 Answers 5
Update
As of Dart 2.12, the required keyword replaces the @required meta annotation. For detailed info look into the official FAQ. The following answer has been updated to reflect both this and null safety.
Parameters required by default
The parameters of a class constructor or function are required by default.
You’re not allowed to do this:
Optional named parameters
If you surround a parameter with curly braces, though, in addition to becoming a named parameter, it also becomes optional.
Since it’s optional, the property must either be nullable like this:
Or it has to have a default value like this:
Required named parameters
Sometimes you don’t want to allow a parameter to be null and there is no natural default variable. In that case you can add the required keyword in front of the parameter name:
This is not ok anymore:
But this is still fine:
Dart 2.12 (null safety):
Beginning with Dart 2.12, the @required annotation is now replaced by the required keyword. You should mark your field required if it is mandatory for others to pass some value to it.
Usage:
@required is an annotation that will create a warning for you to remember that the named parameter is necessary for the class to work as expected. It will not create compile errors, at least for what I know.
@required bounds you to pass @required marked arguments while creating object of Class. For example, while showing a dialog, you’d mark context as required since, you cannot show dialog without having a valid context. But, you should not overuse it.
He could use default value initialization of the parameters instead of ‘required’, if the values were compile-time constants, and that doesn’t seem to be the case here.
Positional parameters can be required or optional, which we pass in order when calling. The following is an example of required positional parameters’ usage:
Named parameters are another type of optional parameters. Flutter APIs use named parameters and in our UI code, it is preferred to use named parameters instead of positional parameters. Reason being readability and clarity when reading code or calling the constructors later on at several parts of the code. You would have seen this as the case with all Widgets, Styles. For if it were to be positional it would be difficult to keep track of them upon calling with the sheer amount of methods that would be in use, and dynamic type inference could also be at work.
NOTE: If exists, required positional parameters have to come first. Either named or optional positional params can follow(NOT BOTH).
Используем Flutter Provider
Передача параметров во Flutter с помощью популярного пакета Provider и организация UserScope.
Большинство приложений использует пакет Provider. Этот пакет рекомендован разработчиками Flutter и насчитывает на момент написания статьи наибольшее число лайков.
Provider является оберткой надо InheritedWidget. Этот пакет позволяет с легкостью использовать InheritedWidget для передачи значений с возможностью подписаться на изменения или получить просто текущее значение.
Используя Provider вам доступны автоматическое создание и освобождение ресурсов, ленивая загрузка (ресурс будет создан только если понадобится), а так же удобные инструменты для упрощения написания кода ваших виджетов.
Виджет Provider имеет конструктор вида:
Параметр lazy по умолчанию равен true. Это означает, что вызов функции create будет происходить лениво, то есть после того, как какой либо виджет запросит значение, а не в момент создания виджета Provider. Если передать значение false, то функция create вызовется в момент создания данного провайдера. Параметр lazy и dispose не обязательны. Вместо child можно использовать builder, об этом чуть ниже.
Данную конструкцию следует использовать только для передачи ресурсов которые будут созданы непосредственно в create.
Если вам необходимо получить ресурс непосредственно в пределах одного контекста, то есть что то вроде:
Такая запись не сработает, так как в данном случае в 4-ой строке будет context из 1-ой строки, который ничего не знает о нашем провайдере. Для этого есть функция builder:
Теперь виджет Text уже создается в контексте из провайдера.
Если вам необходимо передать по контексту уже созданный ресурс, воспользуйтесь записью:
Как и в случае с InheritedWidget, может понадобится создать Scope для какого либо ресурса.
Для получения доступа к ресурсу и подписаться на обновления, можно воспользоваться записью:
Данную запись следует использовать в методе build. Метод build будет перерисовываться, если метод updateShouldNotify вернет true. Данный метод имеет вид:
Если же вам необходимо получить значение в местах, не связаны с отрисовкой, и вам не нужно следить за изменением значения, например в initState или в обработчике нажатия, используйте способы ниже:
Пример из предыдущей статьи но с использованием Provider:
what is the difference between required and @required in flutter. What is the difference between them and when do we need to use them?
If I delete required from the named parameters, it gives me an error:
The parameter ‘color’ // can’t have a value of ‘null’ because of its type, but the implicit default value is ‘null’.
What is the difference between them and when do we need to use them?
2 Answers 2
@required is just an annotation that allows analyzers let you know that you’re missing a named parameter and that’s it. so you can still compile the application and possibly get an exception if this named param was not passed.
However sound null-safety was added to dart, and required is now a keyword that needs to be passed to a named parameter so that it doesn’t let the compiler run if this parameter has not been passed. It makes your code more strict and safe.
The @required annotation marks named arguments that must be passed; if not, the analyzer reports a hint.
With null safety, a named argument with a non-nullable type must either have a default or be marked with the new required keyword. Otherwise, it wouldn’t make sense for it to be non-nullable, because it would default to null when not passed.
When null safe code is called from legacy code the required keyword is treated exactly like the @required annotation: failure to supply the argument will cause an analyzer hint.
When null safe code is called from null safe code, failing to supply a required argument is an error.
What does this mean for migration? Be careful if adding required where there was no @required before. Any callers not passing the newly-required argument will no longer compile. Instead, you could add a default or make the argument type nullable.
Flutter + чистая архитектура: разбираем на примере
Обычно приложение состояло из четырёх слоев:
Создание проекта
Создать проект можно с помощью инструментов вашей любимой IDE или из командной строки. В последнем случае вы должны выполнить в терминале команду:
Получилась следующая структура каталогов:
Содержание файлов main.dart, application.dart и home.dart можно посмотреть под спойлерами.
На данном этапе приложение должно успешно собираться, хотя и будет выглядеть как пустой белый экран. Пожалуй, настало время для первого коммита.
Готовим domain
Для нашего приложения мы воспользуемся бесплатным сервисом Sunrise Sunset, который позволяет получить информацию о продолжительности дня и времени восхода/захода солнца в указанной точке.
Мы будем делать запросы к этому сервису и использовать из полученной информации следующие данные:
время, в которое наступает астрономический полдень
Здесь мы определили конструктор с именованными аргументами, а аннотация @required говорит нам о том, что все аргументы являются обязательными.
Дело в том, что методы наподобие fromJson не имеют отношения к бизнес-логике, это всё часть слоя данных. Если описать его здесь, то наша модель превратится в кашу из обращений к мапе, что сильно усложнит понимание структуры модели, а использоваться всё равно будет только в момент получения данных. Поэтому мы вернёмся к этому вопросу, когда займемся слоем данных.
Итак, мы описали модель, теперь нужно поговорить об источнике данных.
Создадим в этой директории файл day_repository.dart следующего содержания:
На данный момент у нас должна получиться следующая структура каталогов:
Пожалуй, можно закоммитить изменения и переходить к слою данных.
Готовим data слой
Итак, давайте создадим в папке api/model файл api_day.dart следующего содержания:
В данном случае мы описали именованный конструктор, который из словаря, возвращаемого бэкендом, по нужным ключам присваивает значения полям модели.
Обратите внимание: в общем случае типы полей этой модели не совпадают с типами модели из domain слоя. Они имеют именно тот тип, который возвращает бэкенд. Для преобразования api-модели в обычную модель, создадим специальный класс-маппер, который будет сопоставлять поля двух моделей и выполнять преобразования при необходимости.
Работаем с API
На верхнем, более абстрактном, мы описываем интерфейс работы с API: набор методов, которые будут использоваться репозиториями для получения данных, и которые обращаются к нижележащему слою для фактического их получения. А заодно выполняет преобразование API-моделей в модели бизнес-логики.
На нижнем слое у нас будет набор классов, которые работают с конкретными сервисами, преобразуют данные слоя бизнес-логики в необходимый для запросов вид (например, json, FormData), выполняют фактические запросы, и обрабатывают полученные результаты. Поскольку этих классов может быть несколько, разумно выделить для них отдельный каталог.
В экосистеме Flutter существует несколько пакетов для работы с сетью, мне больше нравится dio, но вы можете использовать любой другой.
Здесь мы создали объект dio и описали метод getDay, который с помощью этого объекта делает GET запрос к сервису и из полученных данных создает объект ApiDay.
В данном случае я оставил подготовку данных для запроса внутри метода getDay, что не очень хорошо: некоторым запросам требуется довольно много данных, некоторые из них потребуется предварительно преобразовать. Кроме того, этих запросов может быть большое количество, если оставить все так, то файл довольно быстро превратится в мешанину из словарей и методов.
Поэтому давайте вынесем подготовку данных для запроса в отдельный этап.
Готовим данные для запроса
Все наши подобные классы будут называться по шаблону Body и реализовывать метод toAPi для приведения данных к нужному виду.
Теперь мы можем изменить метод getDay в классе SunriseService:
Все методы в этом файле будут содержать в себе всего несколько строк, что облегчит их чтение, когда этих методов станет много.
Нижний слой API реализован, переходим к верхнему. Создадим в каталоге data/api файл api_util.dart :
На этом уровне мы преобразуем данные бизнес-слоя в необходимый сервису вид, выполняем фактический запрос и преобразуем полученные данные в вид, приемлемый для бизнес-слоя.
Фактически, класс ApiUtil служит единой точкой входа в мир API для всех репозиториев, самостоятельно решая, к какому сервису обращаться за данными. Если завтра нам потребуется получать координаты городов из другого сервиса, или погоду из третьего, мы будем решать это на уровнях ApiUtil-ApiServiсe, а для всех репозиториев это будет выглядеть как будто мы получаем все данные из одного источника. В этом и заключается преимущество такого подхода.
Итак, мы подготовили всё необходимое для работы с API, пора переходить к репозиториям.
Готовим репозитории
Ранее мы определили на уровне бизнес-логики интерфейс репозитория DayRepository, теперь мы можем описать его конкретную реализацию. Для этого в каталоге data создадим папку repository и добавим в неё файл day_data_repository.dart со следующим содержанием:
На данном этапе у нас должна получиться такая структура файлов в директории data :
Можно зафиксировать изменения и переходить к следующему слою, на котором мы будем осуществлять внедрение зависимостей.
Внедряем зависимости
Добавим файл repository_module.dart и запишем в него следующий код:
В классе RepositoryModule описываются статические методы, которые для каждого абстрактного репозитория из domain/repository создают объекты-наследники, реализующие методы этих репозиториев.
Прежде чем мы начнём использовать репозиторий для получения информации о продолжительности дня в указанной точке, давайте зафиксируем изменения и подготовим простой UI нашего приложения.
Слой представления
Интерфейс будет очень простым: два поля ввода (для широты и долготы интересующей точки), кнопка для активации запроса и несколько строк текста для отображения результатов. Бедно, но мы ведь здесь не за этим собрались, верно? Никаких проверок валидности введённых данных тоже не будет, чтобы не усложнять код.
После внесения изменений, код экрана стал выглядеть следующим образом:
Обратите внимание на метод _getDay : уже сейчас мы могли бы создать там объект репозитория и получить с его помощью необходимые данные. Однако делать так не стоит: в этом случае экран, находящийся на слое представления, будет явным образом зависеть от объекта из слоя данных.
Если немного подумать, то станет ясно, что реакция на факт нажатия пользователем кнопки должна находиться в ведомстве слоя бизнес-логики. Именно он должен решать, к каким репозиториям обращаться за данными и говорить слою представления, что именно он должен рисовать на экране.
Disclaimer: я не явлюсь специалистом по MobX, поэтому относитесь к моей реализации этого паттерна критически. Дайте знать, если я допустил ошибки.
Управление состоянием с помощью MobX
Итак, для начала нам потребуется добавить необходимые зависимости в наш проект:
Создадим в нём файл home_state.dart с таким содержанием:
В целом он соответствует шаблону из примера по MobX, обсудим некоторые детали.
У меня поначалу всё пошло не очень гладко: скрипт уходил в бесконечный цикл и наотрез отказывался генерировать необходимый файл. В одном из issue к mobx порекомендовали выполнить в этом случае команды
Мне это помогло, после их выполнения предыдущий скрипт завершился успехом.
Добавим в директорию internal/dependencies файл home_module.dart со следующим содержанием:
Внесём изменения в файл presentation/home.dart :
Результат работы приложения представлен ниже.
Итак, мы разработали проект, который следует идеям чистой архитектуры. Такой проект имеет прозрачную структуру слоёв, что уменьшает когнитивную нагрузку и облегчает включение новых участников в проект.
Независимость слоёв также облегчает тестирование приложения.
Наконец, вы всегда можете заменить условный MobX на BLoC, Redux или что там вам по вкусу, и использовать эту архитектуру на полную катушку.
Кодогенерация в Dart. Часть 2. Аннотации, source_gen и build_runner
В первой части мы выяснили зачем нужна кодогенерация и перечислили необходимые инструменты для кодогенерации в Dart. Во второй части мы узнаем как создавать и использовать аннотации в Dart, а также как использовать source_gen и build_runner, чтобы для запуска кодогенерации.
Аннотации в Dart
Как создать свою аннотацию?
Несмотря на то, что идея добавить метаданные к коду звучит немного экзотично и сложно, аннотации – это одна из самых простых вещей в языке Dart. Ранее было сказано, что аннотации просто несут дополнительную информацию. Они похожи на PODO (Plain Old Dart Objects). И любой класс может служить аннотацией, если в нем определен const конструктор:
Как использовать build_runner?
source_gen для понимания Dart-кода
Собираем все вместе: TODO-репорт
В оставшейся части статьи мы будем разбирать проект todo_reporter.dart, который может быть найден здесь.
Существует неписанное правило, которому следуют все проекты, использующие кодогенерацию: необходимо создать пакет, содержащий аннотации, и отдельный пакет для генератора, который использует эти аннотации. Информацию о том, как создать пакет-библиотеку в Dart/Flutter можно найти по ссылке.
Создание todo_reporter, нашего простого пакета с аннотацией
pubspec.yaml очень прост:
В директории lib нужно сделать следующее:
В нашем случае, все, что нам нужно добавить, это аннотация. Давайте создадим файл todo.dart с нашей аннотацией:
Итак, это все, что нужно для аннотации. Я же говорил, что это будет просто. Но это еще не все. Давайте добавим unit-тесты в директорию test :
Это все, что нам нужно для создания аннотации. Код вы можете найти по ссылке. Теперь мы можем перейти в генератору.
Делаем классную работу: todo_reporter_generator
pubspec.yaml выглядит следующим образом:
Теперь мы можем создать файл builder.dart в директории lib :
И файл todo_reporter_generator.dart в директории src :
Метод generateForAnnotatedElement возвращает строку, содержащую наш сгенерированный код. Если сгенерированный код не скомпилируется, то вся фаза сборки потерпит неудачу. Это очень полезно, так как позволяет избежать ошибок в будущем.
Таким образом, при каждой генерации кода наш todo_repoter_generator будет создавать part файл, с комментарием // Hey! Annotation found! В следующей статье мы узнаем, как обрабатывать аннотации.
Собираем все вместе: использование todo_reporter
После получения пакетов ( flutter packages get ) мы можем использовать нашу аннотацию:
Теперь, когда все на своих местах, запустим наш генератор:
Мы добились чего хотели! Теперь мы можем генерировать корректный Dart-файл для каждой аннотации @Todo в нашем коде. Пробуйте и создавайте их сколько потребуется.
В следующей статье
Теперь у нас есть корректные настройки для генерации файлов. В следующей статье мы узнаем как использовать аннотации, чтобы сгенерированный код мог делать по-настоящему классные вещи. Ведь тот код, который генерируется сейчас не имеет особого смысла.