Все под кат!
Если ты заглянул сюда, значит нам с тобой по пути, дорогой читатель. Всех нас объединяет одно! Любовь! Любовь к красоте, любовь к порядку, любовь к расширяемости и к тестируемости, любовь к гибкости и поддерживаемости! Да, это любовь к архитектуре.
Архитектура. Как много в этом слове. Как необыкновенно и многогранно оно. Для нас с тобой оно много значит.
Ты прочитал много статей, просмотрел видео, попробовал и реализовал различнейшие примеры. Ты можешь забыть сходить за хлебом, но об архитектуре всегда помнишь.
Или ты только в самом начале пути. Ты учишься, ты стараешься. И ты хочешь, чтобы люди, которые продолжат твой проект, не желали тебе гореть в аду на веки вечные.
Но враг не дремлет! Он создал Android, придумал жизненный цикл, активити и фрагменты, адаптеры и пермишены. И враг дал нам всем этим пользоваться, заманил нас, но при этом не сказал, как правильно пользоваться.
Враги, они такие.
А архитектура она такая, что количество вопросов всегда будет больше количества ответов. И чем дальше, тем больше вариаций ответов. И далеко не всегда эти варианты срабатывают так, как задумывалось.
Год назад я выступал на Mobius 2016 с докладом — «Пишем тестируемый код». Еще на самой конференции мне задавали вопросы, ответы на которые я мог дать далеко не сразу. И я уверен, что, если ты опытный разработчик, у тебя всегда найдется задача, над которой я крепко призадумаюсь.
Еще открою тебе маленький секрет. На форумах часто попадаются одни и те же вопросы. Если почитать код разработчиков, которые пробуют первый раз реализовать «чистую архитектуру», то практически все натыкаются на одни и те же грабли. Тебе не кажется все это странным? Может, стоит упорядочить все эти вопросы и грабли?
Так давай объединим наши усилия, дорогой читатель! Расскажи о своей проблеме, которую не можешь решить ты или твой коллега, или о проблеме, которую удалось победить и решением которой хочется поделиться. Может ты не согласен с так таковой «чистой архитектурой», считая, что «горой абстракции» только все запутывается сильнее. Может у тебя есть свой взгляд, свое мнение на счет всего этого. Или у тебя есть «убийственная задача», которая разрушит наше представление об идеальном мире :) Самое главное не молчи! Расскажи о своей боли!
Любое взаимодействие должно иметь четкий план и четкий результат. Поэтому предлагаю нам с тобой договориться, что мы вообще ожидаем друг от друга.
Дорогой друг, я ожидаю от тебя, что ты:
- Просмотришь мое видео с прошлой конференции.
- Прочитаешь блог Fernando Cejas.
- Почитаешь про RxJava. Я настоятельно рекомендую вот эту книжку. Для меня она стала настоящим открытием, даже несмотря на то, что я себя считал разбирающимся в RxJava. Большое спасибо Дмитрию Полищуку за наводку.
- Почитаешь про Dagger 2. Тут я приведу свои статьи (1, 2). В них указаны ссылки и на другие источники.
- Почитаешь и попробуешь разные библиотеки, которые могут облегчить твою жизнь. Это Moxy, mosby и другие.
- Можешь даже посмотреть примеры от Гугла :)
- Сформулируешь проблемы, вопросы, несогласия. Пиши в комментарии, в личку, на почту. Буду очень рад!
От себя же я обещаю следующее:
- Постараюсь дать аргументированные, ясные и четкие ответы на наиболее задаваемые вопросы. Как пример, это могут быть следующие вопросы. Должен ли быть Context в Presenter? Нужны ли getterы в View или Presenter? Как бороться с legacy кодом? Какова должна быть структура пакетов? Вопросов очень много :)
- Разберу с тобой нетривиальные задачи. Как быть с нагруженным экраном? Можем ли мы заиспользовать сразу несколько Презентеров? Нужен ли EventBus нам? Как быстро ваше приложение перевести на рельсы чистой архитектуры? А если у нас все приложение было построено на паттерне «Наблюдатель», то, что вообще делать то с этим??? Я думаю, у тебя найдется не менее коварный вопрос :)
Времени у нас с тобой не так уж и много — до 21-22 апреля, когда пройдет Mobius 2017 (анонс). Мы должны успеть провести огромную подготовительную работу, чтобы наше финальное общение было наиболее продуктивным!
Хочу обрадовать тебя еще одной новостью! На Mobius будет еще выступать небезызвестный и вышеупомянутый Fernando Cejas. Он планирует рассказать про эволюцию проекта. Про то, как при развитии и росте проекта сохранить его красоту и стройность, расширяемость и поддерживаемость.
И мы с Fernando постараемся, чтобы наши доклады дополняли и развивали друг друга. Ведь мы оба хотим, чтобы ты, дорогой читатель, вышел с конференции вдохновленным новыми идеями и решениями!
Комментарии (17)
TimsTims
18.01.2017 13:05+5xoxol_89 Начали за здравие, а дальше просто похожие на рекламные призывы действия — сходи туда, послушай лекции (
закончи университет, купи мою книжку), и до конца непонятно читателю — а надо ли ему вообще всё это? Что я получу в итоге, потратив столько времени на это? Стиль изложения сделан так, будто читателя уже убедили, что это надо ЕМУ, а не вам, но читателю еще даже не рассказали, что его ждёт.
Как-то всё сумбурно и непонятно…TimsTims
18.01.2017 13:08-7Еще добавлю чисто своё очень субьективное мнение, что человек 89-го года рождения (да, мой ровестник), не может (чаще всего. но всегда бывают исключения! я не знаю — исключение ли ваш случай, или нет) толком и внятно говорить про сложные архитектуры систем.
Тут дело всё в том, что возраст молодой, человек учится очень быстро и лет через 5 может полностью изменить своё представление об архитектуре, и будет говорить: забудьте всё, о чем я вам говорил. А пройдёт еще 10 лет, и он будет тоже самое утверждать.
Повторюсь, что это моё слишком субьективное мнение, и оно наверняка ошибочное и не относится ко всем людям 1989 года рождения, я лишь пишу, почему я сомневаюсь в эффектиности чтения ваших лекций.TimsTims
18.01.2017 13:13-2Да, и еще не у всех на работе разрешён YouTube, поэтому даже примерно оценить ваше выступление не могу (пока-что). А в статье ничего толком не раскрывается, и всё действительно становится похоже на саморекламу. Хабр всё же пока-что более текстовый ресурс, и люди привыкли заходить на хабр и читать короткий, сжатый и содержательный материал, а не бегать на ютуб и слушать часовые лекции.
xoxol_89
18.01.2017 15:24+1Архитектура для мобильного приложения, а конкретно под Андроид — это далеок не архитектура какого-то сложного высоконагруженного сервиса.
Андроид — это все-таки просто клиент, который слушает сервис. Раньше вообще считалось, что под мобильные приложения архитектура так таковая не нужна. Но как показывает жизнь, все-таки нужно грамотно продумывать проект.
iamironz
18.01.2017 15:27+13>человек 89-го года рождения не может толком и внятно говорить про сложные архитектуры систем
обычно так говорят люди, которые кроме своих лет мало чего достигли
PS: Это чисто своё, очень субъективное мнение и оно наверняка ошибочное и не относится ко всем людям.TimsTims
18.01.2017 17:00-3> обычно так говорят люди, которые кроме своих лет мало чего достигли
Либо знающие, насколько глубока тема архитектуры приложений
cclvi
19.01.2017 08:30-1Эх, пожалуй надо было зарегистрироваться тут под ником blondinka_99 и троллить
arturdumchev
18.01.2017 14:30+4Спасибо за статью и возможность поделиться проблемой.
У меня как раз есть проблема и решение, в котором я не уверен.
Когда мы работаем по архитектурной модели, как в примере из твоего выступления про тестируемый код ( т.е. у нас есть: View — Presenter — Interactor — Repository)
и надо перенести данные с одного экрана на другой.
На первом экране мы получаем данные с Repository1.
Затем в Interactor1:
1. перерабатываем эти данные (какая-то затратная работа)
2. строим из них модель, которую можно будет использовать Presencation layer (View, Presenter).
На втором экране нам нужны данные, переработанные в Interactor1.
Как ты считаешь, нормально ли будет разделить Dagger Scope на два экрана, и хранить переработанные в Interactor1 данные в специальном CacheRepository? Interactor1 туда их запишет, а Interactor2 оттуда прочитает.
Плюсы такого решения: не надо в PresentationLayer ни сохранять данные, ни передавать их (повторю, это данные, из которых еще не построена модель. Пусть Presenter хранит в своем кеше модели, которые может использовать View).
Если понадобится обрабатывать ситуацию, когда наше приложение убьет система, то пусть CacheRepository при получение данных сразу сохраняет их на диск (в Realm, например).
Насколько такое решение правильно, по-твоему? Может быть, нужно обернуть Activity в интерфейс и передавать ее до уровня Interactor, чтобы там уже сохранять и передавать данные (через Intent и Bundle)?
csero
18.01.2017 16:33+1Нужен ли EventBus нам?
Очень активно использую EventBus, вся работа с Activity из Adapter'ов или Fragment'ов сводится к отправке евентов, вызываю EventBus откуда угодно, даже из кастомных составных View. Намекаете, что это плохо?xoxol_89
18.01.2017 16:38Все хорошо, если в меру =)
Но раньше было модно все приложение строить на паттерне «Наблюдатель». И все покрывалось сплошным «ЭвентБасом». И часто потом получалась ситуация, когда стреляешь в руку, а попадаешь в ногу. И почему, совсем непонятно.
Высокая связность кода впридачу еще получается. И просто ли такое дело тестировать?
А плохо у вас это в приложение или нет, я не могу сказать :)
ankad
18.01.2017 17:08> получалась ситуация, когда стреляешь в руку, а попадаешь в ногу
Приведите пример, пожалуйста.
> Высокая связность кода впридачу еще получается
Наоборот, EventBus уменьшает связность кода.xoxol_89
18.01.2017 17:14К сожалению, ссылку на свои бывшие проекты я дать не могу, NDA. Но уверен, вы бы оценили =)
Если проект небольшой, то все норм. Но если он развивается не первый год, меняются разработчики, то обычно сопровождать код, который черезчур использует паттерн «Наблюдатель», становится тяжко.
Но это сугубо мой опыт.ankad
18.01.2017 17:52-1Строго говоря, EventBus — это не то же самое, что и паттерн «Наблюдатель». В паттерне «Наблюдатель» для того, чтобы Подписчики могли получить событие, Наблюдаемое должно содержать ссылку на коллекцию этих подписчиков. В этом случае, согласен, возникает сильное связывание кода между ними. И чтобы уменьшить связывание, решением может быть вставка третьего компонента между Наблюдаемым и Подписчиками. Этим компонентом как раз и является EventBus. Теперь, вместо того, чтобы Подписчикам регистрироваться в Наблюдаемом, они регистрируются в EventBus'е, и Наблюдаемое направляет события в ИвентБас. Таким образом, события могут иметь любой источник и тот источник можно изменить без необходимости менять код в Подписчиках.
xoxol_89
Всем минусующим просьба аргументировать, что вам не нравится.
Я написал эту статью не ради рекламы, а ради подготовки к выступлению. Чтобы оно было максимально интересно и полезно.
И если у вас есть то, чем вы недовольны, то поделитесь, пожалуйста.
iamironz
Хабр не торт, Жень (с)