Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 18
Всем минусующим просьба аргументировать, что вам не нравится.
Я написал эту статью не ради рекламы, а ради подготовки к выступлению. Чтобы оно было максимально интересно и полезно.
И если у вас есть то, чем вы недовольны, то поделитесь, пожалуйста.
Я написал эту статью не ради рекламы, а ради подготовки к выступлению. Чтобы оно было максимально интересно и полезно.
И если у вас есть то, чем вы недовольны, то поделитесь, пожалуйста.
xoxol_89 Начали за здравие, а дальше просто похожие на рекламные призывы действия — сходи туда, послушай лекции (закончи университет, купи мою книжку), и до конца непонятно читателю — а надо ли ему вообще всё это? Что я получу в итоге, потратив столько времени на это? Стиль изложения сделан так, будто читателя уже убедили, что это надо ЕМУ, а не вам, но читателю еще даже не рассказали, что его ждёт.
Как-то всё сумбурно и непонятно…
Как-то всё сумбурно и непонятно…
Еще добавлю чисто своё очень субьективное мнение, что человек 89-го года рождения (да, мой ровестник), не может (чаще всего. но всегда бывают исключения! я не знаю — исключение ли ваш случай, или нет) толком и внятно говорить про сложные архитектуры систем.
Тут дело всё в том, что возраст молодой, человек учится очень быстро и лет через 5 может полностью изменить своё представление об архитектуре, и будет говорить: забудьте всё, о чем я вам говорил. А пройдёт еще 10 лет, и он будет тоже самое утверждать.
Повторюсь, что это моё слишком субьективное мнение, и оно наверняка ошибочное и не относится ко всем людям 1989 года рождения, я лишь пишу, почему я сомневаюсь в эффектиности чтения ваших лекций.
Тут дело всё в том, что возраст молодой, человек учится очень быстро и лет через 5 может полностью изменить своё представление об архитектуре, и будет говорить: забудьте всё, о чем я вам говорил. А пройдёт еще 10 лет, и он будет тоже самое утверждать.
Повторюсь, что это моё слишком субьективное мнение, и оно наверняка ошибочное и не относится ко всем людям 1989 года рождения, я лишь пишу, почему я сомневаюсь в эффектиности чтения ваших лекций.
Да, и еще не у всех на работе разрешён YouTube, поэтому даже примерно оценить ваше выступление не могу (пока-что). А в статье ничего толком не раскрывается, и всё действительно становится похоже на саморекламу. Хабр всё же пока-что более текстовый ресурс, и люди привыкли заходить на хабр и читать короткий, сжатый и содержательный материал, а не бегать на ютуб и слушать часовые лекции.
Архитектура для мобильного приложения, а конкретно под Андроид — это далеок не архитектура какого-то сложного высоконагруженного сервиса.
Андроид — это все-таки просто клиент, который слушает сервис. Раньше вообще считалось, что под мобильные приложения архитектура так таковая не нужна. Но как показывает жизнь, все-таки нужно грамотно продумывать проект.
Андроид — это все-таки просто клиент, который слушает сервис. Раньше вообще считалось, что под мобильные приложения архитектура так таковая не нужна. Но как показывает жизнь, все-таки нужно грамотно продумывать проект.
>человек 89-го года рождения не может толком и внятно говорить про сложные архитектуры систем
обычно так говорят люди, которые кроме своих лет мало чего достигли
PS: Это чисто своё, очень субъективное мнение и оно наверняка ошибочное и не относится ко всем людям.
обычно так говорят люди, которые кроме своих лет мало чего достигли
PS: Это чисто своё, очень субъективное мнение и оно наверняка ошибочное и не относится ко всем людям.
Эх, пожалуй надо было зарегистрироваться тут под ником blondinka_99 и троллить
Спасибо за статью и возможность поделиться проблемой.
У меня как раз есть проблема и решение, в котором я не уверен.
Когда мы работаем по архитектурной модели, как в примере из твоего выступления про тестируемый код ( т.е. у нас есть: 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)?
У меня как раз есть проблема и решение, в котором я не уверен.
Когда мы работаем по архитектурной модели, как в примере из твоего выступления про тестируемый код ( т.е. у нас есть: 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)?
Нужен ли EventBus нам?
Очень активно использую EventBus, вся работа с Activity из Adapter'ов или Fragment'ов сводится к отправке евентов, вызываю EventBus откуда угодно, даже из кастомных составных View. Намекаете, что это плохо?
Очень активно использую EventBus, вся работа с Activity из Adapter'ов или Fragment'ов сводится к отправке евентов, вызываю EventBus откуда угодно, даже из кастомных составных View. Намекаете, что это плохо?
Все хорошо, если в меру =)
Но раньше было модно все приложение строить на паттерне «Наблюдатель». И все покрывалось сплошным «ЭвентБасом». И часто потом получалась ситуация, когда стреляешь в руку, а попадаешь в ногу. И почему, совсем непонятно.
Высокая связность кода впридачу еще получается. И просто ли такое дело тестировать?
А плохо у вас это в приложение или нет, я не могу сказать :)
Но раньше было модно все приложение строить на паттерне «Наблюдатель». И все покрывалось сплошным «ЭвентБасом». И часто потом получалась ситуация, когда стреляешь в руку, а попадаешь в ногу. И почему, совсем непонятно.
Высокая связность кода впридачу еще получается. И просто ли такое дело тестировать?
А плохо у вас это в приложение или нет, я не могу сказать :)
> получалась ситуация, когда стреляешь в руку, а попадаешь в ногу
Приведите пример, пожалуйста.
> Высокая связность кода впридачу еще получается
Наоборот, EventBus уменьшает связность кода.
К сожалению, ссылку на свои бывшие проекты я дать не могу, NDA. Но уверен, вы бы оценили =)
Если проект небольшой, то все норм. Но если он развивается не первый год, меняются разработчики, то обычно сопровождать код, который черезчур использует паттерн «Наблюдатель», становится тяжко.
Но это сугубо мой опыт.
Если проект небольшой, то все норм. Но если он развивается не первый год, меняются разработчики, то обычно сопровождать код, который черезчур использует паттерн «Наблюдатель», становится тяжко.
Но это сугубо мой опыт.
Строго говоря, EventBus — это не то же самое, что и паттерн «Наблюдатель». В паттерне «Наблюдатель» для того, чтобы Подписчики могли получить событие, Наблюдаемое должно содержать ссылку на коллекцию этих подписчиков. В этом случае, согласен, возникает сильное связывание кода между ними. И чтобы уменьшить связывание, решением может быть вставка третьего компонента между Наблюдаемым и Подписчиками. Этим компонентом как раз и является EventBus. Теперь, вместо того, чтобы Подписчикам регистрироваться в Наблюдаемом, они регистрируются в EventBus'е, и Наблюдаемое направляет события в ИвентБас. Таким образом, события могут иметь любой источник и тот источник можно изменить без необходимости менять код в Подписчиках.
Интересно было бы послушать про master/details, активити с множеством фрагментов, фрагмент с множеством вложенных фрагментов.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Манифест архитектурной боли