Size: a a a

Android Architecture

2020 April 25

EC

Evgeny Cherkasov in Android Architecture
Danil Yudov
вообще довольно спорное удобство. не всегда можно удачно кластеризовать методы по фичам, будет получаться то интерфейс с одним методом, то с десятью методами. возможно иногда фичи будут пересекаться и придётся таскаться с несколькими зависимостями на интерфейсы нетворкинга
+
источник

Q

QMan in Android Architecture
Danil Yudov
не всегда 🤷‍♂
можно пример ?
источник

Q

QMan in Android Architecture
Danil Yudov
скорее два класса с методами api в репу
для примера: ApiUser, ApiMessage, UserRepository, MessageRepository. Для фичи, например Chat, просто юзаем две репы
источник

Q

QMan in Android Architecture
Как то так...
источник

Q

QMan in Android Architecture
Danil Yudov
скорее два класса с методами api в репу
Это как то не оч... Хотя, каждому своё...
источник

D

Danil Yudov in Android Architecture
QMan
можно пример ?
ничего синтетического в голову не приходит. часто например бывает, что нельзя выделить метод в какую фичу отдельно, но при этом он нужен в каждой (например: подтверждение действия кодом из смс). такое крч. пилить репозиторий для одного метода, или прокидывать интерфейс с этим одним методом в каждый репозиторий, что то, что это не слишком удобно. да, когда точек взаимодействия с бэкендом под полтос или больше, какое-то разделение будет логичным, но не потому что удобно (часто вы ползаете в эти интерфейсы работы с апи для каких-то правок? я только если нужно что-то добавить, т.е. весьма редко), а чтоб разграничить ответственность и не давать слишком большой свободы / делать лишнего
источник

KD

Konstantin Dovnar in Android Architecture
Я всегда хер кладу на эндпоинты и просто копирую то, что на бэке.  ¯\_(ツ)_/¯

В каком-нибудь сваггере обычно всё уже поделено по фичам, дан нейминг, всё нужное есть.
источник

В

Вася in Android Architecture
Konstantin Dovnar
Я всегда хер кладу на эндпоинты и просто копирую то, что на бэке.  ¯\_(ツ)_/¯

В каком-нибудь сваггере обычно всё уже поделено по фичам, дан нейминг, всё нужное есть.
как заклинание прозвучало )
источник

D

Danil Yudov in Android Architecture
Konstantin Dovnar
Я всегда хер кладу на эндпоинты и просто копирую то, что на бэке.  ¯\_(ツ)_/¯

В каком-нибудь сваггере обычно всё уже поделено по фичам, дан нейминг, всё нужное есть.
ещё бы всех бэкендеров к сваггеру приучить 😩
источник

EI

Edem Injection in Android Architecture
soap коммуникация используется в андроиде?
источник

D

Danil Yudov in Android Architecture
Edem Injection
soap коммуникация используется в андроиде?
думаю, никто не запрещает использовать. но в основном у всех конечно рест на джейсонах, или gRPC в последние годы (можно присмотреться как к альтернативе soap)
источник

EI

Edem Injection in Android Architecture
spasibo
источник

AD

Aleksey D. in Android Architecture
Как вы в ТЕА избегаете захламления состояния и необходимости пробегать потом по кучам полям-перечислениям, чтобы понять, в каком именно состоянии ты находишься? да, можно создавать на каждый такой случай свои подсостояния, но в итоге их может очень много появиться 🤔
источник

KD

Konstantin Dovnar in Android Architecture
Aleksey D.
Как вы в ТЕА избегаете захламления состояния и необходимости пробегать потом по кучам полям-перечислениям, чтобы понять, в каком именно состоянии ты находишься? да, можно создавать на каждый такой случай свои подсостояния, но в итоге их может очень много появиться 🤔
Кто-то (довольно рисковый) сохраняет все предыдущие состояния.
Кто-то хранит изначальное состояние + все диффы.

Но в целом — никак.
Это один из минусов TEA и подобных ему архитектур. SSOT он такой.
источник

AD

Aleksey D. in Android Architecture
Konstantin Dovnar
Кто-то (довольно рисковый) сохраняет все предыдущие состояния.
Кто-то хранит изначальное состояние + все диффы.

Но в целом — никак.
Это один из минусов TEA и подобных ему архитектур. SSOT он такой.
вот чет не вижу, как мне дифы и предыдущие состояния помогут
источник

KD

Konstantin Dovnar in Android Architecture
Aleksey D.
вот чет не вижу, как мне дифы и предыдущие состояния помогут
Видимо я не понял твою проблему.

Мне казалось, что под "чтобы понять, в каком именно состоянии ты находишься?" ты подразумеваешь "понять, в каком состоянии ты находишься и как в него попал". В диффы как-раз об этом.
источник

AD

Aleksey D. in Android Architecture
Konstantin Dovnar
Видимо я не понял твою проблему.

Мне казалось, что под "чтобы понять, в каком именно состоянии ты находишься?" ты подразумеваешь "понять, в каком состоянии ты находишься и как в него попал". В диффы как-раз об этом.
проблема в том, что состояние помимо всего прочего характеризуют несколько флажков и внутренних подсостояний, которые приходится последовательно проверять, чтобы определить реакцию на то или иное сообщение извне
источник

AD

Aleksey D. in Android Architecture
можно лепить такие ситуации разнми именно состояниями (классами), но вдруг есть способ попроще
источник

KD

Konstantin Dovnar in Android Architecture
Aleksey D.
проблема в том, что состояние помимо всего прочего характеризуют несколько флажков и внутренних подсостояний, которые приходится последовательно проверять, чтобы определить реакцию на то или иное сообщение извне
И диффы — как раз об этом.
Каждый дифф — это какое-то изменение состояния.
Т.е. по факту, у тебя будет полноценная карта того, как и почему пользователь попал в свой стейт.
источник

KD

Konstantin Dovnar in Android Architecture
Стартовое состояние State(counter = 0)
и есть List<State.Diffs> в котором лежит какие-нибудь Add(3), Add(2)

Вот по списку ты и знаешь, что пользователь сначала добавил 3, а потом 2.
источник