Базар в MVC

Шаблон дизайна поставщика Google преобразован в шаблон дизайна MVC

Я обратился на веб-сайт flutterawesome.com, чтобы найти образец приложения, которое затем внедрил бы в шаблон проектирования MVC. E-Bazaar — замечательный образец приложения, предоставленный Bugudi Ramu, выделяющий множество функций пользовательского интерфейса, доступных во Flutter. С его разрешения я адаптировал шаблон MVC в это приложение, чтобы посмотреть, чем все закончится. Эта статья подробно расскажет об этом опыте. Так получилось, что были введены некоторые дополнительные функции, чтобы подчеркнуть, какие функции доступны в структуре MVC, которые я использовал при преобразовании, — в пример приложения, изначально разработанного для демонстрации возможностей пользовательского интерфейса Flutter.

Просто упражнение

Это было просто упражнение. Я обнаружил, что при разработке приложений с использованием фреймворка MVC я использовал врожденную предвзятость. Видите ли, при создании приложения с нуля у меня была бы тенденция приспосабливать код для работы с фреймворком — я не хочу, чтобы это произошло. Итак, я начал искать существующие примеры приложений, чтобы увидеть, как и можно ли реализовать инфраструктуру MVC и при этом получить точно такое же приложение с точки зрения внешнего вида и функциональности. В конце концов, это был фреймворк — он должен быть основой любого приложения и должен работать с любым приложением. Я нашел пример приложения e-Bazaar, чтобы сделать именно это.

Опять же, это упражнение не было отражением собственного программирования Бугуди Раму. Его очень хорошее приложение. Он хотел, чтобы это был всего лишь образец приложения. Кроме того, он не собирался применять к нему какой-либо узор или структуру. Он должен был отражать только интересный пользовательский интерфейс. Это то, что меня в нем привлекло.

По общему признанию, эта статья мало связана с реализацией MVC для примера приложения e-Bazaar и больше о самой интерпретации шаблона MVC — как она реализована пакетом библиотеки mvc_application. Фактически, эта статья предназначена не только для того, чтобы подчеркнуть достоинства использования шаблона проектирования при разработке программного обеспечения или продемонстрировать, как использование шаблона проектирования подчеркивает атрибуты, ускоряющие разработку программного обеспечения. Атрибуты, например, которые позволяют нескольким разработчикам легко работать над проектом отдельно, но параллельно; что позволяет новым разработчикам приходить в любое время и с течением времени и легко приступить к разработке и / или последующему сопровождению приложения. В этой статье также освещаются конкретные возможности пакета библиотеки mvc_application. Это потому, что оно уже предоставляет функции и возможности, которые обычно присутствуют в каждом мобильном приложении, что ускоряет общую разработку с помощью встроенных возможностей.

Мне нравятся скриншоты. Щелкните для Gists.

Как всегда, я предпочитаю использовать скриншоты, а не суть, чтобы показать концепции, а не просто показывать код в своих статьях. Я считаю, что с ними легче работать. Однако вы можете щелкнуть / коснуться их, чтобы получить код в сущности или в Github, если необходимо. По иронии судьбы, эту статью о мобильной разработке лучше читать на компьютере, чем на телефоне. Кроме того, мы программируем на наших компьютерах; не на наших телефонах. Сейчас.

В социальных сетях запрещены движущиеся изображения

Кроме того, в этой статье есть несколько файлов gif, демонстрирующих функции и возможности «движущихся изображений». Однако мне сказали, что просмотр таких файлов невозможен при чтении этой статьи на таких платформах, как Instagram, Facebook. и т. д. Вы увидите пустые квадратные пространства на месте файлов gif. Пожалуйста, имейте это в виду. Я бы порекомендовал прочитать это в браузере на medium.com.

Давайте начнем.

MVC в его коде и в его каталогах

Во всех проектах, над которыми я работал, в которых использовалась эта среда MVC, я организовал саму структуру каталогов, чтобы отразить три компонента шаблона проектирования MVC:

модель — данные, представление — интерфейс, контроллер — логика

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

Опять же, в исходном примере приложения не было предполагаемой структуры каталогов. Однако в варианте MVC, показанном ниже справа, вы можете видеть, что каталоги представлены с заданной структурой. Вариант MVC, конечно же, доступен для скачивания на Github, bazaar.

Даже если вы не знакомы с моими прошлыми статьями на эту тему, вы могли бы различить «роль» каждого файла Dart, указанного ниже. Что каждый делает в приложении и, возможно, даже где в приложении должен выполняться каждый файл.

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

Обратите внимание, что во время интеграции шаблона проектирования я постарался сохранить как можно больше существующего кода и имен файлов Dart из исходного образца приложения, но при этом передать предполагаемую организацию и структуру.

Кроме того, вы можете сделать вывод, что для этого приложения есть экран входа в систему. Опять же, просмотрев каталоги, вы найдете папку с именем login. В этой папке вы увидите три папки с именами, связанными с шаблоном проектирования MVC. Таким образом, вы можете увидеть, где находится код данных, экрана и логики. Как правило, каталоги перечислены в алфавитном порядке, а не в порядке аббревиатуры шаблона проектирования: MVC.

Итак, вот вы где. Вы можете видеть, что для входа в это приложение используются два экрана (или представления). Один называется loginPage.dart, а другой — signupPage.dart. У каждого есть соответствующий контроллер в папке, controller (по именам файлов вы можете догадаться, какой из них для какого), а «источник данных» включает Firebase от Google. Все это достаточно просто взглянуть на структуру каталогов. Таким образом, вы можете использовать саму структуру каталогов, чтобы делегировать своим командам отдельные «аспекты» приложения.

Кто с кем разговаривает

Такие шаблоны проектирования поощряют, если не диктуют, определенные линии связи, как это происходит в отношении MVC, между представлением, контроллером и моделью. Как и все в жизни, разделение вещей на поддающиеся изменению части значительно упрощает разработку и обслуживание. Проще для того, что в целом может быть очень сложной системой.

 

Обними трепет

Я обнаружил, что все популярные в настоящее время шаблоны проектирования, предлагаемые разработчикам Flutter, просто помещают шаблон проектирования поверх Flutter. В некоторых случаях они навязывали свой способ работы поверх нативной структуры. Конечно, все в разной степени, причем шаблон Provider (шаблон, предложенный Google), возможно, является наименее мешающим, а шаблон Redux — наиболее. Шаблон проектирования MVC, предлагаемый пакетом библиотеки, mvc_application, не борется с фреймворком Flutter, а работает с ним. Он принимает это — используя самые характеристики фреймворка.

Во-первых, класс State рассматривается как важный игрок в этом шаблоне проектирования MVC, реализованном для Flutter. Настолько, что этот класс State расширен, чтобы создать новый класс специально для инфраструктуры MVC под названием StateMVC. Вместо использования обычного класса State при работе с этой инфраструктурой MVC вам предлагается использовать класс StateMVC.

Вы можете спросить, зачем вам это делать. Есть несколько причин. Во-первых, потому что в этой конкретной интерпретации шаблона проектирования MVC для Flutter именно содержимое функции build () объекта State считается «представлением» для шаблона проектирования MVC. В «ванильной версии» Flutter виджет, возвращаемый функцией build (), представляет собой «интерфейс» приложения. Что ж, то же самое и в этой структуре MVC. Код, возвращающий виджет, рассматривается как код для «View» в MVC. Ниже приведен снимок экрана, на котором показаны первые несколько строк кода класса StateMVC. Как видите, это абстрактный класс. Это потому, что вам нужно реализовать его View — это его функция build ().

Каков ваш жизненный цикл?

Другая причина использовать этот класс, StateMVC, связана с жизненным циклом мобильного приложения. Имея опыт работы с Android, в одном из моих первых начинаний с Flutter я искал, как жизненный цикл мобильного приложения отражается во фреймворке Flutter. У каждого приложения есть жизненный цикл, и его следует учитывать при его разработке. Как подтверждают мои коллеги-разработчики Android, в известном классе Activity Android есть список функций, которые легко фиксируют различные «состояния», которые могут возникнуть на протяжении жизненного цикла мобильного приложения. Что ж, такой список функций есть и во Flutter, но вам нужно создать новый класс для доступа к ним.

Я нашел своего рода эквивалент функции didChangeAppLifecycleState (). Эта функция находится в абстрактном классе WidgetsBindingObserver. В данном случае передается объект типа AppLifecycleState, который представляет текущее состояние приложения. На снимке экрана ниже показаны возможные состояния, которые в настоящее время передаются в функцию didChangeAppLifecycleState ().

Я чувствовал, что этот класс является очень желательной чертой для фреймворка, и поэтому класс StateMVC расширяет этот абстрактный класс. Затем это обеспечивает доступ к жизненному циклу приложения с помощью функции didChangeAppLifecycleState (). Это также предоставляет список других функций обработчика событий. Все эти функции выделены на правом верхнем снимке экрана ниже.

Хотя этот абстрактный класс расширен, «пустой класс», называемый StateListener, также используется классом StateMVC для реализации этих обработчиков событий. Идея состоит в том, что вы можете выборочно переопределить любую из этих функций для обработки определенных системных или пользовательских событий в вашем приложении. Очень полезная возможность.

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

 

Контроль государства

А теперь подождите, можно сказать! Если вы хоть немного знакомы с шаблоном проектирования MVC, то помните, что именно Контроллер, а не Представление (StateMVC), должен обращаться к какой-либо конкретной системе или пользовательским событиям. Вы были бы правы! Это последняя, ​​но не менее важная причина использовать класс StateMVC. Это потому, что он знает, как работать с классом ControllerMVC. Это тот класс, который вы использовали бы для обращения к таким событиям. Вы увидите, как это было сделано чуть позже, в статье. Видите ли, класс StateMVC обращается к Контроллеру (или Контроллерам, в свою очередь) для обработки каждого происходящего события. Вы должны реализовать этот класс для обработки таких событий. Однако это не единственная причина использовать класс ControllerMVC.

Это непреложно. Продолжай в том-же духе

Итак, почему у Flutter есть неизменяемые объекты, называемые виджетами? Например, почему классы StatelessWidget и StatefulWidgets неизменны? В то время как объект StatefulWidget обычно имеет изменяемое содержимое.

Это соображение производительности. Такие неизменные элементы в компьютерной программе по определению неизменны (однажды построенные, они никогда не обновляются). Следовательно, они относительно дешевы в использовании с точки зрения циклов ЦП и ГП. Это хорошо. Они не меняют состояния.

Вот почему вы можете встретить ключевое слово const везде в приложении Flutter. Ключевое слово const означает, что значение этого экземпляра класса, например, известно во время компиляции и будет постоянным на протяжении всего времени работы приложения. В таком реактивном пользовательском интерфейсе, как во Flutter, большие части дерева виджетов регулярно перестраиваются. Каждый отдельный объект (и все его собственные переменные), используемый в каждом отдельном виджете, воссоздается снова и снова при каждой перестройке — кроме отмеченных значкомconst. В этом случае один и тот же экземпляр используется повторно на протяжении всего жизненного цикла приложения. Это хорошо. Вы увидите, что ключевое слово const часто используется в этом примере приложения.

Итак, части фреймворка Flutter не имеют состояния и, следовательно, неизменны. Это задумано и должно оставаться таким. Однако, если вы похожи на меня, когда вы впервые изучали Flutter, вы, несомненно, поместили изменяемые переменные, например, в StatefulWidget, и получили следующее предупреждение:

А если не туда, то где разместить логику для своего приложения? По своей природе такой код изменяется со временем в ответ на системные и / или пользовательские события! Это логика! Куда оно девается? Что ж, я знаю, где это находится в шаблоне проектирования MVC. Он идет в Контроллер. И в этом случае в класс ControllerMVC. Конечно, с «ванильной версией» Flutter такой код обычно помещается в объект State. Одно место для всего этого кода. Однако, используя этот пакет библиотеки MVC, теперь у вас есть несколько вариантов.

С помощью этой структуры вы можете свободно связывать любое количество контроллеров с определенным представлением (StateMVC) по своему усмотрению. Наличие более одного контроллера позволяет вам «разбить» логику на более управляемые части. Например, каждый контроллер может иметь дело с отдельным аспектом возможностей приложения. Нет необходимости задействовать его с другими Контроллерами. Это позволяет использовать модульный код. Это позволяет параллельную разработку. У вас могут быть отдельные группы разработчиков, ответственных за свою отдельную часть приложения — все они будут заключены в отдельный контроллер с таким количеством изменяемых переменных, сколько необходимо. Все с готовым доступом к единому представлению (StateMVC).

Поговорить с государством

На первом снимке экрана ниже показано начало класса ControllerMVC. Вы можете видеть выделенное на двух соседних снимках экрана, что этот Контроллер, по сути, имеет те же функции, что и в собственном объекте State Flutter. Помните, примите Flutter. Тебе это понравится.

 

Это делается для того, чтобы код, который вы обычно помещаете в функцию initState () объекта State, например, вы могли бы вместо этого поместить в собственную функцию initState () объекта Controller. Конечно, будучи файлом библиотеки Dart, этот Контроллер может содержать любое количество классов, любое количество функций высокого уровня и любое количество переменных высокого уровня. Хороший. Так что еще это значит?

Постройте дерево. Управляйте деревом.

Как вы знаете, во Flutter для косвенного вызова функции build () объекта State (для перестройки этой части дерева виджетов) вы вызываете этот класс setState. () функция. Ну, угадайте, что. Контроллер тоже имеет эту функцию. Вызов этой функции в контроллере вызовет функцию build () в объекте StateMVC, с которым она связана. Когда происходит событие и логика обращается к нему, он может затем сказать «Представлению» перестроить интерфейс, чтобы отразить его реакцию на это событие. По сути, эти двое могут разговаривать друг с другом.

Все, что вы можете делать в объекте State, вы можете делать в контроллере… любое количество контроллеров. Так что именно туда вы поместите «логику», из которой состоит ваше приложение.

Мы дома

Возвращаясь к образцу приложения и использованию шаблона проектирования MVC в этой структуре, мы легко можем найти «домашнюю страницу» для этого приложения в структуре каталогов. В каталоге src есть папка home. Там есть еще одна папка view. Это единственная папка, поэтому код в этой папке должен включать интерфейс — это экран. Фактически, в большинстве случаев это говорит вам, что класс, переданный в именованный параметр MaterialApp, home, находится в этой папке. Глядя ниже, вы можете увидеть, что в этой папке есть один-единственный файл Dart с именем homepage.

Глядя на последующие снимки экрана выше, вы можете увидеть, что соглашение об именах папок отражает те ключевые слова, которые используются во Flutter, и, следовательно, дает вам представление о том, что делает и где приложение.

Например, на втором снимке экрана вы можете легко определить, что «домашний» виджет включает в себя панель приложений, ящик и базу данных (модель). Вы правильно догадались, что виджет Scaffold возвращается функцией build () виджета Home. Наконец, на последнем снимке экрана вы видите, что на панели приложений отображаются функция поиска и корзина для покупок. Существует контроллер под названием HomeAppBar, который, несомненно, реагирует на нажатие пользователем значка поиска и значка корзины покупок. Все с первого взгляда.

Каково ваше мнение

На приведенном ниже снимке экрана показан компонент MVC View для главной страницы. Опять же, функция build () считается представлением в MVC для Flutter, и то, что вы видите ниже, является содержимым функции build () виджета Home. Теперь, как и большинство шаблонов проектирования MVC, представление обычно имеет доступ к связанному с ним контроллеру или контроллерам. Красные стрелки на снимке экрана ниже показывают, как это конкретное представление «взаимодействует» с конкретным контроллером, называемым HomeAppBar.

 

Как видите, в этом представлении используются два конкретных объекта из контроллера, HomeAppBar, которые затем отображаются на панели приложений приложения. Вы видите здесь разделение? Контроллер может позже внести изменения в код, стоящий за «объектом поиска» и «объектом тележки», без изменения одного символа кода на скриншоте выше. Модульное программирование. Несвязанный код.

Ниже у нас есть снимок экрана этого контроллера. Здесь мы обнаруживаем, что «объект поиска» и «объект корзины» на самом деле являются двумя получателями. Это два автономных объекта IconButton с выбранным значком и определенными обработчиками событий. Кроме того, структура каталогов намекает, что задействован объект showSearch, а папка содержит «класс делегата», который будет использоваться.

 

Два представления Один контроллер

Теперь также в функции build () виджета Home создается экземпляр класса RecentProducts. Что ж, это еще один StatefulWidget и также имеет объект State типа StateMVC — так что это еще один View. И, как вы видите ниже, он также использует контроллер HomeAppBar. Не существует закона, согласно которому нельзя использовать контроллер более чем в одном представлении. На самом деле это обнадеживает. Это представление отображает основной список продуктов в нижней половине домашней страницы. Интересно, почему этот View также нуждается в контроллере HomeAppBar?

 

Последний вход, первое обновление

По замыслу, StatefulWidget, RecentProducts, создается после StatefulWidget, HomePage. В конце концов, создается виджет «Домашняя страница», а затем виджет «Недавние продукты» создается в функции build () виджета «Домашняя страница». Из-за этого, по замыслу, когда они совместно используют Контроллер, и этот Контроллер запускает свою команду «обновить» (вызывает функцию setState ()), он перестраивает только последний StateMVC. объект, к которому он был добавлен. Возьми? Видите функцию обновления () ниже? Файл gif рядом со снимком экрана ниже демонстрирует процедуру поиска. Когда пользователь, например, выбирает слово джинсы, функция refresh () вызывает функцию build () в ‘RecentProducts’. виджет, чтобы в этой части экрана отображались только джинсы.

 

И так он работает с LIFO (Last In, First Out). Любые команды, направленные на объект State, будут влиять только на объект State, последний раз связанный с этим Контроллером. Когда объект состояния (отсюда и представление) завершается, предыдущий объект состояния снова становится «текущим» объектом состояния. Понимать? У вас может быть не только несколько контроллеров для представления, но и в течение срока службы этого контроллера он может быть связан с несколькими представлениями. Когда вы входите и выходите из экранов, один контроллер может отвечать за «логику», стоящую за ними. Хороший.

Три контроллера и вид

Ниже приведен снимок экрана StatefulWidget, HomePage. Здесь вы можете легко увидеть, как три контроллера добавляются в представление. Первый, ThemeChanger, добавляется первым, поэтому на него легко ссылаться с помощью свойства StateMVC, controller. Два других «добавляются» к объекту State внутри его конструктора, и у вас есть другие способы получить их ссылки. Например, на снимке экрана ниже платформа предлагает функцию controllerByType () в качестве средства для получения ссылки на контроллер HomeAppBar.

 

Каковы ваши предпочтения?

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

Бугуди Раму предоставил средство для перевода примера приложения в темный режим. Он не собирался сохранять эту настройку, поэтому при следующем запуске примера приложения этот режим исчезнет. Это нормально. Фреймворк может в этом помочь.

Контроллер с именем ThemeChanger отвечает за настройку темы приложения и, соответственно, его режима. Когда режим изменяется в этой версии примера приложения, его настройки легко сохраняются в системных настройках. И поэтому, когда приложение запускается снова, этот параметр снова используется. Давайте посмотрим на начало контроллера, ThemeChanger, ниже. Обратите внимание, что библиотека Prefs вызывается в функции контроллера initState (), задающей тему с помощью функции setDarkMode (). Как вы видите в файле gif ниже, функция setDarkMode () также вызывается каждый раз, когда пользователь нажимает на переключатель — в этой функции последняя настройка ‘сохраняется в настройках системы.

 

Посмотреть продукт

Давайте посмотрим на другой случай, когда используются возможности системы. На снимке экрана ниже представлена ​​первая часть StatefulWidget, которая отображает отдельный элемент Bazaar при нажатии на него. Этот элемент повторно отображается отдельно на отдельном экране. Вы можете видеть, что класс StateMVC реализован. Следовательно, это, конечно, говорит вам, что это View. На этом экране отображается отдельный элемент Bazaar. Файл gif ниже демонстрирует это.

Вы можете видеть, что соответствующий Контроллер «вводится» в представление с помощью оператора импорта, выделенного первой красной стрелкой ниже. Вторая стрелка ниже показывает, где создается экземпляр объекта Controller и передается объекту StateMVC. Затем он повторно появляется как объект в конструкторе StateMVC с переменной con типа ProductDetails, которому присвоено свойство controller типа ControllerMVC. Теперь у вас есть экземпляр этого конкретного контроллера, который будет использоваться функцией build () этого объекта State. Видите, как это все работает сейчас?

 

На следующем снимке экрана ниже показан соответствующий класс контроллера с тем же именем, что и класс StatefulWidget, ProductDetails. Обратите внимание, как языки программирования Dart учитывают повторяющиеся имена классов с помощью предложения «as» в операторе импорта. Кроме того, мы видим, что класс Prefs также импортируется и вызывается в функциях контроллера initState () и deactivate ().

Вы также можете увидеть ссылку на объект View контроллера (StateMVC), доступ к которому осуществляется в его функции initState (). Это делается путем присвоения переменной экземпляра state типа ProductDetailsState свойству stateMVC типа StateMVC. Вернувшись назад, вы увидите, как View и Controller могут «разговаривать» друг с другом. Контроллер ссылается на свое «текущее» представление.

В этом случае контроллер «разговаривает» с представлением (объектом состояния), чтобы получить имя конкретного элемента продукта, чтобы передать его статическим функциям Prefs, getBool () и setBool (). Итак, при каждом нажатии пользователем элемента для переменной экземпляра selected устанавливается значение true, в зависимости от того, найдено ли это название продукта в настройках системы, и хранится ли логическое значение true. Если это правда, в правом верхнем углу отображается «избранное» сердечко. Увидеть ниже.

 

Установить состояние; Восстановить государство

Несомненно, вы снова обратили внимание на функцию refresh (). Он вызывается после того, как пользователь нажимает на сердечко в правом верхнем углу. Как следует из названия, он предназначен для «обновления» экрана приложения. С точки зрения фреймворка Flutter, это восстановление этой части дерева виджетов. Обычно это делается с помощью функции setState () — ее также вызывает функция refresh (), но с пустой функцией: setState((){});

Однако, как и у любого хорошего фреймворка, у вас есть варианты. Функция rebuild () делает то же самое. Судя по названию, это просто к делу. Если вы хотите использовать функцию setState () традиционным способом, вы тоже можете это сделать. Фактически, рекомендуется использовать функцию setState (), чтобы гарантировать, что функция, которую вы вызываете, не возвращает объект Future. Ниже представлен тот же фрагмент кода, но вместо него используются две другие функции: rebuild () и setState ().

 

Контролировать обзор?

В каждом проекте Flutter, который я реализовал с использованием дизайна MVC, я обнаружил, что необходимо принять решение о том, какая часть «внешнего вида» пользовательского интерфейса приложения является ответственностью представления или контроллера. Конечно, на бумаге View больше всего связан с интерфейсом приложения, но на практике я обнаружил, что для Контроллера более целесообразно предоставлять компоненты, составляющие интерфейс в некоторых случаях. Я объясню.

Например, небольшое увеличительное стекло и тележка для покупок на панели приложений приложения в правом верхнем углу — помните, откуда они? Вы уже видели это на большом скриншоте выше. Они исходят от контроллера. Представление и Контроллер, названные ProductDetails, снова отображаются ниже. На этот раз вы можете увидеть, как геттеры, shopping и iconButton из контроллера доступны в функции build () представления.

Контроллер предназначен для обработки пользовательских событий. В этом случае, если и когда пользователь коснется увеличительного стекла или тележки для покупок. Как видите, логика такого события находится в Контроллере. Оказывается, размещение всего объекта IconButton в контроллере значительно упрощает разработку и сопровождение. Контроллер импортирует весь код и использует все необходимые переменные и логику для обращения к событию, а также для сохранения информации в системных настройках — и View ничем не мудрее. Часть View не знает о системных настройках. В этом нет необходимости.

Обратите внимание, как я дал значку «сердце» более общее имя, iconButton, в представлении? Это значит, что на более поздних этапах разработки или на этапе обслуживания, если «сильные мира сего» по какой-то причине захотят превратить это сердце в звезду, получатель вообще не нужно менять на стороне просмотра. . »Любые необходимые изменения будут производиться только в Контроллере. Модульное программирование. Несвязанный код.

Возможно, нам следует изменить получатель, shopping на более общий термин. Нет? С моей стороны необходимо осудить это различие. Вы также можете создать свой собственный проект Flutter.

Войдите и получите рекламу

В этом примере приложения явно используются два дополнительных пакета библиотеки. На снимке экрана с файлом pubspec.yaml ниже показан не только пакет mvc_application, используемый для предоставления инфраструктуры MVC, но также показаны два дополнительных пакета, auth и реклама. Один, конечно же, для авторизации входа в приложение, а другой позволяет размещать рекламу в вашем приложении. Так получилось, что я написал и эти два пакета библиотеки.

 

Управление приложением

Теперь, где можно инициализировать и настроить такие библиотеки, касающиеся входа в приложение и отображения рекламы? Я имею в виду, что они на самом деле не являются частью приложения, связанной с покупками в Интернете. Это общие функции любого мобильного приложения. Помните, что в фреймворке все должно быть организовано так, чтобы все было на своих местах. А где бы вы поместили код, используемый любым приложением? Конечно же, в папке app. Увидеть ниже.

В этом проекте под папкой app вы найдете две другие папки с именами, которые вы знаете: controller и view. На скриншотах ниже мы сначала быстро взглянем на то, что находится в папке, view. Это класс App View с названием BazaarApp. Именно этот класс вызывает страницу «Вход» и переходит к аспекту приложения покупки в Интернете. Однако, как вы видите ниже, он делает еще несколько вещей. На этом этапе наиболее важно то, что он создает экземпляр «Контроллера приложения» и принимает его с помощью именованного параметра con.

Он находится в Контроллере приложений, также называемом BazaarApp, где вы сначала увидите ссылки на два пакета библиотеки, auth и ads . Обратите внимание, что объект Auth сначала инициализируется в конструкторе App Controller, а библиотека Ads создается и настраивается в функции initState () контроллера App. Это все самодостаточно. Когда, например, приложение завершает свою работу, эти два объекта также удаляются с помощью функции dispose () контроллера приложения. Хороший.

Дать им время для начала

Итак, что это за функция init () здесь, в контроллере приложения, с возвращаемым значением Future, равным логическому? Вы видите это на скриншоте выше, и если вы догадались, что он проверяет, вошел ли уже пользователь в систему, вы будете правы. Возможно, вы не знакомы с этой функцией init (), но она является важным аспектом инфраструктуры MVC и может быть продемонстрирована как таковая на снимке экрана ниже. Видите ли, здесь задействован FutureBuilder Flutter.

 

В объекте «Состояние входа» вы можете увидеть, что если пользователь уже вошел в систему, мы переходим прямо на «Домашнюю страницу» вместо отображения экрана входа в систему.

Что ж, нужно время, чтобы определить, вошел ли пользователь уже в систему или нет. Однако его необходимо определить, прежде чем приложение сможет продолжить работу. При использовании FutureBuilder в центре экрана отображается вращающийся круг, пока он не будет определен. Фактически, при запуске выполняется ряд операций (например, инициализация библиотеки Prefs), функция init () — удобное место для их выполнения, чтобы подготовить приложение и настроить его перед продолжением. .

Остановись сейчас

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

Проще говоря, мне не понравились предлагаемые пакеты библиотеки шаблонов проектирования, когда я впервые решил перейти на Flutter. Я обнаружил, что они «сидят на вершине» фреймворка Flutter и не подражают его подходу, а вместо этого «работают с ним». Например, Redux был разработан Facebook, когда веб-приложения стали самой популярной платформой. Управление состоянием было необходимостью веб-приложений, поскольку протокол HTML не сохранял состояние приложения. С Flutter мы вернулись к автономным исполняемым файлам, поскольку Flutter изначально поддерживает их состояние. Мы вернулись к настольным компьютерам с автономными исполняемыми файлами, но теперь эти компьютеры могут уместиться у вас на ладони. Для этих приложений мы вернулись к MVC.

Ваше здоровье.

→ Другие рассказы Грега Перри

Источник: ledsshop.ru

Стиль жизни - Здоровье!