*Знаешь почему стоит пойти ко мне учиться?* *Не сложно!* 👇 Я лично обучаю и делаю это «простым и доступным языком», тебе будет понятно всё что необходимо *Не долго!* 👇 Ты легко освоишь навык разработки приложений всего за 2 месяца *Не дорого!* 👇 Стоимость обучения в разы меньше по сравнению с остальными курсами Flutter (стоимость уточнить можно в ЛС) *Нужно немного твоего времени!* 👇 Каждую субботу будет наш созвон в Zoom и всего на 2 часа (созвон всего лишь раз в неделю) *С домашним заданием!* 👇 Ты будешь получать домашнее задание которое надо выполнить в течении недели и я лично буду проверять ДЗ и давать комментарий *С практикой!* 👇 Ты сделаешь учебный проект и получишь задание делать свое собственное приложение *Не скучно!* 👇 На созвоне я всегда всех призываю активничать и перебивать меня, я всегда хочу получать вопросы и тут же отвечать на них *Перспективно!* 👇 Выпускников я зову на свой практикум, где мы вместе будем делать бизнес на приложениях (зарабатывать на продаже премиум подписках в приложениях) *Остались вопросы?* Ниже контакты, просто напиши мне! Telegram: t.me/stolets WhatsApp, Viber, SMS: +7 (908) 505-49-41 +7 (908) 505-49-41 +7 (908) 505-49-41 (на обычный звонок не отвечаю, по причине частого спама) Vk: vk.com/stolets Instagram: instagram.com/sto_lets Email: ip.stolets@yandex ru
Отличный вопрос. Насколько я понял, для провайдера необходимо иметь разные типы для каждого конкретного провайдера. Если есть одинаковые типы, он будет возвращать первый. Решить эту проблему можно легко, просто создать класс для отдельного вида данных. Но по логике, в провайдере лучше поставлять модели данных, отдельные классы.
@@stolets Provider( create: (context) =>[a,b], ... На другой странице: child: Text(${'Provider.of(context)[1]}'), ... Выведет значение b. Примет любой типизированный массив. На dynamic захлебнётся.
Спасибо за ясный пример :) Если мы хотим вернуться к предыдущим экранам по навигации, восстанавливая отображаемые данные (в полях ввода, например), нужно использовать только провайдер?
@@stolets но получается, что если мы в класс запихнем 50 переменных int и будем провайдить класс, то при изменении любой переменной внутри класса будут срабатывать все ребилды, связанные со всеми этими переменными... А это не выглядит оптимально... Я правильно понимаю?
Спасибо! Очень понятный и качественный видео урок. Читала несколько артиклей, особо не вникала в суть. А теперь стало все понятно. Продолжайте в том же духе🤩😊
В данном примере при нажатии на кнопку изменения температуры перерисовывается весь виджет страницы. Было бы правильней поместить context.watch() и Text в Builder, чтобы перерисовывался только сам Text со значением температуры: Builder( builder: (context) { final temp = context.watch(); return Text( temp.temperature.toString(), style: Theme.of(context).textTheme.headlineMedium, ); }, ),
Лайк и коммент в поддержку канала) Сейчас появилась необходимость побыстрому разобраться в основах флаттера и видосы нормально зашли) Конечно сильно все упрощенно, но как я понял на этом и был акцент чтобы даже совсем начинающие разобрались что да как.
Если провайдер - это только поставщик, то есть, класс, посредством которого "прокидываются" данные, то что мешает объявить глобальную переменную, в которую внести все нужные для передачи данные и получить их в любом другом модуле, в любом другом классе, не заморачиваясь с многострочными вызовами чтения тех же глобальных данных?
@@stolets по хорошему для изменяемых элементов нужно создавать отдельный виджет, как пример виджет сердечка like, что бы при изменении не перерисовывать всю странцу(либо виджет айтема( товара)), а только виджет не посредственно с сердечком
@@stolets ну судя по видео скорее всего хомескрин обновляется, а не виджет текст, так как сначала ты напрямую прописал вызов в чилд текста, а потом вынес в переменную, результат не изменился, исходя из этого делаем вывод что все таки обновляется тот виджет где мы обращаемся к провайдеру
Provider не нужен. Есть встроенные во флаттер InheritedWidget и InheritedNotifier. Почему народ не желает изучить как следует сам флаттер и его возможности, а сразу спрыгивает на сторонние пакеты? Удивительно!
Сложную, масштабируемую бизнес логику очень сложно сделать на provider-е, не говоря уже даже о InheritedWidget. Знать как это работает безусловно стоит, но поверьте, знать хотя бы парочку популярных пекеджей вроде BLoC-а - обязательно.
Поправьте меня если я не прав, но ведь Инхеритед требуют писать больше кода, а готовый пакет Провайдер позволяет уменьшить количество символов, что повышает уровень читаемости , разве нет? Я так понял провайдер сам внутри работает на Инхеритед виджетах, так что не особо понятно зачем лишний раз писать много строк. Как работать знать надо конечно же
@@aleksandrsviridenko5079 Я вам объясню почему я написал такой комментарий. Этот цикл уроков расчитан на начинающих. Провокационное заявление сделано для привлечения пытливых умом разработчиков, чтобы они не торопились, и как следует изучили доступный инструментарий самого флаттера. Понятное дело, что готовый пакет ускоряет разработку, только вот большинство поторопившихся даже не догадывается, что же там "под капотом" у провайдера и на чем основана его работа. По поводу уменьшения символов в коде: разберитесь с ООП и организуйте свой код так, чтобы он работал через взаимодействие компактых легко тестируемых объектов.
