Наличники шаблоны: резные и деревянные шаблоны для дома

Простые трафареты для наличников. Как увеличить шаблон

Простые резные наличники можно делать и без шаблонов. Несколько примеров будет в видео — там показано, как расчертить, как вырезать. Но более-менее сложные узоры рисовать самостоятельно получится далеко не у всех. Нужен навык, да и талант. Самый простой способ — найти схему, распечатать ее в нужном размере, перенести на картон и вырезать. Получится шаблон, который можно обводить.

Второй способ: срисовать с фотографии. Далеко не все схемы можно найти. Некоторые, особенно старинные оконные наличники, вы нигде не найдете. Если есть хоть некоторые способности к рисованию, их можно срисовать.

Даже такой орнамент можно срисовать… если есть навык

Могут возникнуть вопросы по поводу того, как увеличить размер найденной схемы или шаблона. Есть три варианта:

• При помощи любого графического редактора. Самый простейший — Paint — есть в любом компьютере работающем с Windows (вкладка «Изображение», строка «Изменить размер изображения», выберите «сантиметры» и в окошке поставьте нужную длину (высоту).  Полученный файл можно будет распечатывать. Если принтер малого формата, может потребоваться разбиение на несколько страниц. Их потом следует склеить и, по полученному рисунку, сделать шаблон.
• При помощи ксерокопии. У ксероксов есть функция масштабирования.
• Взяв миллиметровую бумагу, переносить рисунок в нужном масштабе. Для этого исходное изображение разбиваем на квадраты со стороной 0,5 или 1 см (можно напечатать на листке в клетку). Потом переносим линии на миллиметровку, увеличивая их в нужной пропорции.

Первые два способа более быстрые. Но при масштабировании рисунок может получиться нечетким и размытым. Его можно поправить руками, можно отрисовать в каком-то редакторе, например, CorelDRAW. Как это сделать смотрите в видео. Как раз пример прорисовки схемы для резьбы.

Шаблоны наличников из дерева. Функциональное назначение оконных наличников

Преимущества

• декорирование оконных проемов. Например, наличник может визуально вытянуть низкий дом, или расширить узкий;

• возможность выразить свою индивидуальность или придать дому стиль определенной эпохи или региона;

• подчеркивают стиль дома и позволяют объединить все строения на участке в единый архитектурный ансамбль;

• защита щелей между окном и стеной от попадания пыли и влаги;

• снижение теплопотерь в месте примыкания оконной рамы и стены;

• снижения уровня внешнего шума;

• иногда являются единственно возможным вариантом оформления. Например, наличники на окна деревянного дома или сруба, могут быть только деревянными. Иначе потеряется весь колорит такого строения.

Недостатки

Деревянный, особенно резной наличник имеет ряд минусов, вернее особенностей:

• зависимость от атмосферных влияний. Частые перепады температур, влага, ультрафиолет, все эти факторы наносят урон наличнику;

• зависимость от качественной обработки. Правильный выбор породы, тщательная пропитка древесины, своевременная замена деталей, и окраска, все это способно продлить срок службы изделия. В противном случае, деревянный наличник скоро придет в негодность;

• сложность комбинирования с современными пластиковыми окнами. Не всегда подходят деревянные наличники на пластиковые окна.

Пластиковые окна с деревянными наличниками Довольно часто встречаются пластиковые окна, обрамленные деревянными наличниками, так, как показано на фото выше. Несколько неудачное, спорное решение. В таких случаях, нужно либо устанавливать деревянные стеклопакеты (или окна, ламинированные под дерево), либо красить наличник в белый цвет.

Более гармоничная отделка – на фото ниже.

Резные наличники на окна трафареты в натуральную величину. Материал для наличников

Резные наличники делают в основном из древесины хвойных пород. Оптимальный вариант — сосна, нормально режется, недорога, из-за высокого содержания смол долговечна. В принципе, можно использовать любую другую хвойную доску, но лучше не пробовать с еловой: слишком она волокнистая, не режется даже самым острым инструментом.

Можно делать резные наличники и из лиственных пород — липы (самая мягкая), тополя, клена, дуба, вишни и т.д. Но с каждой породой надо уметь работать, набивать руку и нет гарантии, что получится что-то удобоваримое, а древесина лиственных пород стоит дорого. Поэтому делают наличники на окна чаще все-таки из сосны. Надо только обратить внимание на качественные характеристики.

Резные наличники на окна — способ сделать свой дом уникальным

Если есть древесина или доска, пролежавшая 3 года и более, можно использовать ее: она уже точно сухая, только потребуется обработка и калибровка. Если дома нет деревообрабатывающего оборудования (рейсмуса и циркулярной пилы), нужна будет обрезная доска. Под резные наличники подойдет древесина первого или высшего сорта. Это значит, что на доске не должно быть сучков, сколов, смоляных карманов. Древесину берите камерной сушки, с влажностью не более 8-12%. На рынках такая не продается, искать надо на пилорамах и в строительных магазинах.

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

Записи решений по архитектуре Пример

Записи решений по архитектуре (ADR) — это метод документирования решений в процессе разработки понятным и непрерывным способом.

В этой статье приводится краткий пример ADR на основе воображаемого приложения, помогающего находить пасхальные яйца.

Что такое записи архитектурных решений?

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

ThoughtWorks оценивает эту концепцию как «принятие» на своем технологическом радаре, что означает, что они рекомендуют эту технику.

На https://adr.github.io вы можете найти отличный обзор этой техники. Но, грубо говоря, идея состоит в том, чтобы задокументировать решение, записав эту информацию (в соответствии с шаблоном от Майкла Найгарда):

Заголовок

Дайте значимое имя, которое позволит читателю быстро понять, о чем идет речь в этом ADR.

Статус

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

Примеры: предложено, принято, отклонено, устаревшее, заменено. Некоторые также называют этот раздел «мотивацией».

Будьте точны и сосредоточьтесь на фактах.

Решение

Опишите предлагаемое изменение. Придерживайтесь фактов и не пытайтесь продать решение. Также опишите, как и почему вы пришли к такому решению. Укажите альтернативы, которые рассматривались в процессе принятия решения.

Последствия

Описывает последствия изменения. Что становится легче? Что будет сложнее?

Приложение для поиска яиц

Чтобы объяснить технику на практическом примере (и поскольку Пасха быстро приближается), я подумал о полезном приложении под названием «Поиск яиц».

В Австрии принято прятать крашеные яйца в пасхальное воскресенье в саду, на квартире или в доме. Дети ищут их и получают все свои находки.

Конечно, эта семейная традиция доставляет всем большое удовольствие. Но также может быть неприятно, если вы не можете найти ни одного яйца или быть последним, кто что-то нашел.

Мы могли бы решить эту проблему с помощью технологий. Итак, давайте разработаем мобильное приложение Egg Finder, которое позволит нам фотографировать окрестности и подскажет, где найти яйца.

Итак, позвольте мне показать вам, как это сделать, решив, какой высокоуровневый архитектурный шаблон мы будем использовать для нашего приложения Egg Finder.

Пример

Шаблон архитектуры высокого уровня для приложения Egg Finder

Статус

Предлагаемый

Контекст

Для нашего приложения Egg Finder нам нужно выбрать шаблон архитектуры высокого уровня, который поможет нам быстро выйти на рынок и позволит нам легко вносить будущие изменения. В этом отношении модульный подход оказался мудрым выбором.

Мы можем использовать ИИ для распознавания изображений на мобильных телефонах. Тем не менее, наш анализ показывает, что возможности облачных провайдеров можно быстро использовать и это может привести к хорошим результатам. Итак, нам нужно разделить систему на мобильное приложение и серверное приложение. Связь должна осуществляться через API.

Логическая структура, к которой мы стремимся, состоит в том, чтобы разделить серверное приложение на компоненты: API, фотографии (хранить фотографии), распознавание яиц (искать яйца на фотографиях) и Push (отправлять уведомление в мобильное приложение, когда серверная часть находит яйцо).

Решение

Кандидатами на шаблон высокоуровневой архитектуры являются модульный монолит или микросервисы. Эти диаграммы архитектуры программного обеспечения описывают шаблоны.

Оба кандидата имеют свои преимущества и недостатки. Чтобы принять правильное решение, нужно учитывать множество факторов.

Но есть новая концепция, которую я разработал, которая лучше всего работает во время пасхального сезона и использует другую австрийскую пасхальную традицию: «Eierpecken». Не думая слишком много о последствиях, он мгновенно даст вам решение: « Решение об архитектуре программного обеспечения Egg Fights ».

Загружая видео, вы соглашаетесь с политикой конфиденциальности YouTube.
Узнать больше

Загрузить видео

Всегда разблокировать YouTube

1. Нарисовать диаграммы кандидатов на яйцах
2. Разбить верхние и нижние «концы» яиц вместе
3. Последнее яйцо хотя бы с одним неповрежденный конец выигрывает и представляет решение

Архитектурное решение Яичные бои — не слишком серьезная концепция, она довольно новая и должна доказать свою полезность в реальном сценарии ;). Чтобы собрать больше данных о концепции, поделитесь своим опытом. Счастливой Пасхи!

Как вы можете видеть на видео, мы «решили» использовать модульный монолит .

Последствия

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

Резюме

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

ADR — отличный инструмент для обоих этих аспектов. Их легко выполнять, и как только вы начнете делать их часто, это улучшит ваш способ принятия решений. Наличие ADR также улучшит документацию вашей системы, поскольку сделает ее более живой и прозрачной.

Также имеется множество инструментов. Мне нравится использовать этот: https://github.com/npryce/adr-tools.

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

Автор:

Саймон Лассельсбергер

Основатель Ласссим, эксперт по архитектуре и разработке программного обеспечения

Адрес электронной почты

Политика конфиденциальности 0003

Основатель Ласссим, эксперт по архитектуре и разработке программного обеспечения

За последние десять лет я работал с небольшими стартапами, а также с глобальными компаниями, такими как adidas, помогал им реализовывать их бизнес-идеи, создавая технические планы и руководя их командами разработчиков по проектам. Больше всего я горжусь успехом, которого мы добились с Runtastic. Они были приобретены adidas в 2015 году за 220 миллионов евро.

Серия Flutter Clean Architecture — Часть 1 (ОБНОВЛЕНО) | AbdulMuaz Aqeel

Чтение: 13 мин.

·

18 февраля 2021 г.

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

Уровни организованы в иерархическом порядке, с более абстрактными и специфическими для бизнеса уровнями вверху и более конкретными и техническими уровнями внизу.

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

Примечание. Эти статьи были обновлены в 22.02.2023 , а также исходный код, чтобы соответствовать последним изменениям, произошедшим в Flutter framework.

1. Разделение ответственности : Чистая архитектура способствует разделению ответственности, что помогает создать более организованную и модульную кодовую базу. Каждый уровень несет определенную ответственность, и уровни слабо связаны, что делает код более удобным для сопровождения и тестирования.
2. Тестируемость : упрощает написание автоматизированных тестов, поскольку различные уровни изолированы и могут тестироваться независимо. Это повышает качество программного обеспечения и снижает риск появления ошибок.
3. Гибкость : Чистая архитектура продвигает модульную конструкцию, которая позволяет разработчикам заменять компоненты или изменять детали реализации, не затрагивая остальную часть системы. Это упрощает адаптацию к изменяющимся требованиям или внедрение новых функций.
4. Независимость от внешних фреймворков : Позволяет отключать внешние фреймворки или библиотеки, не затрагивая остальную часть системы. Это снижает риск быть привязанным к определенной технологии или поставщику.
5. Ремонтопригодность : Помогает создавать код, который легче понять и поддерживать. Разделяя задачи и используя понятные интерфейсы между компонентами, разработчики могут работать с разными частями системы, не затрагивая другие части.

1. Накладные расходы : Это может добавить некоторые накладные расходы в процесс разработки, поскольку требует более предварительного планирования и проектирования. Это также может потребовать написания большего количества кода, поскольку каждый уровень должен иметь свой собственный набор интерфейсов и абстракций.
2. Сложность : Это может усложнить кодовую базу, особенно для небольших проектов или простых приложений. Это может быть излишним для небольших, простых приложений.
3. Кривая обучения : Требуется, чтобы разработчики понимали принципы и концепции, лежащие в основе архитектуры. Это может быть проблемой для разработчиков, которые плохо знакомы с этим подходом.
4. Занимает много времени : Реализация может занять больше времени, чем другие подходы, особенно если команда разработчиков не имеет опыта работы с этим подходом.

Что ж, к счастью, мы собираемся объяснить и создать простое новостное приложение , которое получает данные из REST API (требуется ключ API ), а также кэширует данные локально на устройствах. Это много работы, терпения и сосредоточения внимания на том, как мы будем реализовывать каждую часть приложения очень чистым способом… и окончательные результаты будут потрясающими.

Я разделил всю статью на 3 части, и эта часть объяснит, какие инструменты/библиотеки мы собираемся использовать, структуру папок , различные источники данных , настройку проекта и объяснение основная архитектура и слои данных.

После завершения этой серии приложение будет выглядеть так

Полный исходный код будет доступен в конце каждой части этой серии на моем GitHub .

Этот проект написан с использованием последних стабильных версий:

• Flutter : v3.7.3
• Dart : v2.19.2

Пакеты

902 25

r этрофит : пакет генератора исходного кода, который использует Dio в качестве http-клиента для создания правильных методов, которые нам нужны для работы с REST API на основе абстракции, он вдохновлен Android Retrofit .

f loor : это типобезопасный, реактивный, легкий пакет генератора исходного кода, который использует sqlite для локального хранения своих данных, он снова вдохновлен Android Room .

flutter_bloc : управление состоянием флаттера (вы можете использовать любой тип управления состоянием, с которым вы предпочитаете работать, например, провайдер или riverpod ).

equatable : пакет флаттера, который значительно упрощает сравнение объектов дротика на равенство.

get_it : локатор службы (также инжектор зависимостей во время выполнения).

flutter_hooks : хуки, вдохновленные React Hooks .

auto_route : пакет маршрутизации, который использует новый Flutter Router вместо стандартного Navigator.

awesome_dio_interceptor : потрясающий перехватчик логов Dio (написанный мной), который прекрасно регистрирует сетевые запросы и ответы.

oktoast : настраиваемый и простой в использовании пакет всплывающих сообщений.

lint : флаттер-пакет, помогающий писать чистый код, соответствующий Руководству по стилю Dart (более подробно объяснено позже).

Еще одно замечание, на которое я хотел бы обратить внимание, заключается в том, что для внедрения зависимостей во время выполнения мы будем использовать пакет get_it , мы также можем использовать пакет на основе генерации кода под названием injectable (вдохновленный Android Dagger ), который использует аннотации для автоматического создания зависимостей во время компиляции, но это затруднит объяснение проекта со всеми этими инструментами и библиотеками одновременно, поэтому мы будем использовать только get_it и внедрить зависимости вручную во время выполнения, и я объясню, как использовать этот внедряемый в следующих статьях.

Иконки

• ionicons : набор красивых иконок, доступных в виде флаттер-пакета.

Шрифты

• IBM Plex Sans
• Butler

Ваш файл pubspec.yaml должен выглядеть например так:

pubspect.yaml

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

Взгляните на диаграмму ниже и рассмотрите возможность создания папок внутри папки lib , как показано на диаграмме.

Папки ( данные , домен , презентация ) будут объяснены позже в деталях, но сейчас мы должны знать, для чего нужны ( утилиты , конфигурация )?

Конфигурация 9Папка 0074 содержит конфигурацию приложения (темы , , маршрутизаторы , и т. д.) и все остальное, связанное с конфигурациями приложения.

С другой стороны, папка utils включает ( константы , расширения , ресурсы , … и т. д.) и все, что с этим связано.

Кроме того, создайте файл с именем « locator.dart» внутри папки lib/src , он будет отвечать за внедрение наших зависимостей с использованием Пакет get_it .

диаграмма структуры папок флаттера

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

Во-первых, давайте подробно рассмотрим эту диаграмму ниже:

диаграмма архитектуры флаттера

Посмотрите еще раз, и ниже приведено объяснение для каждого уровня.

Уровень данных

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

Одним из основных преимуществ использования Data Layer в Clean Architecture является то, что он упрощает переключение между различными механизмами хранения данных, не затрагивая остальную часть приложения. Например, если вам нужно переключиться с базы данных SQL на базу данных NoSQL , вы можете просто заменить реализацию уровня данных, не изменяя какие-либо другие уровни в приложении.

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

Уровень представления

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

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

Преимущество использования Presentation Layer заключается в том, что кодовая база становится более модульной и удобной в сопровождении. Благодаря отделению пользовательского интерфейса от бизнес-логики и инфраструктуры становится проще модифицировать и расширять приложение с течением времени. Кроме того, он позволяет разрабатывать и использовать различные пользовательские интерфейсы с одной и той же базовой бизнес-логикой. Например, веб-приложение , мобильное приложение и настольное приложение могут использовать одни и те же Уровень домена , но имеют разные уровни представления, оптимизированные для соответствующих платформ.

Этот слой в нашей серии содержит две важные части: Блок (также ViewModels) и Пользовательский интерфейс

Что такое BLoC и почему?

BLoC означает ( B бизнес Lo gic C компоненты), это шаблон проектирования, который используется для управления состоянием приложения. Он отделяет бизнес-логику от пользовательского интерфейса, упрощая управление и поддержку кодовой базы приложения. Основная цель BLoC должен предоставить чистую, реактивную и масштабируемую архитектуру, которая может обрабатывать сложные пользовательские интерфейсы и управление состоянием.

Шаблон BLoC реализован с использованием потоков в Dart , что позволяет использовать реактивный стиль программирования. В этом шаблоне бизнес-логика обрабатывается блоком, который является компонентом, который получает события от пользовательского интерфейса, обрабатывает их и создает новые состояния. Пользовательский интерфейс, с другой стороны, прослушивает эти изменения состояния и соответствующим образом обновляет пользовательский интерфейс.

Используя Flutter BLoC , мы можем писать чистый, тестируемый и пригодный для сопровождения код, а также пользоваться преимуществами реактивного программирования и управления состоянием на основе потоков.

Почему он любим и популярен у разработчиков?

1. Разделение ответственности : Flutter BLoC позволяет разделить бизнес-логику и пользовательский интерфейс. Это означает, что разработчики могут сосредоточиться на реализации бизнес-логики в BLoC, не беспокоясь о пользовательском интерфейсе, и наоборот.
2. Повторное использование кода : С Flutter BLoC разработчики могут создавать повторно используемые компоненты бизнес-логики, которые можно использовать в разных частях приложения. Это уменьшает дублирование кода и упрощает поддержку кодовой базы приложения.
3. Предсказуемое управление состоянием : Flutter BLoC обеспечивает предсказуемый способ управления состоянием приложения. BLoC генерирует новые состояния в ответ на события пользовательского интерфейса, что упрощает анализ поведения приложения.
4. Тестируемость : Flutter BLoC упрощает написание модульных тестов для бизнес-логики приложения. Поскольку BLoC отделен от пользовательского интерфейса, его можно тестировать независимо от пользовательского интерфейса.
5. Большие и сложные приложения : Flutter BLoC особенно хорошо подходит для больших и сложных приложений, поскольку он обеспечивает масштабируемую архитектуру, которую можно расширять по мере роста приложения.

Недавно, flutter_bloc 9Разработчики 0074 объединили что-то под названием Cubit вместе с Bloc , и в основном Cubit намного проще в использовании, он имеет ( States и Cubit ), но не Events (в отличие от блока, который имеет Events, States, Bloc) , поэтому вместо добавления событий в блок здесь мы просто вызываем методы непосредственно из класса cubit.

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

Уровень домена

Уровень домена — самый важный уровень архитектуры, так как он содержит основную бизнес-логику приложения. Он отвечает за представление понятий и сущностей бизнес-домена и определяет правила и поведение приложения. Разделение ответственности помогает гарантировать, что бизнес-логика приложения остается независимой от пользовательского интерфейса, механизма хранения данных и других внешних систем.

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

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

Как мы уже говорили ранее, lint — это пакет dev-зависимости , который помогает нам писать правильный и чистый фрагмент кода, который следует определенным правилам.

После добавления пакета в файл pubspec.yaml создайте (если он еще не существует) файл в корневом каталоге и назовите его analysis_options.yaml , затем укажите правила, которые вы хотите применить, и рассмотрите возможность их соблюдения.

Как и здесь, мы исключаем анализатор из анализа чего-либо в сгенерированных файлах ( *.g.dart ), а также написал некоторые правила, которым следует следовать:

analysis_options. yaml

• block : это расширение помогает создавать блоки со всеми основными кодами и файлами (события, состояние), а также как фрагменты кода и другие полезные функции блока.
• генератор класса данных dart : полезное расширение, если вы хотите быстро генерировать методы сериализации JSON ( в Json , из Json ).
• импорт дротика : очень удобное расширение, которое делает сортировку и организацию импорта дротиков намного проще и чище.
• фрагменты флаттер-хуков : полезные фрагменты кода (написанные мной) для флаттер-хуков.

Нам нужно настроить наше приложение, прежде чем мы углубимся в реализацию слоев данных, и первое, что мы собираемся сделать, это настроить маршрутизацию нашего приложения:

Маршрутизация

Ранее мы использовали встроенный flutter Navigator , который выполняет основные функции маршрутизации, но у Navigator было много проблем, и команда Flutter решила создать новый механизм маршрутизации, и там 9Был выпущен 0073 Navigator 2. 0 (маршрутизатор) , а также был создан пакет для упрощения его использования под названием go_router .

С учетом сказанного, мы собираемся использовать новую флаттер-маршрутизацию вместо старого Navigator, но мы будем использовать пакет под названием auto_route , который использует генерацию кода и действительно упрощает маршрутизацию.

Вы можете выбрать любой пакет маршрутизации, который вам больше нравится и который соответствует вашим потребностям.

Теперь, после добавления пакета в файл pubspec.yaml , как мы говорили о нем в начале статьи, создайте папку по этому пути lib/src/config и назовите ее router , затем внутри в папке создайте файл и назовите его app_router.dart , как показано ниже:

lib/src/config/router/app_router.dart

В настоящее время у нас нет ( BreakingNewsView , ArticleDetailsView и SavedArticlesView 9 0074 ) классов, но просто для ясности вы можете оставить список пустым, и как только мы создадим каждое представление, мы вернемся сюда и добавим этот маршрут в список.

Вот как мы управляем нашей маршрутизацией, вам нужно только определить свои маршруты в списке и запустить средство запуска сборки, чтобы сгенерировать для нас правильный код в файле с именем ( app_router.gr.dart ), затем определить экземпляр этого класса ( appRouter ) в качестве глобальной переменной под классом, чтобы использовать его в любом месте вашего приложения.

Остался последний шаг, нам нужно сообщить нашему MaterialApp , что мы используем новый флаттер-маршрутизатор, и предоставить необходимые методы для правильной работы с нашим сгенерированным кодом маршрутизации, как показано здесь:

lib/main.dart

Ваш файл main.dart должен выглядеть так, мы используем MaterialApp.router , затем мы предоставляем делегат нашего appRouter и парсер для маршрутизатора.

Примечание: наш MaterialApp.router обернут виджетом под названием OkToast , и это позволяет нам использовать OkToast для отображения настраиваемого всплывающего сообщения пользователю.

Темы

Мы закончили маршрутизацию приложения, теперь все, что нам нужно сделать, это определить темы нашего приложения, и это довольно просто.

Создайте папку с именем themes по этому пути lib/src/config , а затем внутри этой папки создайте файл и назовите его « app_themes.dart », который будет содержать темы вашего приложения, как показано ниже:

lib /src/config/themes/app_themes.dart

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

Лучше упомянуть, что вы можете использовать Material 3 в своей теме, установив useMaterial3: true в ThemeData .

Utils

В папке lib/src/utils у нас есть константы , расширения и ресурса каталога, в которых хранится утилита нашего приложения. s, и просто чтобы прояснить ситуацию здесь .. в обе константы и расширения , всякий раз, когда мы хотим добавить константные значения определенного типа или добавить функциональные возможности для определенного класса, мы разделяем их в отдельных файлах, вам может не понадобиться эта сложность, но в этом примере я буду следуйте этому подходу, поэтому в константы папка у нас есть ( nums.dart и strings.dart ) каждый файл содержит разные константы.

А вот наш файл « strings.dart » должен выглядеть так:

lib/src/utils/constants/strings.dart

Помимо расширений нам может понадобиться добавить метод расширения в класс ScrollController , поэтому мы создаем файл с расширением и называем его scroll_controller.dart и определяем наш код в этом файле (будет объяснено позже в Часть 2 ).

Отлично, теперь все должно быть просто отлично.