Size: a a a

Android Architecture

2020 June 16

Ч

Чича in Android Architecture
QMan
но лучше, естественно, провайдить самому, например использовать di
провайдить это передавать через конструктор?
источник

Q

QMan in Android Architecture
Чича
провайдить это передавать через конструктор?
в конструтор или нет, не суть, но переложить эту ответственность на тот же di, пусть он доставляет готовые к "употреблению"
источник

Q

QMan in Android Architecture
Я, например, не работаю с контекстом в viewmodel, только в view
источник

MM

Mikhail Mustakimov in Android Architecture
Чича
можно на ты))
у меня задача получить координаты юзера(запросить локацию) и типо там же нужно пермишны запросить и сделать действие которое тоже требует контекст но как функция которая должна в активити пойти не смотрится.
Имхо, лучше сделать абстракцию, которая будет предоставлять координаты и с ней уже работать в VM. Пермишены можно запрашивать во View (у себя так делаю).

Пример реализации LocationProvider (использует RxJava, но общий принцип должен быть понятен) — https://gist.github.com/Mikhail57/dc7900321d07a910060ec537c66fd7ea
источник

MM

Mikhail Mustakimov in Android Architecture
Mikhail Mustakimov
Имхо, лучше сделать абстракцию, которая будет предоставлять координаты и с ней уже работать в VM. Пермишены можно запрашивать во View (у себя так делаю).

Пример реализации LocationProvider (использует RxJava, но общий принцип должен быть понятен) — https://gist.github.com/Mikhail57/dc7900321d07a910060ec537c66fd7ea
Решение с провайдером фейкается на ура в тестах, пока проблем особо не встречал
источник
2020 June 17

V

Victor in Android Architecture
Здравствуйте, подскажите плиз зачем в клин архитектуре юскейсы, почему не использовать просто интерфейс репозитория? Зачем вводить юскейсы в чем преимущества?
источник

PA

Pavel Aleksandrov in Android Architecture
Victor
Здравствуйте, подскажите плиз зачем в клин архитектуре юскейсы, почему не использовать просто интерфейс репозитория? Зачем вводить юскейсы в чем преимущества?
Не всегда логика приложения завязана только на общении с сервером. Часть бизнес-логики может выполняться на устройстве (та же валидация данных). А репозиторий используется лишь для взаимодействия с источниками данных
источник

V

Victor in Android Architecture
Pavel Aleksandrov
Не всегда логика приложения завязана только на общении с сервером. Часть бизнес-логики может выполняться на устройстве (та же валидация данных). А репозиторий используется лишь для взаимодействия с источниками данных
Огромное Спасибо кажется теперь начинаю понимать. То есть чтобы такое как валидация не попала в презентер!

А вот если ввести между репозиторием и презентером фасад то можно считать в какой-то степени юскейсом фасад?
источник

V

Victor in Android Architecture
Victor
Огромное Спасибо кажется теперь начинаю понимать. То есть чтобы такое как валидация не попала в презентер!

А вот если ввести между репозиторием и презентером фасад то можно считать в какой-то степени юскейсом фасад?
И прлучаеться можно обойтись без юскейсов?
источник

PA

Pavel Aleksandrov in Android Architecture
Victor
Огромное Спасибо кажется теперь начинаю понимать. То есть чтобы такое как валидация не попала в презентер!

А вот если ввести между репозиторием и презентером фасад то можно считать в какой-то степени юскейсом фасад?
Что в твоём понимании фасад?
источник

V

Victor in Android Architecture
Pavel Aleksandrov
Что в твоём понимании фасад?
Это паттерн с помощью которого можно упростить взаимодействование  со сложной системой(или что-то типа такого).
И ещё можно спрятать легаси код.


Если считать валидацию и репозиторий частями одной системы то получается можно в реализацию фасада это все поместить.

Это как я понимаю)
источник

PA

Pavel Aleksandrov in Android Architecture
Тут уже все зависит от тебя. Архитектура должна упрощать жизнь разработчика. Если ты сможешь легко протестировать такой код и разделить ответственности, то почему бы и нет
источник

V

Victor in Android Architecture
Pavel Aleksandrov
Тут уже все зависит от тебя. Архитектура должна упрощать жизнь разработчика. Если ты сможешь легко протестировать такой код и разделить ответственности, то почему бы и нет
Огромное спасибо
источник

S

Sergey in Android Architecture
Кто-нибудь может обьяснить по простому зачем нужен паттерн Repository в приложении . Или кинуть ссылку где об этом можно почитать
источник

AV

Alex Vayts in Android Architecture
Нужен, чтобы работать с “просто данными”, не думая об их происхождении. Чтобы инкапсулировать источник и можно было выполнять с ним различные манипуляции: подменить для тестов, дополнить кэшем, заменить сеть на базу данных и т.д. и при этом зависимые классы бы не поменялись
источник

ВС

Виталий Сычёв... in Android Architecture
Sergey
Кто-нибудь может обьяснить по простому зачем нужен паттерн Repository в приложении . Или кинуть ссылку где об этом можно почитать
Чтобы не зависеть от источников данных, и работать с этими  данными как с обычной коллекцией, при этом не думать с чего мы получаем и куда мы записываем эти данные( бд, бэк, и тп )
источник

AA

Artur Artikov in Android Architecture
источник

KD

Konstantin Dovnar in Android Architecture
Victor
Огромное Спасибо кажется теперь начинаю понимать. То есть чтобы такое как валидация не попала в презентер!

А вот если ввести между репозиторием и презентером фасад то можно считать в какой-то степени юскейсом фасад?
Обычно юзкейсы и являются фасадом, всё верно.
источник
2020 June 18

ДK

Дамир Kadyrgulov... in Android Architecture
Sergey
Кто-нибудь может обьяснить по простому зачем нужен паттерн Repository в приложении . Или кинуть ссылку где об этом можно почитать
В догонку еще один вопрос - а зачем в репозитории почти всегда присутствует метод GetById? Записи всегда вытаскиваются со своими айдишниками наружу и тащатся эти айдишники через все слои до вьюхи... и вдруг исчезают, ибо пользователю эти айди не нужны
источник

YW

Yakov Weber in Android Architecture
Дамир Kadyrgulov
В догонку еще один вопрос - а зачем в репозитории почти всегда присутствует метод GetById? Записи всегда вытаскиваются со своими айдишниками наружу и тащатся эти айдишники через все слои до вьюхи... и вдруг исчезают, ибо пользователю эти айди не нужны
Ну так если тебе нужно по нажатию на item списка получать детальную информацию для этого и используется ID, потом ты просто находишь данные по нему через метод getById
источник