Size: a a a

Android Architecture

2020 March 03

I

Igor in Android Architecture
мне нрав примеры Фернандо, максимально близко к боевым
источник

МE

Михаил E1ement in Android Architecture
Igor
мне нрав примеры Фернандо, максимально близко к боевым
У Фернандо интерактор наследуется от usecase и через di прокидывается в презентер. Второй момент, почему у меня не взлетели usecase - это 1 execute, т.е. 1 поход в репу, а если нужно цепочку сделать rx, то в презентере получается лестница их compositeDisposible. У тебя есть на что посмотреть более сложное, но по канонам Фернандо?
источник

I

Igor in Android Architecture
Михаил E1ement
У Фернандо интерактор наследуется от usecase и через di прокидывается в презентер. Второй момент, почему у меня не взлетели usecase - это 1 execute, т.е. 1 поход в репу, а если нужно цепочку сделать rx, то в презентере получается лестница их compositeDisposible. У тебя есть на что посмотреть более сложное, но по канонам Фернандо?
так, что-то новое... или я что-то уопустил
источник

I

Igor in Android Architecture
источник

МE

Михаил E1ement in Android Architecture
Igor
так, что-то новое... или я что-то уопустил
Упустил, я скоро по этому примеру диссертацию защищу, проштудировал весь
источник

RM

Ruslan Mingaliev in Android Architecture
Михаил E1ement
У Фернандо интерактор наследуется от usecase и через di прокидывается в презентер. Второй момент, почему у меня не взлетели usecase - это 1 execute, т.е. 1 поход в репу, а если нужно цепочку сделать rx, то в презентере получается лестница их compositeDisposible. У тебя есть на что посмотреть более сложное, но по канонам Фернандо?
а почему 1 execute = 1 поход в репу?
источник

I

Igor in Android Architecture
Михаил E1ement
Упустил, я скоро по этому примеру диссертацию защищу, проштудировал весь
Тот пример, что по ссылке выше? или тот, что с MVP пятилетней давности?
источник

МE

Михаил E1ement in Android Architecture
Igor
Тот пример, что по ссылке выше? или тот, что с MVP пятилетней давности?
А вот походу старый копал. Это новый, для котлина, в нем нет этих болячек? Если да, то спасибо
источник

I

Igor in Android Architecture
это переосмысление Clean для Андроид
источник

МE

Михаил E1ement in Android Architecture
Igor
Тот пример, что по ссылке выше? или тот, что с MVP пятилетней давности?
Я раньше видел статью, но отложил ее до следующего проекта, который будет на котлине. Ещё раз спасибо
источник

RM

Ruslan Mingaliev in Android Architecture
Михаил E1ement
А вот походу старый копал. Это новый, для котлина, в нем нет этих болячек? Если да, то спасибо
В чем болячка то? В старых примерах UseCase возвращает Observable. Observable можно мержить друг с другом, ходить в сначала в один репозиторий, потом в другой, потом производить какие-то операции.
источник

МE

Михаил E1ement in Android Architecture
Ruslan Mingaliev
В чем болячка то? В старых примерах UseCase возвращает Observable. Observable можно мержить друг с другом, ходить в сначала в один репозиторий, потом в другой, потом производить какие-то операции.
Там в usecase уже шел subscribe от rx, второй момент, что на экране нужно N вообще разных usecase, от каждого из которых наследуется интерактор. И тут в презентере будет интеракторХел. Опять же, если есть что посмотреть более менее сложное, то пожалуйста, киньте ссылкой
источник

RM

Ruslan Mingaliev in Android Architecture
Михаил E1ement
Там в usecase уже шел subscribe от rx, второй момент, что на экране нужно N вообще разных usecase, от каждого из которых наследуется интерактор. И тут в презентере будет интеракторХел. Опять же, если есть что посмотреть более менее сложное, то пожалуйста, киньте ссылкой
Если размышлять в этом ключе, то хелл будет в презентере, либо в раздутом на тонны методов интеракторе. Имхо первый вариант лучше. Более того, никто не заставляет реализовывать юзкейс таким образом (возвращать Observable). Там написано у него было, что юз кейс - это просто контракт, который подходит всем его интеракторам в конкретно его примере.
источник

МE

Михаил E1ement in Android Architecture
Ruslan Mingaliev
Если размышлять в этом ключе, то хелл будет в презентере, либо в раздутом на тонны методов интеракторе. Имхо первый вариант лучше. Более того, никто не заставляет реализовывать юзкейс таким образом (возвращать Observable). Там написано у него было, что юз кейс - это просто контракт, который подходит всем его интеракторам в конкретно его примере.
Согласен, можно подумать в этом направлении
источник
2020 March 04

С

Сергей in Android Architecture
Как выглядит MVP для диалоговых окон? Нужен ли отдельный презентер для диалогов? Или зависит от ситуации?
источник

KD

Konstantin Dovnar in Android Architecture
Сергей
Как выглядит MVP для диалоговых окон? Нужен ли отдельный презентер для диалогов? Или зависит от ситуации?
Так же как и для Activity\Fragment.
Да, нужен.
источник

K

Kopusha in Android Architecture
по ситуации. Если там одна статика и какая-то да/нет кнопка, то зачем баловаться архитектурой. Обычные "тупые" вьюхи же без контроллеров.
источник

AE

Alexander Evsikov in Android Architecture
Kopusha
по ситуации. Если там одна статика и какая-то да/нет кнопка, то зачем баловаться архитектурой. Обычные "тупые" вьюхи же без контроллеров.
Вопрос не в "нужен/не нужен mvp", а в "как выглядит"
источник

EG

Evgeny GooDi in Android Architecture
Сергей
Как выглядит MVP для диалоговых окон? Нужен ли отдельный презентер для диалогов? Или зависит от ситуации?
Напиши в ЛС. Могу дать ссыль на свой проект. Там есть ответ на твой вопрос.
источник

A

Astar in Android Architecture
Привет! Такой вопрос вот: Я внедряю в свое приложение паттерн MVVM. И там у меня есть Fragment со списком RecyclerView, к нему я написал адаптер, и в нем у меня есть пара элементов на нажатие которых у меня должны происходить какие либо действия. Правильно ли будет если я добавлю callback методы при помощи интерфейса, что бы во Fragment я мог обрабатывать действия?
Или это будет звучать вот так: насколько сильная связь должна быть между адаптером RecyclerView и моим Fragment?
Какие можете дать рекомендации для построения более правильной архитектуры?
источник