Вопрос, который неоднократно возникал в моих сеансах вопросов и ответов с тех пор, как была выпущена библиотека навигации из компонентов архитектуры Android, заключается в том, является ли архитектура Single Activity Architecture:
- Вредно (плохо)
- Неважно (нейтрально)
- Полезно (хорошо)
- Обязательно (применяется везде и во всех ситуациях)
В этой короткой статье я попытаюсь уменьшить общую сумму недоразумений, которые я вижу у младших и промежуточных разработчиков, относительно того, нужна ли такая практика; вместе с тем, как вы могли бы сделать это оценочное суждение для себя.
Не только авторитетные фигурки попугаев
Любой старший разработчик должен знать, что такого рода вещи (фреймворки) обычно находятся где-то между нейтральным и хорошим в зависимости от требований проекта и личные предпочтения.
Они никогда не являются обязательными, так как это означало бы, что нельзя создавать многофункциональные и производительные приложения без какой-либо конкретной структуры; что полная чушь. Если разработчик фреймворка может его построить, благодаря принципу вычислительной универсальности (полнота по Тьюрингу), вы можете создать его самостоятельно.
Они могут быть плохими, если вам случится обнаружить конкретную ситуацию, когда фреймворк неспособен решить конкретное требование проекта.
По сути, я говорю о том, что вы должны быть очень осторожны с авторитетными лицами, включая меня, делая общие заявления об инструменте или подходе, независимо от того, как они используются и кто их использует.
Да, это правда, что команда Android прямо сейчас рекомендует архитектуру единого действия, и они также рекомендуют вам использовать компонент навигации для достижения этой цели. Вместо того, чтобы просто повторять это утверждение, я поделюсь своим мнением о том, в чем состоит чистая выгода от использования архитектуры единого действия (или отказа от нее).
Избегать действий Бога
Я полностью согласен с тем, что вам не следует заниматься деятельностью Бога. Чтобы статья была краткой, я резюмирую почему, и вам придется поверить мне на слово (а еще лучше, попробуйте сами):
- Их почти невозможно проверить
- Ошибки почти невозможно найти и исправить
- Их очень сложно читать (даже для себя, не говоря уже о коллегах)
- В них может быть сложно или невозможно добавить новые функции, не нарушая их полностью.
По этой причине я рад рекомендовать не заполнять ваши Activity каким-либо кодом, который можно было бы разделить на модули и поместить во что-то вроде n- многоуровневой архитектуры графического интерфейса MV-Whatever. Совет для профессионалов. : иногда трех слоев недостаточно для адекватного разделения проблем.
Прежде чем мы перейдем к обсуждению конкретных реализаций, ключевым моментом этого раздела является то, что я сильно подозреваю, что основная причина для команды Android, отстаивающей архитектуру MVVM и переходящей на единое действие, состоит в том, чтобы просто побудить вас применять разделение проблем в ваших приложениях. Таким образом, все перечисленные выше пункты, являющиеся результатом написания действий Бога, будут сокращены или исключены из ваших приложений.
Если вы входите в команду Android и чувствуете, что я ошибаюсь, сообщите мне, и я напишу отзыв. Даже если это произойдет, я придерживаюсь своего утверждения, что вам действительно не следует писать «Действия Бога».
Архитектура единого действия - только одно решение?
При этом я начинаю не соглашаться с некоторыми людьми относительно того, означает ли это, что вы должны использовать только одно действие, или соотношение действий и основных функций пользовательского интерфейса (экранов) один к одному, или что-то среднее.
По иронии судьбы, когда я впервые попытался реализовать архитектуру единого действия с использованием компонента навигации (что, по общему признанию, было около двух лет назад в младенчестве фреймворка), я сразу же столкнулся с ситуацией, когда я не мог реализовать Архитектура единого действия из-за ограничений компонента навигации.
Чтобы быть конкретным, мне пришлось интегрировать аутентификацию входа в Google через Activity.startActivityForResult () и Activity.onActivityResult (), чтобы зарегистрировать пользователей с помощью аутентификации Firebase, и простейший способ решить эту проблему заключался в том, чтобы просто не использовать компонент навигации в этой конкретной функции приложения.
Примечание: я недавно встречался с экспертом по библиотеке навигации от Jetpack, и похоже, что они устранили эту проблему, касающуюся потоков входа в систему.
Поэтому вместо того, чтобы иметь одно действие для всего приложения или соотношение функций один к одному к действиям, у меня было два Мероприятия и четыре функции. Вне функции входа в систему навигация работала прекрасно, и я все еще мог применять разделение задач в Activity, которое не имело ничего общего с графиком навигации.
В итоге
Такие фреймворки, как компонент навигации, иногда полезны, иногда хуже, чем их не использовать, никогда не являются обязательными из-за естественных законов вычислений, а иногда - пустой тратой размера APK.
Архитектура единого действия, в зависимости от требований проекта, может побудить вас сократить количество избыточного кода и применить разделение задач. Однако вы также можете добиться этого, просто используя свои действия в качестве контейнеров уровня функций (содержащих ваши модели-представления-все что угодно), и я чувствую, что недостаточно людей упоминают, что дополнительная сложность в настройке единой структуры действий может не всегда является чистым преимуществом по сравнению с независимой архитектурой с несколькими действиями, в которой вместо этого используются намерения или рукописный Маршрутизатор.
Вся цель этой статьи состоит в том, что я знаю, что некоторые из вас, младшие и промежуточные разработчики, сталкивались с подобными ситуациями и обеспокоены тем, что несоблюдение рекомендаций команды Android означает, что вы делаете что-то неправильно. Позвольте мне пояснить: Точный момент, когда вы правы, нарушая принципы или рекомендации, - это когда требования вашего проекта делают так, что следование рекомендации создает больше проблем, чем несоблюдение ее.
Социальные сети | Служба поддержки
Эту статью написал Райан Майкл Кей. Я программист / инженер-самоучка, создающий образовательный контент по широкому кругу тем на самых разных платформах. Лучший способ поддержать меня - подписаться на меня на различных платформах и присоединиться к моему сообществу разработчиков (у нас сотни участников!):
Объявления:
https://www.facebook.com/wiseassblog
https://twitter.com/wiseAss301
Руководства и курсы:
Бесплатные уроки, интерактивные вопросы и ответы, живое программирование:
https://www.youtube.com/channel/UCSwuCetC3YlO1Y7bqVW5GHg
Программирование рабочего стола Java с JavaFX (средний уровень) - https://skl.sh/31pzCa1
Полное введение в программирование на Java для новичков (начинающий - средний) - https://skl.sh/3fZbjos
Приложения для Android с Kotlin и Android Studio (для начинающих) - https://skl.sh/2ZU6ZT9
Разработка материалов для Android с использованием Kotlin (средний уровень) - https://skl.sh/2OrwrYZ
Подключиться:
