Ч
но лучше, естественно, провайдить самому, например использовать di
провайдить это передавать через конструктор?
Size: a a a
2020 June 16
Q
провайдить это передавать через конструктор?
в конструтор или нет, не суть, но переложить эту ответственность на тот же di, пусть он доставляет готовые к "употреблению"
Q
Я, например, не работаю с контекстом в viewmodel, только в view
MM
можно на ты))
у меня задача получить координаты юзера(запросить локацию) и типо там же нужно пермишны запросить и сделать действие которое тоже требует контекст но как функция которая должна в активити пойти не смотрится.
у меня задача получить координаты юзера(запросить локацию) и типо там же нужно пермишны запросить и сделать действие которое тоже требует контекст но как функция которая должна в активити пойти не смотрится.
Имхо, лучше сделать абстракцию, которая будет предоставлять координаты и с ней уже работать в VM. Пермишены можно запрашивать во View (у себя так делаю).
Пример реализации LocationProvider (использует RxJava, но общий принцип должен быть понятен) — https://gist.github.com/Mikhail57/dc7900321d07a910060ec537c66fd7ea
Пример реализации LocationProvider (использует RxJava, но общий принцип должен быть понятен) — https://gist.github.com/Mikhail57/dc7900321d07a910060ec537c66fd7ea
MM
Имхо, лучше сделать абстракцию, которая будет предоставлять координаты и с ней уже работать в VM. Пермишены можно запрашивать во View (у себя так делаю).
Пример реализации LocationProvider (использует RxJava, но общий принцип должен быть понятен) — https://gist.github.com/Mikhail57/dc7900321d07a910060ec537c66fd7ea
Пример реализации LocationProvider (использует RxJava, но общий принцип должен быть понятен) — https://gist.github.com/Mikhail57/dc7900321d07a910060ec537c66fd7ea
Решение с провайдером фейкается на ура в тестах, пока проблем особо не встречал
2020 June 17
V
Здравствуйте, подскажите плиз зачем в клин архитектуре юскейсы, почему не использовать просто интерфейс репозитория? Зачем вводить юскейсы в чем преимущества?
PA
Victor
Здравствуйте, подскажите плиз зачем в клин архитектуре юскейсы, почему не использовать просто интерфейс репозитория? Зачем вводить юскейсы в чем преимущества?
Не всегда логика приложения завязана только на общении с сервером. Часть бизнес-логики может выполняться на устройстве (та же валидация данных). А репозиторий используется лишь для взаимодействия с источниками данных
V
Не всегда логика приложения завязана только на общении с сервером. Часть бизнес-логики может выполняться на устройстве (та же валидация данных). А репозиторий используется лишь для взаимодействия с источниками данных
Огромное Спасибо кажется теперь начинаю понимать. То есть чтобы такое как валидация не попала в презентер!
А вот если ввести между репозиторием и презентером фасад то можно считать в какой-то степени юскейсом фасад?
А вот если ввести между репозиторием и презентером фасад то можно считать в какой-то степени юскейсом фасад?
V
Victor
Огромное Спасибо кажется теперь начинаю понимать. То есть чтобы такое как валидация не попала в презентер!
А вот если ввести между репозиторием и презентером фасад то можно считать в какой-то степени юскейсом фасад?
А вот если ввести между репозиторием и презентером фасад то можно считать в какой-то степени юскейсом фасад?
И прлучаеться можно обойтись без юскейсов?
PA
Victor
Огромное Спасибо кажется теперь начинаю понимать. То есть чтобы такое как валидация не попала в презентер!
А вот если ввести между репозиторием и презентером фасад то можно считать в какой-то степени юскейсом фасад?
А вот если ввести между репозиторием и презентером фасад то можно считать в какой-то степени юскейсом фасад?
Что в твоём понимании фасад?
V
Что в твоём понимании фасад?
Это паттерн с помощью которого можно упростить взаимодействование со сложной системой(или что-то типа такого).
И ещё можно спрятать легаси код.
Если считать валидацию и репозиторий частями одной системы то получается можно в реализацию фасада это все поместить.
Это как я понимаю)
И ещё можно спрятать легаси код.
Если считать валидацию и репозиторий частями одной системы то получается можно в реализацию фасада это все поместить.
Это как я понимаю)
PA
Тут уже все зависит от тебя. Архитектура должна упрощать жизнь разработчика. Если ты сможешь легко протестировать такой код и разделить ответственности, то почему бы и нет
V
Тут уже все зависит от тебя. Архитектура должна упрощать жизнь разработчика. Если ты сможешь легко протестировать такой код и разделить ответственности, то почему бы и нет
Огромное спасибо
S
Кто-нибудь может обьяснить по простому зачем нужен паттерн Repository в приложении . Или кинуть ссылку где об этом можно почитать
AV
Нужен, чтобы работать с “просто данными”, не думая об их происхождении. Чтобы инкапсулировать источник и можно было выполнять с ним различные манипуляции: подменить для тестов, дополнить кэшем, заменить сеть на базу данных и т.д. и при этом зависимые классы бы не поменялись
ВС
Sergey
Кто-нибудь может обьяснить по простому зачем нужен паттерн Repository в приложении . Или кинуть ссылку где об этом можно почитать
Чтобы не зависеть от источников данных, и работать с этими данными как с обычной коллекцией, при этом не думать с чего мы получаем и куда мы записываем эти данные( бд, бэк, и тп )
KD
Victor
Огромное Спасибо кажется теперь начинаю понимать. То есть чтобы такое как валидация не попала в презентер!
А вот если ввести между репозиторием и презентером фасад то можно считать в какой-то степени юскейсом фасад?
А вот если ввести между репозиторием и презентером фасад то можно считать в какой-то степени юскейсом фасад?
Обычно юзкейсы и являются фасадом, всё верно.
2020 June 18
ДK
Sergey
Кто-нибудь может обьяснить по простому зачем нужен паттерн Repository в приложении . Или кинуть ссылку где об этом можно почитать
В догонку еще один вопрос - а зачем в репозитории почти всегда присутствует метод GetById? Записи всегда вытаскиваются со своими айдишниками наружу и тащатся эти айдишники через все слои до вьюхи... и вдруг исчезают, ибо пользователю эти айди не нужны
YW
В догонку еще один вопрос - а зачем в репозитории почти всегда присутствует метод GetById? Записи всегда вытаскиваются со своими айдишниками наружу и тащатся эти айдишники через все слои до вьюхи... и вдруг исчезают, ибо пользователю эти айди не нужны
Ну так если тебе нужно по нажатию на item списка получать детальную информацию для этого и используется ID, потом ты просто находишь данные по нему через метод getById