Программист
Случается, что связку .obs/Obx критикуют за нарушение инкапсуляции и за прямой доступ к изменению переменной из View минуя Model. Статья описывает подход к устранению этого недостатка и к реализации Unidirectional Data Flow поверх Rx-переменных библиотеки GetX с помощью паттерна Decorator.
GetX удобен. Действительно удобен, лаконичен, функционален, выразителен. Но порою его функционала не хватает. В частности, речь об инжектировании контроллеров -Get.put/lazyPut/create/find - вот это все. Данная схема отлично работает в контексте навигации между страницами. Но не работает, например, в страницах PageView, или же при конструировании Get.bottomSheet. Ниже предлагается решение для этих случаев.
В отношении политики AWS не может быть никаких претензий, конечно. Все нижеописанное случилось по собственному ротозейству. Мы же вас предупреждали, незнание законов, и т.п.
Эта короткая публикация о том, что нужно очень внимательно относиться к лицензиям и правилам использования облачных служб и инструментов.
Yesterday my friend said something like "I’m writing simple offline app, I don’t need these streams and all that jazz". I was confused, but I thought, that there may be other coders in this delusion.
Below, literally in 50 lines I will show, on known example that reactivity is:
a) not about offline/online
b) very easy
c) very good for simplifying almost any code
Вчера мой хороший товарищ сказал что-то типа "я же пишу простяцкое оффлайн приложение, мне ни к чему все эти стримы и потоки". Я даже растерялся, а потом подумал, что это заблуждение могут разделять и другие кодеры.
Ниже буквально в 50 строк я на известном примере покажу, что реактивность
а) это не про оффлайн/онлайн
б) это очень просто
в) очень хороша для упрощения практически любого кода
Про локализацию (интернационализацию) приложений Flutter написано уже достаточно много.
Официальная документация довольно подробно останавливается на этом вопросе, кроме этого ряд энтузиастов описывает самые различные подходы.
Эта статья не претендует на полноту охвата вопроса, а является описанием практики, на мой взгляд, очень эффективно уменьшающей ручной ввод.
Речь идет о локализации при помощи flutter_i18n — плагина Android Studio, используя который удается избавиться от рутинной работы и шаблонного кода.
Это четвертая часть моей серии про архитектуру 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 я был удивлен, что в нем не было никаких похожих шаблонов проектирования. Я начал исследовать различные предлагаемые подходы, но ничего из имеющегося не удовлетворило меня в полной мере:
В конце прошлого года мне потребовался undo/redo инструмент для Java-проекта, который, помимо стандартных для этого концепта задач, умел бы сохранять историю команд и корректно обрабатывать привязку к меняющемуся адресному контексту (это с прицелом на мой готовящийся проект для Android и его регулярное пересоздание вьюшек). Поискал, не нашел, взялся.
Результатом стала библиотека JUndo.