#статьи
Почитал тут недавно серию статей (их пока что три) - http://five.agency/android-architecture-part-1-every-new-beginning-is-hard/
Очень грамотное теоретическое описание трансформации классической Clean Architecture от дядюшки Боба в Clean Architecture для Android. Вот прям по полочкам.
Единственное, вторая статья как-то немного запутала с этими input/output портами для UseCase и решением проблемы флоу данных через наследование и композицию. Немного оторвано от практики, как мне показалось. Лучше сразу к третьей части приступить, если вы также не совсем поняли.
Еще есть моменты, над которыми можно похоливарить =)
Ребята вроде как обещают четвертую часть, где у них будет большой пример Clean Architecture. Ждемс!

#кейсы
Вопрос:
Есть следующая задача: перед каждым 4м вызовом некоторого апи нужно показывать рекламный блок. Как правильно сделать?
Ответ:
Проверка на уровне интерактора. То есть у репозитория два метода: getData и getAds.
А интерактор считает когда нужно показывать данные, а когда рекламу, в нём логика.

#кейсы
Вопрос:
Есть RecyclerView с различными разнообразными ViewHolder. В одном item списка может быть семь EditText, в другом - другие компоненты. У каждого item своя логика валидации и прочее. Возникает риск распухания ViewHolderов и намешивания в них бизнес-логики.
Ответ:
Советуем посмотреть в сторону решения, описанного в http://hannesdorfmann.com/android/adapter-delegates.
Там вводится новая сущность - делегат. Делегат позволяет разгрузить ваши адаптеры и вьюхолдеры, а также сделать их максимально переиспользуемыми, если списков в приложении много.
В делегаты вы можете инжектить Презентеры, через которые провайдите действия пользователя.
Однако бывают случаи, когда один item переиспользуется много где, и этот item отвечает, например, за "like". Инжектить Презентер бывает не очень удобно, так как тогда возникает дублирование кода и протягивание лишних зависимостей, чтобы в конце концов выполнить нужный юз-кейс.
Поэтому можно заинжектить в данный делегат специальный Интерактор, который как раз и выполняет юз-кейс нажатия на like.

#статьи
В статье автор пытается разобраться с понятием Inversion Of Control и дать более менее формальное определение понятию.
На примере, написанном на псевдокоде, рассматривается система с прямым потоком управления, после эта же система, но с применением иневерсии потока упраления. Показав систему до и после и проанализировав изменения, автор, на мой взгляд, неплохо раскрывает тему IoC.
Статья читается тяжеловато, много сложной терминологии (автор дает определения), но рекомендую к прочтению, особенно, если вы путаете понятия Inversion of Control, Dependency Inversion Principle, Dependency Injection и хотите разобраться с теоретической стороной вопроса.
Хотя для некоторых понятий в статье дается несовсем полное определение, которое верно в контексте статьи, но может запутать, если вы только знакомитесь с тематикой, например, Dependency Injection — это функция, которую может выполнять IoCContainer. Все верно, но помните, что Dependency Injection прекрасно существует без IoCContainer и эта штука хоть и очень полезная, но опциональная. В общем, читайте аккуратнее!

https://rsdn.org/article/ioc/Inversion%20of%20Control2.xml

#кейсы
Вопрос:
А как правильно реализовывать логику выбора данных из кэша или из сети? Что если иногда надо брать из кэша, а иногда из сети? Правил но ли делать в репозитории методы типо getfromnetwork и getfromcache? Например в случае если пулл ту рефреш то это обязательно из сети, а в каких-то других случаях можно и из кэша взять. Или
например есть ситуация: есть обьект, мне сначала нужно сделать бизнес-операцию над ним, далее показать, паралельно отправить запрос в облако, для обновления данных об обьекте, и когда запрос выполнится, отобразить актуалные данные из сети. По сути мне нужно знать об существовании разных источников данных на уровне бизнес логики. Тогда какая часть должна быть в репозиторие?

Что предлагаем:
Логика получения данных, в общем случае, хранится в специальном классе в уровне модели. Далее возможно иметь 2 кейса:
1) Менеджер источников данных (например, SmthDataStoreFactory) инжектится в SmthRepository и сам решает, как вытаскивать данные - из сети или кэша.
2) В случае, когда бизнес логике важно, чтобы данные пришли свежими, отправляется специальный флаг типа "needFreshData", его получает менеджер и понимает, что кэш в данном случае не прокатит, делает запрос на сервер. Если нужна более гибкая настройка, можно использовать различные стратегии для выборки данных, FirstCache, NoCache и т.д.. В репозитории будут методы с сигнатурой, getUser(int id, boolean needFreshData) или getUser(int id, CachePolicy policy).

Методы, вроде getfromnetwork и getfromcache использовать можно, у такого подхода есть плюс, по сравнению с подходом, когда используется менеджер источников данных (SmthDatatStoreFactory) - не будет заглушек вроде UnsupportedOperationException на методы, которые актуальны для одних источников, но не поддерживаются в других. Из минусов, Не получится, поменять источник данных, незатронув при этом реализации зависящих классов.

#статьи
https://plus.google.com/+DianneHackborn/posts/FXCCYxepsDU
Пост инженера Гугла о том, о чем мы все очень любим говорить (чем грешу и я) - Андроид мешает нам жить!
На самом деле Android SDK - это просто API, по которому приложение общается с ОС и другими приложениями через ту же ОС. Всё! И более ничего.
Далее рассматриваются ключевые компоненты SDK и их истинное предназначение.
Activity - это не только View, а прежде всего это системный компонент. Он помогает сохранять состояния при убийстве процесса, восстанавливать его, пермишены там разные получать и т.д. На фрагменты да, вы уже можете вешать ответственность "только View".
BroadcastReceiver. Используйте его только для получения каких-либо системных событий. Внутри приложения общение между компонентами можете организовывать как угодно, но желательно не через BroadcastReceiver, чтобы не получить потенциальные дыры.
Service. Started services. Для запуска долгоиграющих задач. Например, проигрывание музыки.
Service. Bound services. Для общения между процессами. Не более. В рамках одного процесса вообще не имеет смысла запускать.
ContentProvider. Самое интересное, как по мне. ContentProvider - это просто специальная возможность публиковать данные со своего приложения куда-либо еще. Это никакая ни абстракция для БД, сети или еще чего-либо.
А хотите там архитектур всяких красивых - думайте сами!

#статьи
Шпаргалка по SOLID принципам. Для каждого принципа есть краткое описание, примеры нарушения и версии принципов с приставкой Anti-, такие как DI-головного мозга, Принцип тысячи интерфейсов и т.д. Так же вы можете ознакомиться с каждым из принципом более подробно, в конце статьи есть ссылки на цикл статей по SOLID принципам.
Особенно рекомендуется к прочтению статья "Критический взгляд на принцип инверсии зависимостей", в которой автор делает анализ примеров, приведенных в статье и книге Дядюшки Боба и приходит к интересным выводам.

http://sergeyteplyakov.blogspot.ru/2014/10/solid.html
http://sergeyteplyakov.blogspot.ru/2013/04/blog-post.html

#презентация
Доклад "Чистая архитектура. Погружение" (Евгений Мацюк и Александ Блинов).
В pptx + keynote.
https://drive.google.com/drive/folders/0B5fMdvXec3eyMVNnNHNIY3kwZ28?usp=sharing

#статьи
Наверняка, частенько бывало такое, что выделив интерфейсы для всех ваших зависимостей и прокинув их пачкой через конструктор к потребителю, вы становились абсолютно спокойным за свой дизайн. Так как, вы не завязаны на конкретную реализацию, формально есть DIP (вы зависите от абстракций), у вас есть Dagger, который соберет все в кучу. Но все ли так хорошо на самом деле? И что такое франкен-код или франкен-дизайн? В этих вопросах поможет разобраться статья про управление зависимостями.

https://habrastorage.org/web/f85/ee5/aeb/f85ee5aeb3e84d758f60d9efcf015868.jpg

http://sergeyteplyakov.blogspot.ru/2012/11/blog-post.html
https://plus.google.com/u/0/+SergeyTeplyakov/posts/gRaqrqaiGbe

P.S. На изображении Сергей Шкредов рассказывает про систему управления зависимостями в .NET продуктах JetBrains. IntellisenseManager - реально существующая сущность, кажется в плагине для VS Resharper. Не забывайте, что в статьях скорее всего речь идет о больших десктопных приложениях, которые вероятно сложнее и крупнее мобильных, но материал конечно актуален и для мобильных приложений тоже.

#кейсы
Вопрос:
Мне необходимо загрузить список (есть local и remote data source). Т.о сначала необходимо отобразить данные из local, и потом делать запрос к серверу. Является ли это бизнес-логикой, или эту логику необходимо вынести в Repository?
Что предлагаем:
Зависит от требований к приложению, глобально есть два подхода:
1) умный кеш (тогда это на уровне репозитория, а интерактор только просит данные)
2) глупый репозиторий (репозиторий только знает как достать данные, а интерактор сам говорит откуда и когда)

#кейсы
Вопрос:
После некоторого действия пользователя показывается SnackBar с кнопкой Отмена. Если успеть ее нажать, то действие надо отменить. Как лучше это сделать.
Что предлагаем:
Презентер сообщает действие интерактору только по событию: "SnackBar скрылся", то есть только после того как пользователь решил не отменять действие. Важно: надо заранее учесть, что пользователь может сразу после действия выйти с экрана или приложения. Тогда надо принять решение - либо также передать действие интерактору при деттаче вью, лтбо считать такое поведение пользователя тоже отменой действия.

#кейсы
Вопрос:
Есть список элементов. По клику открывается информация о конкретном элементе.
Можно ли передавать элемент через параметры нового экрана или надо в параметры класть только Id.
Что предлагаем:
Правильнее передавать параметром только Id, а сами элементы будут закешированы в репозитории.
Так как в этом случае мы сможем получить всегда актуальную информацию из репозитория, а не устаревшую из параметров.

#кейсы
Вопрос:
Может ли Presenter обращаться к Interactor за некоторыми константами (Interactor.ROOT_FOLDER_ID)?
Что предлагаем:
Лучше чтобы презентер не знал о каких-то константах бизнес логики.
Если эта константа дальше нужна для получения данных, то лучше сделать явный метод getRootFolderInfo() или что-то в этом роде

#кейсы
Вопрос:
Необходимо в тексте подсветить некоторые части с помощью спанов.
Это бизнес логика, как лучше поступить?
Что предлагаем:
Передавать из презентера массив пар строка-цвет и отрисовывать во вью.
Или передавать всю строку, и массив из выделений (индекс начала, индекс конца, цвет)

#книги
Приводим список книг, которые помогут вам писать более поддерживаемый, модифицируемый, "чистый" код.

1. Паттерны проектирования. Банда четырех.
Основа основ.
2. Effective Java 2. Джошуа Блох.
Хорошо вправляет мозги, особенно начинающим. Полезные советы о том, как писать хороший код на Java.
3. Чистый код. Роберт Мартин.
Отличная книга, показывающая, каких ошибок не стоит совершать.
4. Совершенный код. Стив Макконнелл.
Отлично прочищает мозги.
5. Экстремальное программирование. Кент Бек.
Как писать с TDD. Учит мыслить тестами.
6. The Clean coder. Робер Мартин.
Хорошие советы разработчикам.
7. Working effectively with Legacy code. Майкл Фезерс.
Про боль, которая знакома каждому. Как бороться с легаси кодом.
8. Refactoring. Мартин Фаулер.
Не всегда мы пишем всё с нуля. Тут нам подскажут, как с наименьшими потерями обновить существующую кодовую базу.

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

#теория
Состоялся тут в чатике холивар по тому, на сколько нужны паттерны проектирования для начинающих и вся подобная теория.
Вывод довольно простой на самом деле. Без знания языка и какой-то практики теория не будет иметь большого смысла. Шаблоны - хороший и выразительный инструмент для функциональных конструкций. В каждом проекте применяется множество шаблонов, их нужно уметь распознавать и применять. Это требует практики и осмысления. Существует несколько базовых принципов, понимание которых сильно упростит и понимание шаблонов, GRASP и SOLID. Понимание этих принципов сделает некоторые шаблоны очевидными, некоторые вполне закономерными. В современных тенденция также будут полезными знания освновных принципов функционального программирования.
На основе этого можно достаточно легко оперировать такими инструментами как DI, применять Rx, разделять отвественности по слоям.

#Вечный_вопрос
Использовать контекст в Презентере и Интеракторе или нет? Почти как "быть или не быть", судя по той частоте, с которой задается данный вопрос.
Причем вроде все согласны с тем, что андроид-классам в бизнес-логике не место. На то она и бизнес-логика, чтобы быть максимально независимой, особенно независимой от платформы. Андроид-классы у нас обычно или во вьюшке, или в Data-слое (получение данных типа геопозиции, контактов и прочее).
Но вот нужно нам строчку из Презентера передать вьюшке. И как быть? Без контекста вроде никак. И тут мы добавляем зависимость. И это только для получения строчки, не более. Но проблема в том, что последователи могут начать использовать контекст в Презентере не по назначению. А если контекст будет в Интеракторе, то теоретически наша бизнес-логика будет завязана на конкретную платформу, что делает ее не переиспользуемой (кейс переиспользования бизнес-логики где-то в другом месте, конечно, очень редкий в нашем мобильном мире, но все же).
На самом деле есть способы избежать использования контекста в том же Презентере.
Для доступа к ресурсам надо создать отдельную сущность, которая будет работать с контекстом только ради ресурсов, типа ResourceManager, и все.
Проблема решаема, причем довольно малой кровью. Но зато наш код чистый и независимый.

#Теория
Что есть Interactor и UseCase?
Каноничный юзкейс - это класс с одним методом execute. На практике это не всегда бывает удобно. Плюс порождает большое количество классов. Поэтому вводится такое понятие как Интерактор.
На самом деле каноничного определения Интерактора нет.
В нашем понимании Интерактор = набор юзкейсов связанных одной фичей.
То есть ProfileInteractor = LoadProfileUseCase + UpdateProfilePhotoUseCase + UpdateProfileNameUseCase + ...

#статьи
Как понять по логам тестов что перестало работать? Как упростить понимание кода с помощью тестов? Как сделать тесты более читаемыми? В статье приведены 7 подходов к именованию unit-тестов, которые помогут ответить на эти вопросы глядя только имя тестового метода.
https://dzone.com/articles/7-popular-unit-test-naming