Android Architecture - summary

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

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

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

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

#статьи Товарищ @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.pdfhttp://rts.lab.asu.edu/web_438/project_final/Talk%208%20AndroidArc_Binder.pdfhttps://www.dre.vanderbilt.edu/~schmidt/cs282/PDFs/8-Services-and-IPC-parts-14-15-and-16.pdfhttp://blog.checkpoint.com/wp-content/uploads/2015/02/Man-In-The-Binder-He-Who-Controls-IPC-Controls-The-Droid-wp.pdf

#КейсыОбработка результата отдельного сценария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

#книгиПредставляем вашему вниманию статью с подборкой книг по дизайну и ООП. В статье, кроме самих книг, автор дает советы о выбре книг как новичкам, так и продвинутым разработчикам. А так же о каждой книге написана небольшая рецензия. Автор подборки, кстати, так же является автором многочисленных статей о проектировании ПО и замечательной книги про паттерны проектирования (можете легко найти ее сами по ссылке на статью). Интересно, что автор критикует одну из книг Дядюшки Боба и даже посвятил этому отдельную статью. Еще хотелось бы отметить, что книга Dependency Injection in .NET от Марка Симана, которая находится в разделе "Проектирование в контексте платформы .NET", актуальна для любой платформы со статически типизированным языком. И будет очень полезна Android-разработчикам в том числе.http://sergeyteplyakov.blogspot.ru/2014/07/books-on-design-and-ood.html

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

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

#кейсыВопрос:Есть активити с тулбаром, внутри которой переключаются фрагменты. Как из вьюшки (фрагмента) взаимодействовать с тулбаром (например поменять тайтл)?Что предлагаем:Вариант 1:Тулбар в данном случае будет независимой вьюшкой, со своим собственным презентером. Презентер тулбара подписывается на модель (репозиторий), которая хранит состояние тулбара. Эта модель является глобальной для всех презентеров внутри этой активити. Остальные презентеры при надобности имеют право писать в модель, а презентер тулбара должен соответственно реагировать на ее изменения.Вариант 2:Зачастую надобности в глобальном тулбаре нету. Тогда у каждого фрагмента можно сделать собственный тулбар. Поскольку в данном случае он будет являться частью текущей вьюшки, то презентер сможет обращаться к нему напрямую (например через метод во вью setTitle)

#кейсы Вопрос: от сервера в Repository приходит флаг, по которому необходимо разлогинить пользователя. Но перед этим мне необходимо почистить все данные пользователя (SharedPreferences, Database). Этот флаг может придти в любом запросе. Получается, что необходимо в каждый Repository Inject-ить LogoutResolver или реализовать эту логику на уровне BaseRepository?Вариант 1: Ввести декоратор для репозтория, в который инжектиться все необходимое для очистки данных. Однако, если у декоратора нет полной информации о том, как должны очищаться остальные репозитории (они могут хранить что-то в других преференсах, бд, файлах), то по-прежнему остаётся проблема того, что эти репозитории нужно как-то уведомить о необходимости очистки.Один из вариантов - создать список слушателей в декораторе, куда подключать все репозитории. В дальнейшем, если один репозиторий поймал событие о разлогине, уведомляются все репозитории-слушатели и выполняют свою логику по очистке.Недостаток: многовато кода и недостаточно легко масштабируемо.Вариант 2:Можно ввести специальную новую сущность, например, DataCleaner.Он будет инжектиться в интерсептор OkHttpClient, но при этом будет имет доступ в БД и Преференсам, чтобы почистить их.То есть все будет разруливаться в дата слое без Репозитория и прочего.При этом, если есть, допустим, несколько файлов Преференсов, и их нужно все почистить, то для большего удобства можно ввести что-то вроде PreferencesFacade, который бы предоставлял унифицированный доступ ко всем файлам нужным. И собственно из Репозиториев тоже можно работать с преференсами через него. Тогда точно ничего не забудется.

#кейсыЕсли посмотреть лекции дядюшки Боба, интерактор отвечает за бизнес логику и ничего не знает о внешних фреймворках, 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 в новом слое мы знаем, на каком потоке он выполнится. Минус подхода - зачастую, будут излишние переключения.

#статьи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

#оВечномЯ хочу быть ниндзя и расслоить мой проект как врага сюрекенами, но есть Glide, неужели его кишки тоже надо раскидать по всему проекту? Что делать?Да, Glide (как и Пикассо, Фреско, УИЛ и тд) отличная вещь, не надо от нее отказываться.Тут тебе и загрузка картинок, и пост обработка и кеши всякие.Но, скажете вы, вьюха должна быть тупой, а картинка приходить из дата слоя. В теории все так, но в реальном мире надо уметь находить компромиссы, которые помогут писать проект и чисто и быстро.(умение формулировать компромиссы появляется ТОЛЬКО с опытом, поэтому мы и создали этот чат, чтобы неопытные не выдумывали боль из ничего)Итак, что с загрузкой картинок? Компромисс здесь в том, что мы будем считать, что вью каким-то образом умеет отображать URL картинки как саму картинку и все! Вас же не смущает, что вебвью смогло загрузить веб-страницу по переданной ссылке? Поэтому смело забывайте про загрузку картинок и передавайте их в виде ссылке внутрь вью!

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