ну только если в описание чата или запиненное сообщение, в чичероне запинили ссылку на телеграф статью, норм

гит вики

Вопрос по архитектуре бд. Есть ли случаи, когда стоит хранить одни и те же данные в разных таблицах?

Для перфоманса делают денормализацию бд, или для аналитики, на больших объемах данных.
Большая БД?

Бд для месседжера

Теоретически большая

Ну хз, геморой поимеешь при обновлении.
А join rulez 👽

А как в таком случае обновлять сразу все поля?)

Чтоб сохранить консистентность

Если одни и те же данные в разных таблицах, то придется обновлять не одну таблицу а несколько в одной транзакции понятное дело.

Это называется партицирование. В мускуле и постгре, например, такие механизмы встроены.

Вообще можно было бы создать ещё и канал, запинить ссылку на него и сливать туда полезности

У нас в чате Мокси возникла небольшая дискусия, имеющая отношение и к архитектуре. Поэтому хотел бы спросить совета еще и здесь. Есть следующий код: http://dl3.joxi.net/drive/2017/02/06/0020/1410/1373570/70/178626bfeb.png
Здесь Даггер инжектит презентер. Потом этот презентер через метод c  аннотацией @ProvidePresenter отдается Мокси, и дальше уже Мокси берет на себя управление презентором, но работает с ним через то же поле, с которым работал до этого Даггер.
Хотел бы посоветоваться, на сколько такой подход плохой?

Посмотрел доклад наконец-то. Доклад отличный. Спасибо.

Есть вопросы по поводу взаимодействия view и presenter.

Вью:
https://github.com/matzuk/TestableCodeMobius/blob/master/app/src/main/java/com/matsyuk/testablecodemobius/ui/profile/view/IProfileView.java

Почему вью имеет методы типа setName, setAccountNumber и т.д. ? Почему не лучше иметь метод accountAvailable(Account acc) ? С учетом того что модель Account это модель уровня вью. Ведь в случае изменения модели прийдется менять и интерфейс вью, и реализацию вью, и реализацию пресентера.  Если же сделать как описано выше, то прийдется изменить лишь реализацию вью.

Вью:
https://github.com/matzuk/TestableCodeMobius/blob/master/app/src/main/java/com/matsyuk/testablecodemobius/ui/transfer/view/ITransferView.java

Первый вопрос такой же как и в предыдущем вью почему не иметь вместо методов showOrgNameError, showBIKError и т.д. метод showError(Error err)?
Второй вопрос по поводу метода setEnableSendTransferButton. Почему метод имеет в названии элемент андроид интерфейса? Почему не называется например setTransferringAvailable. Опять же при изменении дизайна возможно уже нужно будет отображать не кнопку а что-то еще или вообще просто добавить распознавание жеста.

На вопрос с моделью Евгений уже отвечал

Доброе утро коллеги) @eugene_matsyuk у Вас [тут](https://github.com/matzuk/TestableCodeMobius/blob/master/app/src/main/java/com/matsyuk/testablecodemobius/ui/profile/view/IProfileView.java) в примере 5 полей биндится на экран причем из одной модели. Вопрос, если у меня экран с кучей полей (15-20 большой экран с инфо о пользователе) мне тоже плодить 15-20 методов сетеров? или завернуть их все в модель и передать на view ее тоже можно?

заверните в модель, конечно же =)
и передайте целиком во вьюшку

кстати да, как идея

полностью согласен
оборачивайте в модель и меняйте название =)

А тут я согласен по поводу имени setEnableSendTransferButton, но не согласен по поводу ошибки. У нас могут быть разные виды ошибок, вьюха зачастую должна отрабатывать их по-разному, соответственно ей надо дёргать разные методы и этим занимается презентер. С другой стороны, мы всегда можем сначала создать один метод, потом дополнить необходимыми.