Как организовать передачу данных из Activity в Presenter используя MVP?
Привет. Пытаюсь реализовать MVP в своем приложении. Не могу понять как правильно передавать данные из activity в presenter (например введенный текст из edit text). Тут говорится что activity должна только уведомлять presenter о том, что данные введены, а решение об их получении должен принять presenter. Т.е. сейчас, условно, на ввод текста в edit text, activity должна вызвать presenter.textReceived() и потом в presenter view.getText().
При таком подходе, мне приходится создавать промежуточные переменные в activity. К примеру, получаю время из кастомного DatePickerDialog, используя интерфейс OnTimeSetListener в activity, сохраняю результат в переменной. Потом уведомляю presenter об получении времени и в presenter вызываю view.getTime().
Насколько правильный такой подход? Какие еще решения используются на практике?
Спасибо!
- Вопрос задан более трёх лет назад
- 453 просмотра
Комментировать
Решения вопроса 1
Сергей @red-barbarian
Не надо хранить промежуточные данные. Презентер сразу получает данные от вьюхи. presenter.setTime(time)
Затем презентер принимает решение, что с ними делать и если отображать то вызывает view.update(time)
Кстати, обязательно разделяйте презентер и активити интерфейсом.
Ответ написан более трёх лет назад
Комментировать
Нравится 1 Комментировать
Ответы на вопрос 0
Ваш ответ на вопрос
Войдите, чтобы написать ответ
- Android
Можно ли редактировать prop в таком состоянии?
- 1 подписчик
- 16 часов назад
- 26 просмотров
- Android
- +4 ещё
Как получить доступ к накопителю телефона, у которого чёрный экран и не работает сенсор?
- 1 подписчик
- 19 часов назад
- 126 просмотров
Что такое MVP, и как создать минимально жизнеспособный продукт
Чтобы добиться успеха с минимальными рисками и затратами в условиях, где закрывается 92% запущенных стартапов, каждый проект стоит начинать с запуска минимально жизнеспособного продукта. В этой статье мы разберем понятие, типы и этапы построения MVP.
MVP — подробное руководство по созданию минимально жизнеспособного продукта
Согласно исследованию CB Insights, в 42% случаев причиной провала стартапа становится отсутствие рыночного спроса. Почти в половине случаев предприниматели тратят месяцы и даже годы работы лишь затем, чтобы осознать, что гипотеза была ошибочной, и никто не заинтересован в их продукте.
Концепция MVP (Minimum Viable Product) — разработана, чтобы минимизировать риск такой ситуации. Она применима для создания любого продукта, но чаще используется для разработки программного обеспечения и цифровых сервисов.
Понятие MVP ввел в оборот в 2001 году Фрэнк Робинсон (Frank Robinson), соучредитель и президент консалтинговой фирмы SyncDev. Робинсон определяет MVP, как результат «синхронной разработки» — одновременного развития продукта и исследования целевой аудитории, ее реакции на продукт. MVP — такая версия будущего проекта, которая позволяет собрать максимум практических данных о том, как с ним взаимодействуют клиенты, при минимальных затратах.
Отличия MVP от PoC
MVP часто путают с PoC — Proof of Concept — доказательством правильности концепции. Эти понятия взаимосвязаны, но не равнозначны. В качестве PoC выступают: реакция потенциальных клиентов на анонс, число предзаказов, маркетинговые и социологические исследования и другие теоретические свидетельства того, что будущий продукт интересен рынку. MVP — больше, чем доказательство, это — работоспособный продукт.
Отличия MVP от прототипа
Вместе с тем, MVP — не прототип. Минимально жизнеспособный продукт содержит только самую необходимую функциональность, но он не должен быть сырым или примитивным. Напротив, основную функцию MVP должен выполнять как можно лучше.
Задачи MVP
Minimum Viable Product создается не для тестирования технологий, а чтобы проверить на практике, нужен ли пользователям такой продукт, верны ли гипотезы, лежащие в основе бизнес-модели. Главная задача MVP — минимизировать время и усилия, затраченные на тестирование реакции рынка на идею.
MVP позволяет привлечь к проекту реальных пользователей в качестве проводников, которые помогут скорректировать бизнес-модель и базовые характеристики будущего продукта, наметить направления развития и спланировать дорожную карту обновлений. Положительные результаты на стадии MVP дают зеленый свет для разработки полной версии продукта.
Пример MVP
Показательный пример MVP — мессенджер WhatsApp, который в момент публикации в 2009 году не имел функций для отправки сообщений.
Создатели WhatsApp — Ян Кум (Jan Koum) и Брайан Эктон (Brian Acton) исходили из простой идеи — создать мобильную телефонную книгу, которая бы показывала статус контакта: доступен, занят, на совещании, за рулем, в спортзале и так далее. Когда пользователи указывали статус, их контакты получали всплывающее уведомление.
Вскоре Кум и Эктон заметили, что пользователи стали использовать статусы для общения. Ухватившись за эту идею, они выпустили новую версию WhatsApp, в которой было больше функций, связанных с отправкой сообщений. В результате небольшая пользовательская база в считанные дни выросла до 250 000 человек, доказав, что разработчики на верном пути.
Преимущества MVP
Таким образом, минимально жизнеспособный продукт позволяет:
- подтвердить жизнеспособность идеи и проверить гипотезы о продукте с помощью реальных данных;
- выявить тенденции, которые можно использовать при разработке полной версии продукта;
- снизить риск крупных финансовых потерь в случае выпуска неудачного продукта;
- сократить стоимость разработки за счет приоритизации важных и выявления невостребованных функций;
- ускорить поиск ошибок и внутреннее тестирование продукта;
- собрать базу пользователей перед полномасштабным запуском;
- занять рыночную нишу и привлечь инвесторов раньше конкурентов.
Разновидности MVP
Среди многочисленных подходов к созданию Minimum Viable Product выделяют три основных подхода.
1. Продукт с единственным параметром
Наиболее распространенный вариант создания MVP уже был описан на примере WhatsApp. Это приложение или программа, выполняющие одну-две функции, которые необходимы для проверки жизнеспособности вашей идеи. Если основная функциональность приложения неинтересна пользователям, то продолжать вкладывать в разработку силы, время и ресурсы бессмысленно.
2. Разрозненный MVP
Этот подход применяют, если идею продукта можно реализовать без разработки уникальных программных решений, при помощи набора готового программного обеспечения.
Объединение различных инструментов в единый комплекс и, тем более, разработка оригинального ПО — делают тестирование бизнес-идеи трудозатратным и дорогостоящим. Иногда к этим стадиям разработки стоит переходить уже после получения обратной связи от пользователей.
Так запустился сервис Groupon. На старте он представлял собой лишь примитивный сайт на основе открытого исходного кода. Все услуги Groupon оказывал по электронной почте. Социальные функции, полноценная email-рассылка, автоматизация, мобильное приложение — все это было разработано потом, когда стало ясно, что коллективные покупки востребованы.
3. Волшебник страны Оз и консьерж
Эти близкие разновидности Minimum Viable Product подразумевают отказ от длительной и дорогостоящей разработки в пользу ручного труда.
Герой сказки Фрэнка Баума (Lyman Frank Baum) изображал из себя волшебника, а MVP этого типа притворяются полнофункциональными сервисами и приложениями. На деле же, вместо алгоритмов работу Minimum Viable Product обеспечивают люди.
Волшебник страны Оз не афиширует этот факт. Так поступал основатель Zappos — крупного американского интернет-магазина. Чтобы убедиться в жизнеспособности идеи, он начал продажи задолго до того, как автоматизировал заказы и даже арендовал склады. Первых клиентов Ник Свинмурн (Nick Swinmurn) обслуживал лично, приобретая товары со скидками в рознице и перепродавая их.
Отличие продуктов, построенных по консьерж-модели, в том, что они открыто позиционируются, как предоставляющие услуги реальных людей, и используют этот факт, как одно из конкурентных преимуществ.
Создание MVP: пошаговое руководство
Чтобы запустить минимально жизнеспособный продукт, необходимо пройти через восемь подготовительных этапов. Первые четыре шага нацелены на предварительное уточнение бизнес-идеи. Пятый и шестой этапы касаются проектирования продукта, и только на седьмом и восьмом пунктах дело дойдет непосредственно до разработки и тестирования.
1. Сформулируйте задачу
Каждый продукт создается для решения некой задачи, и речь не о получении прибыли. Здесь требуется клиентоориентированный подход. Для чего пользователю нужен продукт?
Внятно сформулировав ответ, вы получите представление о задаче продукта и о его ценности для пользователя. Так, открывая сервис для краткосрочной аренды парковочных мест, вы решаете проблему, с которой сталкиваются все водители, — облегчаете поиск места, где можно оставить машину.
2. Определите аудиторию и выделите ее ядро
Ориентироваться на потребности широкой аудитории при проектировании MVP — ошибочная стратегия. Сужение целевой аудитории позволяет точнее ориентировать будущий продукт. Для этого необходимо сформулировать портрет «идеального» пользователя, человека, который без раздумий купит ваше решение и останется доволен его возможностями.
Обычно в такой портрет включают информацию о возрасте пользователя, уровне образования, доходах, привычках, интересах и увлечениях. Эти детали необходимы, чтобы понять, насколько хорошо продукт подходит будущему пользователю, и помогут позднее, на этапе рекламы и продвижения.
3. Изучите конкурентов
Даже если вы придумали нечто новое, найдутся компании, которые уже действуют в выбранной отрасли. Их опыт, преимущества и недостатки стоит внимательно изучить. Выясните, какова их доля на рынке, зачем к ним приходят клиенты и что делает их уникальными. Эти подробности помогут скорректировать MVP.
4. Проведите SWOT-анализ
Этот метод стратегического планирования используется крупными компаниями для принятия управленческих решений и формирования бизнес-политики с 1963 года. И хотя обычно он используется в куда большем масштабе, SWOT-анализ хорошо подходит для определения сильных и слабых сторон, возможностей и угроз для минимально жизнеспособного продукта.
5. Составьте карту путей
После фундаментального анализа бизнес-идеи самое время взглянуть на будущий продукт с точки зрения пользователя. Карта путей — тот порядок действий, который пользователь совершает, чтобы достигнуть своей цели, например, приобрести товар или найти и арендовать парковочное место.
Этот путь должен быть не просто максимально коротким, но и простым и удобным. Продумав, как пользователь взаимодействует с будущим приложением, вы поймете, на какой стадии предоставить дополнительную информацию, где добавить подсказку и как оптимально спроектировать интерфейс.
6. Выделите основные функции для реализации и рассчитайте объем MVP
Каким бы масштабным ни был задуманный проект, для MVP необходимо перечислить и приоритезировать его функции. При создании Minimum Viable Product предпочтение отдается тем из них, что непосредственно связаны с основной целью будущего продукта.
Введение дополнительных возможностей в прототип только запутает пользователей и снизит достоверность результатов исследования бизнес-идеи. Их можно добавлять уже после развертывания MVP, сбора и анализа первичной обратной связи.
7. Выберите подходящую методологию и разработайте MVP
Определив объем, порядок и направление работ, можно приступить к разработке минимального жизнеспособного продукта.
От того, как именно будет построен процесс разработки, во многом зависит результат. Для MVP принципиально важно использовать один из итеративных подходов к разработке. Lean, Scrum, Kanban, экстремальное программирование — все они позволяют наладить регулярный выпуск обновлений, совершенствовать продукт «на ходу», по мере поступления обратной связи. Выбор конкретной методологии зависит от предпочтений команды разработчиков и особенностей конкретного проекта.
8. Протестируйте продукт
Минимально жизнеспособному продукту требуется регулярное тестирование на всем протяжении разработки. Альфа-тестирование проводится внутри команды силами тестировщиков, но для бета-тестирования потребуется помощь посторонних. Хорошо, если это будут люди из числа будущих пользователей. Желающих поучаствовать в тесте можно найти на таких сайтах, как BetaList, ProductHunt, Reddit, Quora или привлечь через собственные каналы связи: социальные сети, блоги и email-рассылку.
Основной задачей тестирования будет техническое совершенствование MVP. Перед выпуском продукт должен работать без ошибок, чтобы проблемы технического характера не помешали пользователям оценить его функциональность.
Запуск минимально жизнеспособного продукта
Для команды проекта работа еще только начинается. С момента запуска необходимо собирать, сохранять и анализировать обратную связь, начиная со статистики и заканчивая данными о поведении и отзывами пользователей. Эта информация — то, ради чего все затевалось.
Данные, собранные при помощи MVP, позволят понять, есть ли у проекта перспективы, помогут сгенерировать новые идеи и разработать стратегию развития продукта, основанную, не на предположениях, а на фактах. Таким образом, MVP тестирование полностью себя оправдает.
Наш опыт позволяет нам оценивать полученные данные и анализировать фидбек от клиентов. Мы понимаем, что запустить MVP, протестировать продукт и обработать обратную связь — сложные и затратные задачи, которые требуют профессионального подхода.
Если вы запускаете новый продукт и не знаете с чего начать — свяжитесь с нами через форму обратной связи, и мы поможем реализовать ваш проект.
Android MVP пример для начинающих. Без библиотек и интерфейсов.
В этом посте описывается несложный пример MVP, без использования запутывающих интерфейсов и сложных библиотек.
Что такое MVP
Сначала немного теории о MVP. Схематично это выглядит так:
MVP расшифровывается как Model-View-Presenter (модель-представление-презентер). Если рассматривать Activity, которое отображает какие-то данные с сервера, то View — это Activity, а Model — это ваши классы по работе с сервером. Напрямую View и Model не взаимодействуют. Для этого используется Presenter.
Если в Activity пользователь нажал кнопку Обновить, то Activity сообщает об этом презентеру. При этом Activity не просит презентер загрузить данные. Оно просто сообщает, что пользователь нажал кнопку Обновить. А презентер уже сам решает, что по нажатию этой кнопки надо делать. Он запрашивает данные у модели и передает их в Activity, чтобы отобразить на экране.
Если экран отображает данные из базы данных, то модель — это база данных. Презентер может подписаться на уведомления модели об обновлении. В случае, когда данные в БД изменятся, модель оповестит об этом презентер. Презентер получит эти изменения и передаст их в Activity.
Можно сказать, что презентер — это логика, вынесенная из Activity в отдельный класс. А Activity остается для отображения данных и взаимодействия с пользователем. Если вы решили сделать другое Activity для отображения данных, то вам уже не нужно будет переносить логику в новое Activity, можно будет использовать готовый Presenter. А если вы решили поменять логику, то вам не нужно будет лезть в Activity и там, среди кода, который отвечает за отображение данных и взаимодействие с пользователем, искать логику и менять ее. Вы меняете код в презентере.
Важное замечание! Пример реализации, который мы сейчас будем рассматривать, не является единственно правильным вариантом, выполненным по канонам MVP. В разных случаях могут быть шаги влево и вправо. Но общую концепцию этот пример отражает.
Практика
Я создал небольшое приложение и залил на гитхаб.
Приложение умеет добавлять, хранить и отображать список пользователей.
Чтобы наглядно показать отличие MVP, я сделал этот экран в двух вариантах: Activity и MVP. Вы можете выбрать нужный вариант при запуске:
Оба этих режима внешне будут выглядеть и работать одинаково, но «под капотом» они разные.
Первый вариант реализован с помощью одного Activity — SingleActivity. В нем реализовано следующее:
— вывод информации на экран и обработка нажатий
— логика (что делать по нажатию на кнопки и что/когда показывать)
— работа с базой данных.
Такой вариант реализации считается тяжелым и неудобным. Слишком много всего возложено на один класс.
Второй вариант реализован с помощью MVP — mvp.
В этом варианте я просто разделил код из SingleActivity на три класса в соответствии с MVP:
— в UsersModel — работа с базой данных (Model)
— в UsersActivity — вывод информации на экран и обработка нажатий (View)
— в UsersPresenter — логика (Presenter)
Давайте немного пройдемся по ключевым моментам кода. Сначала рекомендую вам посмотреть код SingleActivity, чтобы понять основные механизмы работы приложения. А я дальше буду описывать, как это было разделено по разным классам.
UsersModel
Это Model (модель). В модели обычно реализована работа с данными, например: запрос данных с сервера, сохранение в БД, чтение файлов и т.п.
Здесь находятся все операции с базой данных. Этот класс имеет три public метода, которые вызываются презентером:
loadUsers — получение списка пользователей из БД
addUsers — добавление пользователя в БД
clearUsers — удаление всех пользователей из БД
Что происходит внутри этих методов — касается только модели. Презентер будет просто вызывать эти методы и его не должно интересовать, как именно они реализованы.
Методам на вход можно передавать колбэки, которые будут вызваны по окончанию операции. Асинхронность работы с БД реализована с помощью AsyncTask. В методы добавления и удаления добавлены секундные паузы для наглядности.
UserActivity
Это View (представление). Представление отвечает за отображение данных на экране и за обработку действий пользователя.
Здесь есть несколько public методов, вызываемых презентером:
getUserData — получение данных, введенных пользователем
showUsers — отображение списка пользователей
showToast — отображение Toast
showProgress/hideProgress — скрыть/показать прогресс-диалог
В представлении не должно быть никакой логики. Это только инструмент для отображения данных и взаимодействия с пользователем.
Действия пользователя передаются в презентер. Обратите внимание на обработчики для кнопок Add и Clear. По нажатию на них, представление сразу сообщает об этом презентеру. И презентер уже будет решать, что делать.
Повторюсь, т.к. очень важно понимать это правильно. По нажатию на кнопки, Activity не просит презентер добавить пользователя или удалить всех пользователей. Т.е. оно не указывает презентеру, что ему делать. Оно просто сообщает, что была нажата кнопка Add или Clear. А презентер принимает это к сведению и действует по своему усмотрению.
UsersPresenter
Это Presenter (презентер). Он является связующим звеном между представлением и моделью, которые не должны общаться напрямую.
От представления презентер получает данные о том, какие кнопки были нажаты пользователем, и решает, как отреагировать на эти нажатия. Если надо что-то отобразить, то презентер сообщает об этом представлению. А если нужно сохранить/получить данные, он использует модель.
Давайте по шагам рассмотрим взаимодействие представления, презентера и модели на нашем примере. Возьмем сценарий добавления новых данных в базу.
1) Пользователь вводит данные в поля ввода. Это никак не обрабатывается и ничего не происходит.
2) Пользователь жмет кнопку Add. Вот тут начинается движ.
3) Представление сообщает презентеру о том, что была нажата кнопка Add.
4) Презентер просит представление дать ему данные, которые были введены пользователем в поля ввода.
5) Презентер проверяет эти данные на корректность.
6) Если они некорректны, то презентер просит представление показать сообщение об этом.
7) Если данные корректны, то презентер просит представление показать прогресс-диалог и просит модель добавить данные в базу данных.
8) Модель асинхронно выполняет вставку данных и сообщает презентеру, что вставка завершена
9) Презентер просит представление убрать прогресс-диалог.
10) Презентер просит свежие данные у модели.
11) Модель возвращает данные презентеру.
12 Презентер просит представление показать новые данные.
Из этой схемы видно, что презентер рулит всем происходящим. Он раздает всем указания, решает, что делать и как реагировать на действия пользователя.
Обратите внимание на методы презентера: attachView и detachView. Первый дает презентеру представление для работы, а второй говорит, что представление надо отпустить. Эти методы вызывает само представление. Первый метод — после своего создания, а второй — перед своим уничтожением. Иначе, если презентер будет держать ссылку на представление после его официального уничтожения, то может возникнуть утечка памяти.
Метод viewIsReady вызывается представлением, чтобы сообщить о том, что представление готово к работе. Презентер запрашивает у модели данные и просит представление отобразить их.
Плюсы MVP
Кратко напишу преимущества MVP по сравнению с Activity.
— легче писать тесты
— в небольших классах искать что-либо и вносить изменения легче, чем в одном большом
— бывает так, что одно представление используется разными презентерами, или наоборот — один презентер используется для разных представлений. Если у вас все в одном Activity — вы не сможете так сделать.
Все плюсы вытекают из того, что вместо одного класса, мы используем несколько.
Что дальше?
Я создал этот пример, чтобы максимально просто показать реализацию MVP. Реальный рабочий пример будет содержать несколько важных дополнений. Кратко расскажу о них, чтобы вы представляли себе, куда двигаться дальше.
Интерфейсы.
Это то, что очень запутывает новичков в примерах MVP, но действительно является очень полезным инструментом.
Обратите внимание на взаимодействие презентера и представления в нашем примере. У представления есть несколько методов, которые вызывает презентер: getUserData, showUsers, showToast, showProgress, hideProgress. Вот эти методы — это все что должен знать презентер. Ему не нужны больше никакие знания о представлении. А в текущей реализации презентер знает, что его представление — это UsersActivity. Т.е. это целое Activity с кучей методов, которые презентеру знать незачем. Использование интерфейсов решает эту проблему.
Мы можем создать интерфейс UsersContractView
interface UsersContractView < UserData getUserData(); void showUsers(Listusers); void showToast(int resId); void showProgress(); void hideProgress(); >
Добавить этот интерфейс в UsersActivity
public class UsersActivity extends AppCompatActivity implements UsersContractView
Теперь в презентере можно убрать все упоминания о UsersActivity, и оставить только UsersContractView.
public class UsersPresenter < private UsersContractView view; public void attachView(UsersContractView view) < this.view = view; >. >
Плюс такого похода в том, что теперь в этом презентере вы можете использовать любое представление, которое реализует интерфейс UsersContractView. И вам не придется ничего менять в презентере.
А если презентер завязан на конкретный класс, например, UsersActivity, то при замене представления, вам придется открыть презентер и поменять там UsersActivity на другой класс.
Асинхронные операции
Для реализации асинхронности я здесь использовал AsyncTask. Но не помню, когда последний раз использовал его в рабочем коде. Обычно используются различные библиотеки, которые удобнее в использовании, гибче и дают больше возможностей. Например — RxJava.
Создание объектов
В UsersActivity мы создаем презентер следующим образом:
DbHelper dbHelper = new DbHelper(this); UsersModel usersModel = new UsersModel(dbHelper); presenter = new UsersPresenter(usersModel);
Это не очень хорошая практика. Рекомендуется не создавать объекты внутри вашего класса, а получать их уже готовыми снаружи. Для реализации этого принципа существуют различные библиотеки. Самый распространенный пример — это библиотека Dagger 2.
Поворот экрана
В этом примере нет обработки поворота экрана. Если ваш презентер выполняет какую-то долгую операцию, и вы повернете экран, у вас просто создастся новый презентер, а результаты работы старого презентера могут быть потеряны.
Есть различные способы, как этого избежать. Один из них — не пересоздавать презентер, если представление пересоздается. При этом, презенетер отпускает старое представление (метод detachView), и получает новое представление (метод attahcView). В итоге, результаты работы долгой операции будут отображены уже в новом представлении.
Если тема MVP стала вам интересна, то посмотрите этот пример. Он посложнее и более приближен к реальному коду.
Присоединяйтесь к нам в Telegram:
— в канале StartAndroid публикуются ссылки на новые статьи с сайта startandroid.ru и интересные материалы с хабра, medium.com и т.п.
— в чатах решаем возникающие вопросы и проблемы по различным темам: Android, Compose, Kotlin, RxJava, Dagger, Тестирование, Performance
— ну и если просто хочется поговорить с коллегами по разработке, то есть чат Флудильня
Как связать Fragment и DialogFragment в MVP
Есть MainFragment , который содержит описание товара. Если пользователь хочет добавить комментарий к товару, то он делает это в DialogFragment (открытом из MainFragment ) и потом комментарий передается в MainFragment . Насколько я понял, при MVP для обоих фрагментов нужен свой Presenter , но я не понимаю, как правильно наладить связь между ними, чтобы DialogPresenter для DialogFragment передал комментарий в MainPresenter для MainFragment . Можно ли передавать MainPresenter в конструкторе для DialogFragment или передавать его через интерфейс, чтобы DialogPresenter мог к нему обратиться или есть какой-то другой, правильный путь?
Отслеживать
11.7k 9 9 золотых знаков 28 28 серебряных знаков 40 40 бронзовых знаков
задан 25 ноя 2019 в 9:59
13 3 3 бронзовых знака
1 ответ 1
Сортировка: Сброс на вариант по умолчанию
Если рассматривать диалоговое окно как самостоятельное View , то лучше создать для него отдельный Presenter . А, модель пусть будет та же самая.
Если используете LiveData, то при изменении комментария в диалоговом окне, данные автоматически обновятся и в основном View .
Отслеживать
ответ дан 25 ноя 2019 в 10:19
11.7k 9 9 золотых знаков 28 28 серебряных знаков 40 40 бронзовых знаков
Поправьте, если я неправильно понял. Мне надо создать модель в главном фрагменте и передать ее в диалог, откуда уже я помещаю эту модель в Presenter для диалога. И при этом Presenter ‘ы для каждого View не должны между собой общаться?
25 ноя 2019 в 12:33
По хорошему, Вам нужно передать в диалог только id товара, а MVP стек диалога (если так можно сказать) вытащит из БД модель и обновит её в БД при изменении комментария.