DB
Ну когда мы на Б, активити А onStop а значит он не слушает события. мы же отписываемся
Size: a a a
2017 January 25
СГ
Мы у себя делаем эквивалентными UserDatabase и User. Да и по возможности UserApi и User. А иначе — только ручной маппинг. Может у кого-то по другому?)
Мы тоже об этом думаем. Вопрос по фэн шую ли это) Но если в случае со склейкой User + UserDb более просто и понятно, то со склейкой User и UserApi могут быть сложности из за того, что UserApi из внешнего источника приходит..
EM
Всем привет!
Очень интересно узнать, какие используете подходы для доменных сущностей в контексте Clean Architecture.
Например есть моделька User в слое domain. В слое дата так же получается есть сущности типа UserDatabase и UserApi.
Чтобы гонять эти сущности можду слоями делаем мапперы. В идеальном минимальном случае нужны мапперы UserApi -> User , UserDatabase -> User.
Так же вполне может появиться UserView со специфичными полями для View(для списка например)
Кто как решает вопрос с этим boilerplate'ом и маппер хелом?
Очень интересно узнать, какие используете подходы для доменных сущностей в контексте Clean Architecture.
Например есть моделька User в слое domain. В слое дата так же получается есть сущности типа UserDatabase и UserApi.
Чтобы гонять эти сущности можду слоями делаем мапперы. В идеальном минимальном случае нужны мапперы UserApi -> User , UserDatabase -> User.
Так же вполне может появиться UserView со специфичными полями для View(для списка например)
Кто как решает вопрос с этим boilerplate'ом и маппер хелом?
вопрос в том, как бороться с постоянным преобразованием моделек между слоями, как я понял?
да никак =) это необходимое зло, так как способствует независимости каждого уровня. и это окупается, когда у вас вдруг поменялась моделька в БД, и это затронет только Дата уровень. А не как раньше, единая модель для всего и страдание с мучениями при изменениях))
да никак =) это необходимое зло, так как способствует независимости каждого уровня. и это окупается, когда у вас вдруг поменялась моделька в БД, и это затронет только Дата уровень. А не как раньше, единая модель для всего и страдание с мучениями при изменениях))
EM
в докладе я затрагивал этот момент
СГ
вопрос в том, как бороться с постоянным преобразованием моделек между слоями, как я понял?
да никак =) это необходимое зло, так как способствует независимости каждого уровня. и это окупается, когда у вас вдруг поменялась моделька в БД, и это затронет только Дата уровень. А не как раньше, единая модель для всего и страдание с мучениями при изменениях))
да никак =) это необходимое зло, так как способствует независимости каждого уровня. и это окупается, когда у вас вдруг поменялась моделька в БД, и это затронет только Дата уровень. А не как раньше, единая модель для всего и страдание с мучениями при изменениях))
Если нужно передать модельку из api в локальное хранилище, делаете еще один маппер UserApi -> UserDb?
EM
Мое мнение, что лучше разделять. Для апи одна моделька, для бд - другая.
Да, это оверхед кодовый, но зато ничего друг от друга не зависит.
но можно подумать еще на эту тему
Да, это оверхед кодовый, но зато ничего друг от друга не зависит.
но можно подумать еще на эту тему
YS
Ну когда мы на Б, активити А onStop а значит он не слушает события. мы же отписываемся
ну так она как рестартанётся, так и отобразит то, что нужно ;)
СГ
Мы пришли к варианту делать для модели интерфейс IUser, и чтобы каждая моделька в слое реализовывала его, т.о. можно сократить мапперы к варианту IUser -> UserDb, IUser -> UserApi, IUser -> UserView.
Ну и тесты на каждый маппер обязательно, чтобы убедиться в правильной конвертаций.
Насколько такой вариант корректый?
Ну и тесты на каждый маппер обязательно, чтобы убедиться в правильной конвертаций.
Насколько такой вариант корректый?
YS
Мое мнение, что лучше разделять. Для апи одна моделька, для бд - другая.
Да, это оверхед кодовый, но зато ничего друг от друга не зависит.
но можно подумать еще на эту тему
Да, это оверхед кодовый, но зато ничего друг от друга не зависит.
но можно подумать еще на эту тему
ещё наверное зависит от проекта. если это большой, долгоиграющий продукт, то это одно. а если это аутсорс на полгодика покодить и забыть — это другое ;)
DB
ну так она как рестартанётся, так и отобразит то, что нужно ;)
Видимо я чего-то не догоняю, мы щас про евентбас или нет?)
СГ
Мое мнение, что лучше разделять. Для апи одна моделька, для бд - другая.
Да, это оверхед кодовый, но зато ничего друг от друга не зависит.
но можно подумать еще на эту тему
Да, это оверхед кодовый, но зато ничего друг от друга не зависит.
но можно подумать еще на эту тему
Да, оверхед все таки смущает, при больших списках можно немало лишних аллокаций получить. Ну и утомительно эти мапперы писать(
S
Евгений, добрый день! вопрос может задавали уже: как тестировать получение координат от FusedLocationProvider'а ?
YS
Видимо я чего-то не догоняю, мы щас про евентбас или нет?)
Нее, мы щас про MVP =) Один презентер меняет модель, другой презентер слушает эти изменения. И кстати, если вы из презентера отправите команду в стопнутую активити, команда ваша спокойно выполнится.
EM
ещё наверное зависит от проекта. если это большой, долгоиграющий продукт, то это одно. а если это аутсорс на полгодика покодить и забыть — это другое ;)
Да, опять таки все зависит от проекта =)
EM
Str13
Евгений, добрый день! вопрос может задавали уже: как тестировать получение координат от FusedLocationProvider'а ?
Привет!
Не задавали)
Может кто знает?
Не задавали)
Может кто знает?
S
)) смотрел доклад с мобиуса 2016 и ждал, что будет раскрыта эта тем )
EM
@senneco @xanderblinov может сталкивались с таким?)
S
конечно в связке с чистой архитектурой. В каком месте такой архитектуры нужно располагать получение координат и вобще работа с GoogleApiClient
S
возможно будет время в следующем докладе раскрыть или зацепить чуток эту тему ) было бы круто )
YS
@senneco @xanderblinov может сталкивались с таким?)
Не сталкивался с такими задачами. Только могу посоветовать посмотреть на пару методов: https://developers.google.com/android/reference/com/google/android/gms/location/FusedLocationProviderApi.html#setMockLocation(com.google.android.gms.common.api.GoogleApiClient,%20android.location.Location) и https://developers.google.com/android/reference/com/google/android/gms/location/FusedLocationProviderApi.html#setMockMode(com.google.android.gms.common.api.GoogleApiClient,%20boolean) %)