Это четвертая часть моей серии про архитектуру Flutter:
Хотя 2 предыдущие части явно не относились к паттерну RxVMS, они были необходимы для ясного понимания этого подхода. Теперь мы обратимся к самом важным пакетам, которые понадобятся, чтобы использовать RxVMS в вашем приложении.
Добро пожаловать — это третья часть моей серии статей об архитектуре Flutter.
На этот раз мы совершим небольшое погружение в магическое царство реактивных расширений (Rx). Я сосредоточусь на наиболее используемых функциях Rx и объясню их применение. Если вы не читали предыдущий пост, сейчас для этого самое время, прежде чем двигаться дальше.
RxDart — это реализация концепции Rx для языка Dart, за что следует сказать спасибо Frank Pepermans и Brian Egan. Если ранее вы использовали Rx в других языках, то наверняка заметите разницу в именовании ряда функций, но это вряд ли вызовет у вас затруднения.
Код для тестирования находится здесь.
До сих пор мы использовали потоки как способ передачи данных из одного места в другое в нашем приложении, но они могут сделать гораздо больше. Давайте взглянем на некоторые функции, которые Rx добавляет в Streams.
Это вторая часть моей серии по поводу Flutter Architecture:
Потоки являются основным строительным блоком RxVMS, их понимание является абсолютно необходимым условием для работы с этой библиотекой, так что мы подробнее остановимся на них в этом посте.
Оказалось, что включение Rx в этот пост сделало бы его слишком длинным, поэтому я разделил его на две части.
Я читаю множество комментов, что дескать потоки, и особенно Rx, слишком сложны для понимания и, как следствие, для использования.
Мне бы хотелось, чтобы вы знали, что я не считаю себя гуру Rx. Освоить всю мощь его нелегко, и я признаю, что продолжаю учиться. Но позвольте мне с самого начала исправить одно заблуждение: вам не нужно быть волшебником Rx, чтобы начать получать массу преимуществ от использования потоков и этой технологии. Я приложу максимум усилий, чтобы объяснить вам потоки наиболее доступным образом.
Это первый пост из серии публикаций, в которых объясняется мое понимание архитектуры приложений для Flutter. Предупреждаю — это будет весьма самоуверенным.
Пока запланированы:
Я в программировании уже около 20 лет. Начал мобильную разработку 4 года назад с Xamarin.Forms, ибо кроссплатформенность была единственной побудительной причиной для меня в качестве инди-разработчика. Xamarin.Forms буквально толкают тебя к использованию паттерна MVVM, так как определение UI ведется в XAML, и тебе необходим какой-то слой, чтобы склеивать UI с Моделью. В процессе работы с Xamarin я познакомился с ReactiveUI и был буквально покорен потоками и реактивными расширениями (Rx), сделавшими мои приложения более надежными.
В то время, как в Xamarin.Forms MVVM были "из-коробки", при переходе к Flutter я был удивлен, что в нем не было никаких похожих шаблонов проектирования. Я начал исследовать различные предлагаемые подходы, но ничего из имеющегося не удовлетворило меня в полной мере:
В конце 2018 года Google, не без помощи Open-Source сообщества, сделал большой подарок для мобильных разработчиков, выпустив первую стабильную версию кросс-платформенного фреймворка для мобильной разработки Flutter.
Однако, при разработке крупных приложений, немного больших, чем одностраничные 'Hello World'ы, разработчики могли столкнуться с проблемой неопределенности. Как стоит писать приложение? Фреймворк достаточно молод, ещё не существует достаточной базы хороших примеров с открытым кодом, основываясь на которых можно было бы понять плюсы и минусы применения различных паттернов, понять что стоит использовать в данном конкрентном случае, а что — нет.
Спасает ситуацию то, что Flutter имеет определенную степень схожести с React и React Native, а значит можно перенять некоторый опыт программирования на последних. Возможно, именно из-за этого появились такие библиотеки, как Flutter Flux, Flutter Hooks, MobX, а также сразу несколько реализаций Redux. Долгое время самой популярной была версия Брайана Игана под названием Flutter Redux.
Тем не менее, пару месяцев назад первый коммит увидела библиотека Fish Redux, опубликованная под именем компании Alibaba. Библиотека за короткое время собрала большую популярность, уже на первом дне обогнав реализацию Брайана по количеству звезд, а на втором опередив её в два раза.
Параметр key можно найти практически в каждом конструкторе виджета, но используют этот параметр при разработке достаточно редко. Keys сохраняют состояние при перемещении виджетов в дереве виджетов. На практике это означает, что они могут быть полезны для сохранения местоположения прокрутки пользователя или сохранения состояния при изменении коллекции.
Данная статья адаптирована из следующего видео. Если вы предпочитаете слушать / смотреть, а не читать, то видео предоставит вам тот же материал.
В первой части мы выяснили зачем нужна кодогенерация и перечислили необходимые инструменты для кодогенерации в Dart. Во второй части мы узнаем как создавать и использовать аннотации в Dart, а также как использовать source_gen и build_runner, чтобы для запуска кодогенерации.
Известно, что для программиста очень хорошо быть ленивым, потому что делать больше с меньшими затратами — ключ к прогрессу. Никто не любит делать одно и то же снова и снова. Это утомительно, скучно, да и совсем не креативно. Повторяя одно и то же действие мы часто делаем ошибки, но, к счастью, есть те, кто действительно хорош и эффективен в выполнении однотипных задач. И это КОМПЬЮТЕРЫ!
На сегодняшний день кодогенерация это возможность сделать работу за наименьший промежуток времени. Основная идея проста: найти закономерность в однотипных и утомительных участках кода, которые приходится писать снова и снова, создать инструмент для генерации, запустить его и увидеть, как происходит волшебство!
В мире Android разработки такие инструменты хорошо известны каждому разработчику. Это и Retrofit, и Dagger, и Room. А как насчет Dart? И не менее важный вопрос: что нам нужно, чтобы создавать собственные инструменты для кодогенерации?
Сколько времени занимает проверка гипотезы для мобильного приложения? Давайте посчитаем:
Если ваши разработчики работают по Scrum с двухнедельными итерациями, обычно это означает, что тестирование гипотезы занимает полный месяц. С другими методологиями этот срок можно ужать, но незначительно.
Такое положение дел делает невозможным достижение ритма “5 гипотез в неделю”, к которому стремятся многие продуктовые команды.
Ниже я расскажу, как можно ускорить и улучшить этот процесс и укажу ряд готовых решений, которые можно использовать.
Поехали.
Возможность задействовать камеру существует во многих приложениях, и мы все регулярно пользуемся ею. Во Flutter мы можем реализовать работу с камерой с помощью двух официальных плагинов:
Между ними – заметная разница, и использовать их стоит по ситуации:
camera позволяет взаимодействовать с доступными устройству камерами из вашего приложения и выводить изображение в виджет. Хорошо подходит под задачи, когда надо "кастомизировать" работу камеры под приложение.image-picker запускает приложение камеры и возвращает объект типа File (изображение или видеофайл, выбранный пользователем) в ваше приложение. Также image-picker дает возможность выбора файла из имеющихся на устройстве, при этом, как и в случае камеры, запускается отдельное приложение, после чего в ваше приложение возвращается выбранный объект.Здесь можно посмотреть исходники.
Причем для последней ОС – Fuchsia – это пока единственный способ создать приложение.
Flutter на протяжении долгого времени, с 2015 года, был представлен только в альфа и бета версиях. Релиз первой стабильной версии состоялся 4 декабря 2018 года.
Flutter активно продвигается Google, постепенно набирает популярность и, скорее всего, в дальнейшем будет теснить другие, используемые сейчас средства кроссплатформенной разработки (React Native, Xamarin), особенно при условии широкого распространения Fuchsia. С учетом того, что Google позиционирует данную операционную систему как замену Android, рано или поздно Flutter вытеснит нативную разработку под Android. Поэтому перспективность и активное развитие – основные плюсы Flutter.
В данной статье речь пойдет о реализации мобильного клиента Flutter.
Какого именно мобильного клиента?
В предыдущей публикации описана система программных аксессуаров:
bobaoskit — аксессуары, dnssd и WebSocket.
Аналог программного аксессуара — реальный объект. Лампочка, переключатель, cd/кассетный проигрыватель, радио плеер, термостат, датчик температуры, датчик движения и т.д… Набор аксессуаров определяется фантазией и программным кодом. Можно реализовать хоть шахматную доску. Для такой доски надо иметь поле управления(control) move, принимающее объект { from: "e2", to: "e4" } для примера и сервисные поля для сброса фигур и т.д… Скрипт аксессуара обработает запрос на управление полем move, примет решение можно ли перемещать фигуру, и вернет(или нет) статус с положением фигур на всем поле.
На текущий момент поддерживаемые типы аксессуаров с минимальным функционалом следующие: "switch", "temperature sensor", "thermostat", "radio player".
Про шахматы далее речи не пойдет. Если интересно и в таком случае, добро пожаловать под кат.
Совсем недавно я открыл для себя Flutter – новый фреймворк от Google для разработки кроссплатформенных мобильных приложений – и даже имел возможность показать основы Flutter человеку, который никогда не программировал до этого. Сам Flutter написан на Dart – языке, родившимся в браузере Chrome и сбежавшим в мир консоли – и это навело меня на мысль "хм, а ведь Flutter мог вполне бы быть написан на Go!".
Ведь почему нет? И Go и Dart созданы Google, оба типизированные компилируемые языки – повернись некоторые события чуть иначе, Go был бы отличным кандидатом для реализации такого масштабного проекта, как Flutter. Кто-то скажет – в Go нет классов, дженериков и исключений, поэтому он не подходит.
Так давайте представим, что Flutter уже написан на Go. Как будет выглядеть код и вообще, получится ли это?
