#статьи
Как понять по логам тестов что перестало работать? Как упростить понимание кода с помощью тестов? Как сделать тесты более читаемыми? В статье приведены 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/

Ребятки, 24 апреля, Лаборатория Касперского проводит 2-ю встречу Android-разработчиков:
Kaspersky Android Night #Bumblebee

>На встрече мы расскажем про последствия использования кроссплатформенной разработки на реальном проекте (Xamarin), немного с другой стороны посмотрим на Flutter, а в конце, обсудим итоги конференции AppsConf, а так же, вместе со Звиадом Кардавой поговорим на больную для многих тему: "Собирается ли Google убивать Android?"

Регистрация:
https://careers.kaspersky.ru/events/colaboratory-android-night-2-bumblebee/

Всем привет, комрады!
В последнее время в нашем чатике участились случаи флуда, беспредметчины и троллинга.
Все это подтолкнуло меня к обновлению состава админов.
Кто хочет:
- бдить наш уютный чатик
- прокачать свои хард-скиллы погружением в проблемы своих собратьев
- прокачать свои софт-скиллы умелым общением с каждым
- прокачать менеджерские скиллы, обобщая и выделяя общие проблемы, их документирование и тд
- ну и быть плечом к плечу со мной против опасностей архитектурных =)
Милости прошу заполнить эту анкету - https://forms.gle/U1y5X17cwnRMGrBj7
Это займет 3 минуты)
На помощь я уже взял Андрея Прохоренко @aprokhor

Ребят, минутка рекламы на правах автора)

29 мая, в стенах Лаборатории пройдёт Google IO’19: Extended.

Обсудим ключевые изменения, погрузимся в историю релизов Android, а так же, детально поговорим про UI.

Количество мест ограничено.

Регистрация:
https://careers.kaspersky.ru/events/i-o-extended-2019-moscow/

Онлайн-трансляция:
Будет размещена на данной ссылке (регистарция не требуется)

Ребят, если вы хотите погрузиться в автотесты. С чего начать, какую боль пройти, и как ее пройти, то смело смотрите вот это видео!
Мы с Димой и ребятами постарались вложить в этот доклад самое важное и лучшее)
Спойлер: Очень скоро будет выпущен фреймворк, который решает много боли =)
https://youtu.be/q_8UUhVDV7c