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

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

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

#оВечном

Я хочу быть ниндзя и расслоить мой проект как врага сюрекенами, но есть Glide, неужели его кишки тоже надо раскидать по всему проекту? Что делать?

Да, Glide (как и Пикассо, Фреско, УИЛ и тд) отличная вещь, не надо от нее отказываться.
Тут тебе и загрузка картинок, и пост обработка и кеши всякие.
Но, скажете вы, вьюха должна быть тупой, а картинка приходить из дата слоя. В теории все так, но в реальном мире надо уметь находить компромиссы, которые помогут писать проект и чисто и быстро.

(умение формулировать компромиссы появляется ТОЛЬКО с опытом, поэтому мы и создали этот чат, чтобы неопытные не выдумывали боль из ничего)

Итак, что с загрузкой картинок? Компромисс здесь в том, что мы будем считать, что вью каким-то образом умеет отображать URL картинки как саму картинку и все! Вас же не смущает, что вебвью смогло загрузить веб-страницу по переданной ссылке? Поэтому смело забывайте про загрузку картинок и передавайте их в виде ссылке внутрь вью!

#статьи

Service Locator - паттерн проектирования, описанный Мартином Фаулером ещё в далеком 2004 году: http://martinfowler.com/articles/injection.html

Сейчас только ленивый не говорит о том, что Service Locator - это анти-паттерн, и нужно избегать его использование. Первое громкое заявление, что Service Locator это анти-паттерн, было от Марка Симана в 2010 году. Следует отметить, что Марк разрабатывал Service Locator для первой версии Microsoft patterns & practices Enterprise Library и работал над проектом несколько лет, прежде чем признать Service Locator анти-паттерном и отказаться от него.

Причина простая, есть лучшая альтернатива - DI.
Автор статьи, которую мы хотим представить вашему вниманию, согласен с тем, что DI - лучшая альтернатива, но хочет сказать пару слов в защиту Service Locator. Из статьи вы узнаете о некоторых проблемах DI, которых нет в Service Locator и найдёте много интересного теоретического материала.

http://bayou.io/draft/In_Defense_of_Service_Locator.html

#кейсы

Если посмотреть лекции дядюшки Боба, интерактор отвечает за бизнес логику и ничего не знает о внешних фреймворках, ui, db.

То, что Андроид обязан работать со вьюхами только в главном потоке, знает только сам Андроид фреймворк. Соответственно, обязанность предоставить шедулер Android.mainThread() должна лежать снаружи от интерактора.

Обязанность презентера - координировать вью и модель. Если вью необходимо, чтобы данные обрабатывались в главном потоке - мы явно указываем observeOn(AndroidSchedulers.mainThread()).

@senneco заметил, что не нужно всё делать асинхронно — ведь если репозиторий возвращает данные из мемори кэша, то незачем переключать потоки туда-сюда.

Поэтому, subscriveOn() происходит уже в интеракторе, или репозитории, которые владеют необходимой информацией о том, стоит ли выделить новый поток (который будет уже Андроид-независимым, как Schedulers.Io() или Schedulers.computation()).

Пример:

Презентер:

userInteractor.downloadUserInfo()

  .map(mapper::entityToView);

  .observeOn(AndroidSchedulers.mainThread())

  .subscribe(view::showUserInfo);

Интерактор:

repository.downloadUserInfo();

Репозиторий (в более сложном кейсе, шедулер зависит от источника данных, тут упрощённый пример с нетворком)

api.downloadUserInfo()

  .subscribeOn(Schedulers.io)

  .map(mapper::networkToEntity);

Summary:
Переключение потоков может быть как частью бизнес-логики, так и частью слоя данных. Зависит от того, какой класс имеет необходимую информацию для принятия решения.

Мнение:
При передаче между слоями можно всегда прокидывать данные через главный поток - таким образом, при получении observable в новом слое мы знаем, на каком потоке он выполнится. Минус подхода - зачастую, будут излишние переключения.

#кейсы

Вопрос: от сервера в Repository приходит флаг, по которому необходимо разлогинить пользователя. Но перед этим мне необходимо почистить все данные пользователя (SharedPreferences, Database).
Этот флаг может придти в любом запросе.
Получается, что необходимо в каждый Repository Inject-ить LogoutResolver или реализовать эту логику на уровне BaseRepository?

Вариант 1:
Ввести декоратор для репозтория, в который инжектиться все необходимое для очистки данных. Однако, если у декоратора нет полной информации о том, как должны очищаться остальные репозитории (они могут хранить что-то в других преференсах, бд, файлах), то по-прежнему остаётся проблема того, что эти репозитории нужно как-то уведомить о необходимости очистки.
Один из вариантов - создать список слушателей в декораторе, куда подключать все репозитории. В дальнейшем, если один репозиторий поймал событие о разлогине, уведомляются все репозитории-слушатели и выполняют свою логику по очистке.
Недостаток: многовато кода и недостаточно легко масштабируемо.

Вариант 2:
Можно ввести специальную новую сущность, например, DataCleaner.
Он будет инжектиться в интерсептор OkHttpClient, но при этом будет имет доступ в БД и Преференсам, чтобы почистить их.
То есть все будет разруливаться в дата слое без Репозитория и прочего.
При этом, если есть, допустим, несколько файлов Преференсов, и их нужно все почистить, то для большего удобства можно ввести что-то вроде PreferencesFacade, который бы предоставлял унифицированный доступ ко всем файлам нужным. И собственно из Репозиториев тоже можно работать с преференсами через него. Тогда точно ничего не забудется.

#кейсы
Вопрос:
Есть активити с тулбаром, внутри которой переключаются фрагменты. Как из вьюшки (фрагмента) взаимодействовать с тулбаром (например поменять тайтл)?
Что предлагаем:

Вариант 1:
Тулбар в данном случае будет независимой вьюшкой, со своим собственным презентером. Презентер тулбара подписывается на модель (репозиторий), которая хранит состояние тулбара. Эта модель является глобальной для всех презентеров внутри этой активити. Остальные презентеры при надобности имеют право писать в модель, а презентер тулбара должен соответственно реагировать на ее изменения.

Вариант 2:
Зачастую надобности в глобальном тулбаре нету. Тогда у каждого фрагмента можно сделать собственный тулбар. Поскольку в данном случае он будет являться частью текущей вьюшки, то презентер сможет обращаться к нему напрямую (например через метод во вью setTitle)

Хорошая подборка по Чистой архитектуре!
java-help.ru/articles-clean-architecture
Спасибо товарищу "Архитектор".

#Теория
Действительно ли в клин архитектуре нельзя в разных слоях использовать одни и те же модели данных, и их нужно перемапить, прежде чем отдать на слой выше? Не напряжно ли поддерживать такое количество классов, и не пахнет ли оно бойлерплейтом?
Отвечаем:
Чистая архитектура призывает иметь зависимости, направленные только во внутрь, а значит никто не мешает использовать Entity (бизнес сущности) в наружних слоях (например, Presentation или Data). Таким образом, в чистой архитектуре, достаточно иметь только Entities. Например, если сервер присылает данные в таком же формате, как и бизнес сущности, то особого смысла создавать новые модели данных нет, можно использовать Entitiy в качестве модели данных для сервера. Реальная надобность в мапперах возникает тогда, когда структура данных на разных слоях должна быть разной или в моделе данных необходимо иметь платформо(фреймворк) - специфическую зависимость, например, реализовать интерфейс RealmModel. Другой пример, в Presentation слое можно использовать бизнес сущности, но когда потребуется добавить в сущности дополнительные поля, специфические для UI (например, Color и т.д.), то имеет смысл сделать отдельную модель для слоя представления.
Итого, строго по клин архитектуре, достаточно иметь только Entities (бизнес сущности), которые по правилу зависимостей, можно использовать во всех наружних слоях.

#книги

Представляем вашему вниманию статью с подборкой книг по дизайну и ООП. В статье, кроме самих книг, автор дает советы о выбре книг как новичкам, так и продвинутым разработчикам. А так же о каждой книге написана небольшая рецензия.
Автор подборки, кстати, так же является автором многочисленных статей о проектировании ПО и замечательной книги про паттерны проектирования (можете легко найти ее сами по ссылке на статью). Интересно, что автор критикует одну из книг Дядюшки Боба и даже посвятил этому отдельную статью.

Еще хотелось бы отметить, что книга Dependency Injection in .NET от Марка Симана, которая находится в разделе "Проектирование в контексте платформы .NET", актуальна для любой платформы со статически типизированным языком. И будет очень полезна Android-разработчикам в том числе.

http://sergeyteplyakov.blogspot.ru/2014/07/books-on-design-and-ood.html

#Кейсы
Обработка результата отдельного сценария

1) Имеется экран "Список карт лояльности"
2) На экране есть кнопка "Добавить новую карту"
3) При нажатии кнопки открывается визард, который состоит из цепочки активити
4) При прохождении сценария, нужно:
- закрыть все экраны сценария
- отобразить обновленный список карт
- показать snack уведомление, что карта добавлена

Приведем возможные варианты реализации:

Вариант 1.
Дефолтными средствами AOS
Реализуем старт активити с помощью startActivityForResult и в onActivityResult при необходимости делаем finish()

Вариант 2.
На основе Cicirone
Подробности можно посмотреть в @Cicerone_RUS

Вариант 3.
С использованием общего интерактора
- Создаем интерактор, который доступен на экране списка карт лояльности и финальном экране визарда.
- Всем активити визарда в манифесте устанавливаем значение taskAffinity как AddLoyaltyCardWizard
- При добавлении карты на финальном экране происходит два действия:
1) Интерактор оповещается о добавлении карты. По этому действию он может инициировать обновление списка и отображение оповещения
2) Вызывается finishAffinity

В данной реализации нужно обратить внимание на потенциальную возможность убийства активити системой.

Как работает taskAffinity можно прочитать в https://developer.android.com/guide/topics/manifest/activity-element.html#aff

#статьи

Товарищ @ikomarov интересуется IPC (Inter process communication) и предлагает подборку статей по IPC и Binder Framework.

Стоит иметь в виду, что часть из них была написана "пол жизни андроида" (4 года) назад, но, скорее всего, такие фундаментальные вещи изменились не сильно. К примеру, там указывается, что использование низкоуровневого Binder framework'a дает гораздо большую скорость, чем Messenger'a или других обёрток. Оптимизировали ли обёртки с тех пор? Мы не берёмся сказать. Если у вас есть опыт в этом вопросе - пишите в https://t.me/Android_Architecture

Итак, статьи:

https://events.linuxfoundation.org/images/stories/slides/abs2013_gargentas.pdf

http://rts.lab.asu.edu/web_438/project_final/Talk%208%20AndroidArc_Binder.pdf

https://www.dre.vanderbilt.edu/~schmidt/cs282/PDFs/8-Services-and-IPC-parts-14-15-and-16.pdf

http://blog.checkpoint.com/wp-content/uploads/2015/02/Man-In-The-Binder-He-Who-Controls-IPC-Controls-The-Droid-wp.pdf

#Для_начинающих

Вопрос:
Стоит ли в начале пути изучения Java, Android сразу же продумывать архитектуру и применять паттерны?

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

#Hot_news

Ребят, всем привет!
Рады вам представить архитектурный CookBook v0.1 - https://github.com/AndroidArchitecture/AndroidArchitectureBook!
Это нужно читать всем!
Ждем отзывов, предложений и замечаний!
Всем отличных выходных!

#hot_news

Всем привет!
А мы продолжаем работу над КукБуком (https://github.com/AndroidArchitecture). Все уже имели возможность ознакомиться.
Поэтому я создал issues - https://github.com/AndroidArchitecture/AndroidArchitectureBook/issues
В одной из них - https://github.com/AndroidArchitecture/AndroidArchitectureBook/issues/13, затронут фундаментальный вопрос, связанный с будущим КукБука, его структурой, предназначением и прочим. В данной issue вы можете высказать свое мнение, свое видение, свою критику, ну и вообще, полезен ли данный материал для вас.
В остальных issues я накидал некоторые задачи. Пока они на уровне набора инициативных людей с их идеями и предложениями.
Так что предлагаю всем принять участие в дискуссии =)

Господа!
Рад представить свою новую статью на ваш суд)
Многомодульность в Android с точки зрения архитектуры. От А до Я
https://habr.com/company/kaspersky/blog/422555/

Лайки, комменты, обсуждения и репосты горячо приветствуются!

Ребят, всем привет!
Пробуем новый формат встреч.
Гоу по ссылке и вэлкам =)
Первая встреча будем посвящена Многомодульности. Пошумим с пивком и пиццей!!
https://habr.com/ru/company/kaspersky/blog/441102/