Что такое архитектура приложения перечислите основные компоненты android приложений
Правильная архитектура мобильного приложения Android глазами пользователя
Архитектура Android-приложений: основные принципы
Можно постараться определить по каким основным принципам выстраивается архитектура Android-приложений, о них мы сегодня и поговорим.
Нужно разделять ответственность
Это один из самых важных принципов, который многие не соблюдают. Нужно разделять ответственность между классами. Например, не нужно разрабатывать весь код приложения в «Activity» или «Fragment», потому что эти классы должны отвечать лишь за логику взаимодействия интерфейса и ОС.
Нужно наладить управление интерфейсом пользователя из модели
пользователи вашего приложения не потеряют свои данные, если операционная система Андроид удалит вашу программу, освобождая ресурсы системы;
ваш продукт будет работать даже в тех случаях, когда устройство не будет подключено к сети или связь с сетью буде т слабой и нестабильной.
Рекомендуемая архитектура Android-приложения
Невозможно и неправильно будет утверждать, что какая-то особенная архитектура мобильного приложения Android будет лучше или хуже другой. Сценарии работы у разных приложений будут разные, соответственно , архитектура и подходы к разработки приложений тоже будут разные. Поэтому, если у вас уже сформировались собственные архитектурные принципы при создании успешных Android-приложений, то не стоит их менять. Если вы стоите на самом старте и не знаете, какую архитектуру использовать, то можете применить архитектуру, рекомендуемую командой разработчиков Android. Если необходимо, то можете ее доработать или переопределить на свой вкус.
Вот как она выглядит:
«Activity» и «Fragment» являются частью слоя «View», а это значит, что они не должны иметь ничего общего с бизнес-логикой и/или сложными процессами в приложении. «View» всего лишь отвечает за взаимодействие между пользователем и приложением, анализируя и наблюдая за этим процессом.
«ViewModel» анализирует состояние «LifeCycles» и поддерживает согласование между компонентами в случаях изменений конфигураций Android-приложения, это также становится возможным благодаря извлечению данных из «Repository». «ViewModel» не взаимодействует напрямую с «View», а делает это при помощи сущности «LiveData».
«Repository» — это не какой-то специальный компонент Андроид. Это вполне обычный класс, чья основная задача — это выборка данных из разных источников, в том числе и баз данных, и различных веб-служб. Выбранные данные, этот класс преобразует таким образом, чтобы их мог наблюдать компонент «LiveData» и они были доступны компоненту «ViewModel».
«Room» — это библиотека, облегчающая процесс взаимодействия с базой данных «SQLite». Также в ее зоне ответственности лежит: запись шаблонов действий, проверка ошибок во время компиляции, прямое «общение» с «LiveData».
Подробнее о компонентах рекомендуемой архитектуры
Компонент «LiveData». По сути является компонентом, содержащим какие-то данные, которы е можно наблюдать со стороны. Данный компонент всегда знает, когда и какие данные изменяются в приложении и «наблюдает» ли кто-то за ним в данный момент времени и нужны ли обновления «наблюдателю».
Компонент «ViewModel». Это один из самых важных компонентов архитектуры, потому что именно этот компонент содержит в себе информацию о состоянии пользовательского интерфейса, также этот компонент сохраняет «целостность» интерфейса при изменении в конфигурации, например экран телефона был повернут. «ViewModel» связывает «LiveData» и «Repository». «LiveData», получая данные из «ViewModel», делает его доступным для наблюдения за ним.
Компонент «Room». Операционная система Андроид всегда поддерживала работу с базой данных SQLite, но такое взаимодействие имело ряд проблем. Например, приходилось создавать множество шаблонов для совместной работы, SQLite не могла сохранять простые Java-объекты, не проводилась проверка при компиляции и др. Но пришла библиотека «Room» и решила эти проблемы взаимодействия между Android и SQLite.
Заключение
Любая архитектура Android-приложения — это широкое поле для творчества, да и вообще программирование — это творчество, где любую проблему можно решить несколькими путями, в общем так, как видит решение конкретный «автор».
Описанную архитектуру Android-приложений рекомендует Google, при это она не является обязательной — об этом, кстати, сам Гугл и пишет. Поэтому не стоит боят ь ся экспериментировать и практиковать что-то новое.
Мы будем очень благодарны
если под понравившемся материалом Вы нажмёте одну из кнопок социальных сетей и поделитесь с друзьями.
Вот и пришла пора поговорить непосредственно о внутренней организации приложений под Android : обсудить их архитектуру и основные компоненты.
Архитектура Android приложений основана на идее многократного использования компонентов, которые являются основными строительными блоками. Каждый компонент является отдельной сущностью и помогает определить общее поведение приложения .
Система Android выстроена таким образом, что любое приложение может запускать необходимый компонент другого приложения. Например, если приложение предполагает использование камеры для создания фотографий, совершенно необязательно создавать в этом приложении активность для работы с камерой. Наверняка на устройстве уже есть приложение для получения фотографий с камеры, достаточно запустить соответствующую активность , сделать фотографию и вернуть ее в приложение , так что пользователь будет считать, что камера часть приложения, с которым он работает.
Можно выделить четыре различных типа компонентов, каждый тип служит для достижения определенной цели и имеет свой особый жизненный цикл , который определяет способы создания и разрушения соответствующего компонента. Рассмотрим основные компоненты Android -приложений.
Сервисы (Services). Сервис - компонент , который работает в фоновом режиме, выполняет длительные по времени операции или работу для удаленных процессов. Сервис не предоставляет пользовательского интерфейса. Например, сервис может проигрывать музыку в фоновом режиме, пока пользователь использует другое приложение , может загружать данные из сети, не блокируя взаимодействие пользователя с активностью. Сервис может быть запущен другим компонентом и после этого работать самостоятельно, а может остаться связанным с этим компонентом и взаимодействовать с ним.
Контент-провайдеры (Content providers). Контент-провайдер управляет распределенным множеством данных приложения. Данные могут храниться в файловой системе, в базе данных SQLite, в сети, в любом другом доступном для приложения месте. Контент-провайдер позволяет другим приложениям при наличии у них соответствующих прав делать запросы или даже менять данные. Например, в системе Android есть контент-провайдер, который управляет информацией о контактах пользователя. В связи с этим, любое приложение с соответствующими правами может сделать запрос на чтение и запись информации какого-либо контакта. Контент-провайдер может быть также полезен для чтения и записи приватных данных приложения, не предназначенных для доступа извне.
Все рассмотренные компоненты являются наследниками классов, определенных в Android SDK .
Это тема сложна для понимания, даже если вы немного разбираетесь в технологиях. Но если коротко, архитектура приложения − это набор методов и шаблонов, которые помогают разработчикам создавать структурированные приложения. В этом материале специалисты из команды Crypterium разбирают тему архитектуры и рассказывают о подходе компании к её разработке.
Давайте в объяснении того, что есть архитектура приложения, отойдем от технических терминов и проведем аналогию с повседневной жизнью. Посмотрите на свое тело. Все, что находится снаружи, − голова и тело, − это front, а всё, что внутри, − сердце, мозг и внутренние органы, − back.
Crypterium занимается разработкой платёжного сервиса. Back-end команда разрабатывает технологии, отвечающие за обмен, передачу, хранение и прочее, а Front-end следят за тем, чтобы пользователю было удобно взаимодействовать с функциями приложения.
Теперь, когда мы разобрались с различием front и back частей, давайте рассмотрим два ключевых подхода, которые используют современные разработчики: API First и Loose Coupling. Они позволяют программистам легко менять структуру приложения. Более того, они делают так, что каждая отдельная часть приложения может быть изменена без затрагивания остальных частей.
Метод API First отвечает за высокую скорость работы и нововведения. Идея в том, чтобы ввести данные и получить в ответ API, необходимый для Front-end и Back-end команд разработки: это позволяет им одновременно писать код и параллельно тестировать его. Преимущества метода заключаются в снижении издержек на разработку, увеличении скорости и снижении рисков.
Пример из жизни: когда вы готовите пасту Болоньезе, вам не нужна сначала паста, потом соус: вы можете готовить их параллельно. В таком случае, еда приготовится быстрее, ничего не успеет остыть, а друзья смогут оценить блюдо в том состоянии, в котором оно и должно быть (а не как обычно).
Одна из функций, за которую команда приложения любит подход API First, называется Swagger − это open-source фреймворк, который помогает разработчикам строить архитектуру, проектировать и создавать документацию для своих приложений. Swagger автоматически генерирует описание API для большинства языков и фреймворков, для обеих − Front-end и Back-end − команд.
Следующий подход называется Loose Coupling, в дословном переводе − слабая связь. И если в жизни примером Loose Coupling может быть отмена свидания в День святого Валентина, то в программировании это наоборот помогает. Если быть точнее, то эта функция упрощает соединение компонентов в сети.
Система Loose Coupling уменьшает риск случайного изменения отдельных объектов, без изменения других − так как в приложении всё взаимосвязано, это может привести к поломкам и уязвимостям. Так вот, благодаря возможности ограничения работы отдельных соединений, система помогает найти и решить проблему быстрее, прямо во время тестирования.
Благодаря принципам API First и Loose Coupling, приложение может выступать микросервисом − приложением, состоящем из независимых служб, способных работать самостоятельно, свободно масштабироваться на разных устройствах.
Микросервисные архитектуры лучше организованы, так как у каждого микросервиса есть определенная задача. Их преимущество ещё и в легкой реконфигурации и перестройке для различных целей. Кроме того, они характеризуются быстрым развертыванием, отказоустойчивостью, горизонтальным масштабированием, низким порогом входа и простотой управления.
Представьте себе умный дом, где все можно контролировать и управлять с помощью одного устройства. Допустим, это устройство − * core *, а управляемыми элементами являются * services *. С помощью основного устройства вы можете открывать окна, включать телевизор или даже закрывать шторы. Так работает архитектура микросервисов.
Но всегда есть альтернативный вариант, верно? Второй тип архитектуры − монолитная архитектура. Это означает, что приложение написано как одна единица кода, чьи компоненты предназначены для совместной работы, используют одни и те же ресурсы и место на диске. Службы в таких приложениях тесно связаны, и при изменении одной из них проблемы могут возникнуть у остальных.
Представьте себе многослойный шоколадный торт. Каждый новый слой делает торт ещё вкуснее, но вы не можете добавить слой с клубникой в середину, не изменив вкус и структуру торта. Можно считать, что у торта − монолитная архитектура.
Мультифункциональные приложения, например, мобильные кошельки, обычно связаны ещё с сотнями различных служб. Чтобы структурировать работу приложения, в Crypterium разделили команду Back-end разработчиков на две. Одна работает только над ядром продукта, вторая − над всем остальным, то есть авторизацией, коммуникацией и так далее.
Команда Front-end специалистов следит за тем, чтобы приложение было удобным, а интерфейс − интуитивно-понятным и быстрым.
Android-версия приложения Crypterium основана на языках Java и Kotlin (как и среда JVM), а приложение iOS − на новом, простом в использовании языке программирования Swift. Функции языка включают в себя контроль доступа, управление памятью, отладку, цепочку вызовов и протокол-ориентированное программирование.
Команда разработчиков Crypterium для iOS, выбрала стиль архитектуры MVVM и роутинг. Благодаря структуре, архитектуры удобны и для разработчиков, и для пользователей.
MVVM − это Model-View-ViewModel, где Model означает информацию о продукте, а View показывает, как клиенты видят продукт. В MVVM есть структура слоев: первый уровень − UI (пользовательский интерфейс). Другие уровни содержат сетевые и логические сервисы. Роутинг отвечает за технические процессы − действия пользователей, перемещения внутри приложения, регулируются именно им.
Чтобы повысить простоту обслуживания и гибкость приложений, команда Android решила использовать метод под названием «Чистая архитектура». Он гарантирует отсутствие ненужных связей и делает приложение более тестируемым.
Результатом является чистое, новое, свежее, простое в использовании приложение для Android с четырьмя уровнями:
- веб, базы данных, пользовательский интерфейс;
- шлюзы, презентаторы;
- варианты использования;
- юридическая информация.
Архитектура приложений − очень сложная тема, и все, что написано выше, является лишь верхушкой айсберга.
Если вам понравился материал о том, что такое архитектура приложения, посмотрите следующее:
Источник: Объясни это маме − что такое архитектура приложения on Hackernoon
Android был представлен миру в 2005 году, и за эти 12 лет существования платформа достигла удивительных успехов, став самой установленной мобильной ОС. За это время было запущено 14 различных версий операционной системы, причем Android всегда становится все более зрелым. Тем не менее, очень важная область платформы по-прежнему игнорировалась: стандартный шаблон архитектуры, способный обрабатывать особенности платформы и достаточно простой для понимания и принятия средним разработчиком.
Ну, лучше поздно, чем никогда. На последнем вводе / выводе Google команда Android наконец решила решить эту проблему и ответить на отзывы разработчиков по всему миру, объявив официальную рекомендацию по архитектуре приложений Android и предоставив строительные блоки для ее реализации: новую архитектуру Компоненты. И что еще лучше, им удалось сделать это, не ставя под угрозу открытость системы, которую мы все знаем и любим.
В этом руководстве мы рассмотрим стандартизированную архитектуру, предложенную командой Android в Google I / O, и рассмотрим основные элементы новых компонентов архитектуры: Lifecycle , ViewModel , LifeData и Room . Мы не будем уделять слишком много внимания коду, а сосредоточимся на концепции и логике этих тем. Мы также рассмотрим некоторые простые фрагменты, все они написаны с использованием Kotlin, удивительного языка, который теперь официально поддерживается Android.
1. Что пропало в Android?
Если вы только начинаете свое путешествие как разработчик, возможно, вы не знаете точно, о чем я говорю. В конце концов, архитектура приложения может быть поначалу неясной темой. Но поверьте мне, вы скоро узнаете его важность! По мере роста и усложнения приложения его архитектура становится все более важной. Это может буквально сделать вашу работу блаженством или адом жизни.
Архитектура приложений
Грубо говоря, архитектура приложения представляет собой согласованный план, который необходимо составить до начала процесса разработки. Этот план предоставляет карту того, как различные компоненты приложения должны быть организованы и связаны друг с другом. В нем представлены руководящие принципы, которые должны соблюдаться в процессе разработки, и вынуждает жертвовать собой (обычно связанные с большим количеством классов и шаблонов), которые в итоге помогут вам создать хорошо написанное приложение, которое будет более тестируемым, расширяемым и обслуживаемым.
Архитектура прикладного программного обеспечения — это процесс определения структурированного решения, отвечающего всем техническим и эксплуатационным требованиям, при оптимизации общих атрибутов качества, таких как производительность, безопасность и управляемость. Он включает ряд решений, основанных на широком спектре факторов, и каждое из этих решений может оказать значительное влияние на качество, производительность, ремонтопригодность и общий успех приложения.
— Руководство по архитектуре и дизайну программного обеспечения Microsoft
Хорошая архитектура учитывает множество факторов, особенно характеристики и ограничения системы. Существует множество архитектурных решений, каждый из которых имеет свои плюсы и минусы. Тем не менее, некоторые ключевые понятия являются общими для всех видений.
Старые ошибки
До последнего ввода-вывода Google система Android не рекомендовала какой-либо конкретной архитектуры для разработки приложений. Это означает, что вы были полностью свободны в принятии любой модели: MVP, MVC, MVPP или вообще без паттерна. Кроме того, платформа Android даже не предоставила нативных решений для проблем, создаваемых самой системой, в частности, жизненным циклом компонента.
Таким образом, если вы хотите использовать шаблон приложения View View в своем приложении, вам нужно с нуля придумать собственное решение, написать много стандартного кода или использовать библиотеку без официальной поддержки. И это отсутствие стандартов создало множество плохо написанных приложений с кодами, которые было сложно поддерживать и тестировать.
Как я уже сказал, эта ситуация критиковалась годами. На самом деле, я недавно написал об этой проблеме и о том, как ее решить, в моей серии « Как принять модель представления на Android ». Но важно то, что после 12 долгих лет команда Android наконец решила выслушать наши жалобы и помочь нам с этой проблемой.
2. Архитектура Android
Новое Руководство по архитектуре Android определяет некоторые ключевые принципы, которым должно соответствовать хорошее приложение Android, а также предлагает безопасный путь для разработчика для создания хорошего приложения. Однако в руководстве прямо указано, что представленный маршрут не является обязательным, и в конечном итоге решение является личным; Разработчик должен решить, какой тип архитектуры выбрать.
Согласно руководству, хорошее Android-приложение должно обеспечивать четкое разделение проблем и управлять пользовательским интерфейсом от модели. Любой код, который не обрабатывает пользовательский интерфейс или взаимодействие с операционной системой, не должен быть в Деятельности или Фрагменте, потому что поддержание их как можно более чистыми позволит вам избежать многих проблем, связанных с жизненным циклом. В конце концов, система может уничтожить Действия или Фрагменты в любое время. Кроме того, данные должны обрабатываться моделями, которые изолированы от пользовательского интерфейса и, следовательно, от проблем жизненного цикла.
Новая рекомендуемая архитектура
Архитектура, которую рекомендует Android, не может быть легко помечена среди стандартных шаблонов, которые мы знаем. Он выглядит как шаблон Model View Controller, но он настолько тесно связан с архитектурой системы, что трудно маркировать каждый элемент с использованием известных соглашений. Это, однако, не имеет значения, так как важно то, что он полагается на новые компоненты архитектуры, чтобы создать разделение задач с отличной тестируемостью и ремонтопригодностью. А еще лучше, это легко реализовать.
Чтобы понять, что предлагает команда Android, мы должны знать все элементы компонентов архитектуры, поскольку именно они сделают за нас тяжелую работу. Существует четыре компонента, каждый с определенной ролью: Room , ViewModel , LiveData и Lifecycle . Все эти части имеют свои собственные обязанности, и они работают вместе, чтобы создать надежную архитектуру. Давайте посмотрим на упрощенную схему предложенной архитектуры, чтобы лучше ее понять.
Как видите, у нас есть три основных элемента, каждый из которых несет ответственность.
- Activity и Fragment представляют слой View , который не имеет дело с бизнес-логикой и сложными операциями. Он только настраивает представление, обрабатывает взаимодействие с пользователем и, самое главное, наблюдает и LiveData элементы LiveData взятые из ViewModel .
- ViewModel автоматически наблюдает за состоянием Lifecycle представления, поддерживая согласованность во время изменений конфигурации и других событий жизненного цикла Android. Это также требуется представлением для извлечения данных из Repository , который предоставляется как наблюдаемые LiveData . Важно понимать, что ViewModel никогда не ссылается на View напрямую и что обновления данных всегда выполняются сущностью LiveData .
- Repository не является специальным компонентом Android. Это простой класс, без какой-либо конкретной реализации, который отвечает за выборку данных из всех доступных источников, из базы данных в веб-службы. Он обрабатывает все эти данные, обычно преобразовывая их в наблюдаемые LiveData и делая их доступными для ViewModel .
- База данных Room — это библиотека отображений SQLite, которая облегчает процесс работы с базой данных. Он автоматически записывает кучу шаблонов, проверяет ошибки во время компиляции и, самое главное, может напрямую возвращать запросы с наблюдаемыми LiveData .
Я уверен, что вы заметили, что мы много говорили о наблюдаемых. Шаблон наблюдателя является одной из основ элемента LiveData и компонентов, LiveData Lifecycle . Этот шаблон позволяет объекту уведомлять список наблюдателей о любых изменениях его состояния или данных. Поэтому, когда Activity наблюдает за сущностью LiveData , она будет получать обновления, когда эти данные претерпевают любые изменения.
Читайте также: