Шаблон MVC на Android

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

• Модель: Что делать
• Вид: Как сделать
• Контроллер: События, пользовательский ввод

Также подумайте об этом так: когда вы программируете свою модель, модели не нужно беспокоиться о рендеринге (или конкретном коде для платформы). Модель скажет на мнение, мне все равно, если ваш рендеринг - Android или iOS или Windows Phone, это то, что мне нужно, чтобы вы визуализировали. Вид будет обрабатывать только код рендеринга для платформы.

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

Действия, представления и действия на Android - это искушенный способ работы с Android UI и являются реализацией шаблона model-view-viewmodel (MVVM), который структурно похож (в том же семействе, что и) модель-view-controller.

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

После некоторого поиска наиболее разумным ответом является следующее:

MVC уже реализован в Android как:

• View = макет, ресурсы и встроенные классы, такие как Button, полученные из android.view.View.
• Controller = Activity
• Model = классы, реализующие логику приложения

(Это, кстати, не подразумевает логику домена приложения в действии.)

Самое разумное для маленького разработчика - следовать этому шаблону, а не пытаться делать то, что Google решил не делать.

PS Обратите внимание, что действие иногда перезапускается, поэтому нет места для данных модели (самый простой способ вызвать перезапуск - опустить android:configChanges="keyboardHidden|orientation" из XML и включить ваше устройство).

ИЗМЕНИТЬ

Мы можем говорить о MVC, но это будет так сказать FMVC, Framework - Model - View - Controller. Framework (ОС Android) накладывает свою идею жизненного цикла компонента и связанных с ним событий, и на практике Контроллер (Activity/Service/BroadcastReceiver) в первую очередь несет ответственность за то, чтобы справиться с этими событиями, основанными на Framework ( таких как onCreate()). Должен ли пользовательский ввод обрабатываться отдельно? Даже если это необходимо, вы не можете его разделить, события ввода-вывода также поступают с Android.

В любом случае, чем меньше кода, не специфичного для Android, вы помещаете в свой Activity/Service/BroadcastReceiver, тем лучше.

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

Но тем не менее, способ Android имеет дело с классами и ресурсами, иногда вы даже вынуждены следовать шаблону MVC. Более сложными, на мой взгляд, являются действия, которые иногда отвечают за представление, но тем не менее действуют одновременно в качестве контроллера.

Если вы определяете свои представления и макеты в файлах XML, загружайте свои ресурсы из папки res, и если вы избегаете более или менее смешать эти вещи в своем коде, то вы все равно следуете шаблону MVC.

Вы можете реализовать MVC в Android, но он не поддерживается "на месте" и требует определенных усилий.

Тем не менее, я лично склоняюсь к MVP как к более чистой архитектурной схеме для разработки Android. И, сказав MVP, я имею в виду следующее:

Я также опубликовал более подробный ответ здесь.

После игры с различными подходами к реализации MVC/MVP в Android я придумал разумный архитектурный шаблон, который я описал в этом сообщении: MVP и MVC Architectural Patterns в Android.

Лучший ресурс, который я нашел для реализации MVC на Android, - этот пост:

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

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

Я согласен с JDPeckham, и я считаю, что одного XML недостаточно для реализации части пользовательского интерфейса приложения.

Однако, если вы рассматриваете действие как часть представления, то реализация MVC довольно проста. Вы можете переопределить Application (как было возвращено функцией getApplication() в Activity), и здесь вы можете создать контроллер, который выживает на протяжении всей жизни вашего приложения.

(В качестве альтернативы вы можете использовать шаблон singleton, как это предлагается в документации по приложению)

Создание пользовательского интерфейса Android с использованием макетов, ресурсов, действий и намерений - это реализация шаблона MVC. Для получения дополнительной информации см. Следующую ссылку: http://www.cs.otago.ac.nz/cosc346/labs/COSC346-lab2.2up.pdf

зеркало для pdf

Архитектура MVC на AndroidЛучше следовать за любым MVP вместо MVC в android. Но все же в соответствии с ответом на вопрос это может быть решением

Описание и рекомендации

     Controller -
        Activity can play the role.
        Use an application class to write the
        global methods and define, and avoid
        static variables in the controller label
    Model -
        Entity like - user, Product, and Customer class.
    View -
        XML layout files.
    ViewModel -
        Class with like CartItem and owner
        models with multiple class properties
    Service -
        DataService- All the tables which have logic
        to get the data to bind the models - UserTable,
        CustomerTable
        NetworkService - Service logic binds the
        logic with network call - Login Service
Helpers -
        StringHelper, ValidationHelper static
        methods for helping format and validation code.
SharedView - fragmets or shared views from the code
        can be separated here

AppConstant -
        Use the Values folder XML files
        for constant app level

ПРИМЕЧАНИЕ 1:

Теперь вот волшебство, которое вы можете сделать. После того, как вы классифицировали фрагмент кода, напишите базовый класс интерфейса, например IEntity и IService. Объявите общие методы. Теперь создайте абстрактный класс BaseService и объявите свой собственный набор методов и разделите код.

ПРИМЕЧАНИЕ 2: Если ваша деятельность представляет несколько моделей, а не записывает код/​​логику в действие, лучше разделить представления на фрагменты. Тогда это лучше. Поэтому в будущем, если вам понадобится еще одна модель для отображения в представлении, добавьте еще один фрагмент.

ПРИМЕЧАНИЕ 3: Разделение кода очень важно. Каждый компонент архитектуры должен быть независимым, не имея зависимой логики. Если случайно, если у вас есть что-то зависящее от логики, тогда напишите между ними логический класс отображения. Это поможет вам в будущем.

Model View Controller (MVC)

Описание:

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

Шаблон MVC по существу таков:

• Модель: Что показывать. Это может быть источник данных (Ex: Server, Raw данные в приложении)
• Вид: как он отображается. Это может быть xml. Таким образом, он действует как презентационный фильтр. К своей модели (или модели) прикрепляется вид, и получает данные, необходимые для презентации.
• Контроллер: обработка событий, таких как ввод данных пользователем. Это будет деятельность

Важная функция MVC: Мы можем изменить либо модель, либо представление или контроллер, все еще не влияющие на другие

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

Хотя этот пост, кажется, старый, я хотел бы добавить следующие два, чтобы сообщить о недавней разработке в этой области для Android:

android-binding. Предоставление инфраструктуры, которая обеспечивает привязку виджетов виджетов к модели данных. Он помогает внедрять шаблоны MVC или MVVM в приложениях для Android.

roboguice - RoboGuice берет догадки из разработки. Внесите свой вид, ресурс, системное обслуживание или любой другой объект, и пусть RoboGuice позаботится о деталях.

Шаблон Android MVC (вид) реализован с помощью классов Adapter. Они заменяют контроллер "адаптером". Описание состояния адаптера:

Объект Adapter действует как мост между AdapterView и базовые данные для этой точки зрения.

Я просто рассматриваю это приложение для Android, которое читает из базы данных, поэтому я не знаю, насколько хорошо он работает. Однако это похоже на архитектуру Qt Model-View-Delegate, которая, по их утверждению, является шагом от традиционного шаблона MVC. По крайней мере, на ПК образец Qt работает достаточно хорошо.

Я думаю, что самое полезное упрощенное объяснение здесь: http://www.cs.otago.ac.nz/cosc346/labs/COSC346-lab2.2up.pdf

Из всего остального, что я видел и читал здесь, реализация всех этих вещей делает его сложнее и не очень хорошо вписывается в другие части андроида.

При наличии активности другие слушатели уже являются стандартным способом Android. Самым безобидным способом было бы добавить Java Observer, например, слайды, описать и сгруппировать onClick и другие типы действий в функции, которые все еще находятся в Activity.

Способ Android - это то, что Activity выполняет оба действия. Борьба с ним на самом деле не упрощает расширение или дальнейшее кодирование в будущем.

Я согласен с вторым сообщением. Это уже реализовано, просто не так, как люди привыкли. Независимо от того, находится ли он в том же файле или нет, уже существует разделение. Нет необходимости создавать дополнительное разделение, чтобы он соответствовал другим языкам и ОС.

Будучи усталым от катастрофы MVx на Android, я недавно создал крошечную библиотеку, которая обеспечивает однонаправленный поток данных и похожа на концепцию MVC: https://github.com/zserge/anvil

В принципе, у вас есть компонент (активность, фрагмент и группа просмотра). Внутри вы определяете структуру и стиль слоя вида. Также вы определяете, как данные должны привязываться к представлениям. Наконец, вы можете связать слушателей в одном месте.

Затем, как только ваши данные будут изменены, вызывается глобальный метод render(), и ваши представления будут обновлены с последними данными.

Здесь пример компонента, имеющего все внутри для компактности кода (конечно, модель и контроллер можно легко разделить). Здесь "count" - это метод model, view() - это представление, а "v → count ++" - это контроллер, который прослушивает нажатие кнопки и обновляет модель.

public MyView extends RenderableView {
  public MyView(Context c) {
      super(c);
  }

  private int count = 0;

  public void view() {
    frameLayout(() -> {              // Define your view hierarchy
      size(FILL, WRAP);
      button(() -> {
          textColor(Color.RED);      // Define view style
          text("Clicked " + count);  // Bind data
          onClick(v -> count++);     // Bind listeners
      });
    });
  }

С разделенной моделью и контроллером она будет выглядеть так:

button(() -> {
   textColor(Color.RED);
   text("Clicked " + mModel.getClickCount());
   onClick(mController::onButtonClicked);
});

Здесь, на каждой кнопке, номер увеличивается, тогда будет вызываться "render()", и текст кнопки будет обновлен.

Синтаксис становится более приятным, если вы используете Kotlin: http://zserge.com/blog/anvil-kotlin.html. Кроме того, существует альтернативный синтаксис для Java без lambdas.

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

(Отказ от ответственности: я являюсь автором этой библиотеки)

Существует не реализованная MVC-архитектура, но существует множество библиотек/примеров для реализации архитектуры MVP (модель-представление-презентатор).

Пожалуйста, проверьте эти ссылки:

• https://github.com/sockeqwe/mosby

• https://github.com/android10/Android-CleanArchitecture

• https://github.com/antoniolg/androidmvp

Google добавил пример архитектуры Android MVP:

• https://github.com/googlesamples/android-architecture

Согласно объяснение, которое объяснила команда Xamarin (на iOS MVC "Я знаю, что это странно, но подождите секунду" )

• Модель (логика данных или приложений),
• Вид (пользовательский интерфейс) и
• Контроллер (код позади).

Я могу сказать следующее:

Модель на Android - это просто решающий объект. Представление представляет собой XML-макет, а контроллер - это (действие + его фрагмент).

* Это только мое мнение, а не какой-либо ресурс или книга.

Я видел, что многие люди говорят, что MVC уже реализован в Android, но это не так. По умолчанию Android не следует за MVC.

Потому что я не Google никогда не будет насильно навязывать ограничения реализации MVC, такие как iPhone, но его до разработчиков, которые хотят или хотят их в своем проекте. В небольших или простых приложениях обычно использовать MVC не требуется, а как приложение растет и усложняется и требует модификации своего кода в последующие годы, тогда возникает потребность в шаблоне MVC в Android.

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

http://www.therealjoshua.com/2011/11/android-architecture-part-1-intro/

Но в настоящее время я считаю, что MVP вместе с Android Architectural Pattern является одним из лучших разработчиков, которые разработчики должны использовать для чистых и надежных приложений для Android.

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

В MVC уровень просмотра знает, как показывать пользовательский интерфейс (UI). Если для этого нужны какие-либо данные, он получает его из слоя модели. Но View НЕ обращается непосредственно к модели, чтобы найти данные, она делает это через контроллер. Таким образом, контроллер вызывает модель для предоставления требуемых данных для представления. После того, как данные готовы, Контроллер информирует View, что данные готовы к приобретению из Модели. Теперь представление может получить данные из Модели.

Этот поток можно суммировать следующим образом:

Стоит отметить, что View может знать о доступности данных в Модели либо через Controller, также известный как Passive MVC, либо путем наблюдения за данными в Модели путем регистрации наблюдаемых на ней, которые являются активными MVC.

На части реализации одной из первых вещей, которая приходит на ум, является то, какой компонент Android должен использоваться для представления? Activity или Fragment?

Ответ заключается в том, что это не имеет значения, и оба могут быть использованы. В представлении должен быть представлен пользовательский интерфейс (UI) на устройстве и отвечать на взаимодействие пользователя с пользовательским интерфейсом. Для этого требуются как Activity и Fragment.

В примере приложения, используемого в этой статье, я использовал Activity для слоя View, но Fragment также можно использовать.

Полный пример приложения можно найти в "Mvc" ветки моего GitHub репо здесь.

Я также рассмотрел все плюсы и минусы архитектуры MVC в android на примере здесь.

Для тех, кто заинтересован, я начал серию статей о Android App архитектуре здесь, в которой я сравнить различные архитектуры, т.е. MVC, MVP, MVVM, для развития Android App через полное рабочее приложение.

Когда мы применяем MVC, MVVM или Модель представления в Android-приложение, нам действительно нужно иметь четкий структурированный проект и, что более важно, для модульных тестов.

В настоящий момент, без сторонней структуры, у вас обычно есть много кода (например, addXXListener(), findViewById() и т.д.), который не добавляет никакого бизнес-значения.

Что еще нужно, вы должны запускать тесты для Android, а не обычные тесты JUnit, которые требуют времени для запуска и делают блок-тесты несколько непрактичными. По этим причинам несколько лет назад мы начали проект с открытым исходным кодом, RoboBinding - структура модели Presentation-binding для платформы Android.

RoboBinding помогает вам писать код пользовательского интерфейса, который легче читать, тестировать и поддерживать. RoboBinding устраняет необходимость ненужного кода, такого как addXXListener или так, и переносит логику пользовательского интерфейса на модель представления, которая является POJO и может быть протестирована с помощью обычных тестов JUnit. RoboBinding поставляется с более чем 300 тестов JUnit для обеспечения его качества.

Model-View-Controller в Android Примерно в 2011 году, когда Android стал все более популярным, естественно возникли вопросы архитектуры. Поскольку MVC был одним из самых популярных шаблонов пользовательского интерфейса в то время, разработчики также пытались применить его к Android.

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

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

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

в другом слове

Модели: контент-провайдеры. Менеджеры данных, которые являются рекомендуемой формой совместного использования данных между приложениями.

Просмотров: Деятельность. Это компонент основного пользовательского интерфейса приложения. Каждый отдельный экран приложения для Android выводится из класса Activity Java (android.app.Activity). Они являются контейнерами для Views (android.view.View).

Контроллеры: службы. Это фоновые компоненты, которые ведут себя как демоны UNIX и службы Windows. Они работают невидимо и выполняют непрерывную обработку без обслуживания.