Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 44
Аббревиатура RESS в мобильном мире когда-то закрепилась за Responsive Design + Server Side (https://www.lukew.com/ff/entry.asp?1392).
Хорошо было бы посмотреть на вашу архитектуру в действии. Может вам стоит написать какое-нибудь приложения для демонстрации? Честно говоря у меня возникает сомнение в целесообразности применении данной архитектуры даже в средних приложениях. Что-то подобное у нас делал Junior разработчик в небольшом проекте и от этого кода дыбом волосы становились, особенно, когда мне пришлось исправлять баги и дорабатывать экраны…
В статье есть пример небольшого приложения, опущены только детали реализации UI
Отсутствие проблем с Activty lifecycle, поворотами экрана, упрощение архитектуры и как следствие увеличение понимания системы любым членом команды, уменьшение количества мусорного кода, упрощение поддержки, ускорение и удешевление стоимости разработки для вас нецелесообразно?
Честно говоря у меня возникает сомнение в целесообразности применении данной архитектуры даже в средних приложенияхТак приведите аргументы почему?
Отсутствие проблем с Activty lifecycle, поворотами экрана, упрощение архитектуры и как следствие увеличение понимания системы любым членом команды, уменьшение количества мусорного кода, упрощение поддержки, ускорение и удешевление стоимости разработки для вас нецелесообразно?
делал Junior разработчик в небольшом проекте и от этого кода дыбом волосы становилисьА от статей по VIPER у вас волосы дыбом не встают? Вы точно уверены кто там у вас джуниор в команде? Ну и скорее всего ваш джун просто все коряво сделал
В статье есть пример небольшого приложения, опущены только детали реализации UI
Я, наверное, не правильно выразился. Я имел ввиду законченное клиент-серверное приложение среднего масштаба. Например небольшой клиент для GitHub. Ваш пример очень простой и может не выявить определённых проблем в архитектуре, а они присутствуют в любой из них. Тем более я уверен, что Вы будете дальше развивать вашу архитектуру, и мне, как неуверенному джуниору, нужен будет пример реализации
Отсутствие проблем с Activty lifecycle, поворотами экрана, упрощение архитектуры и как следствие увеличение понимания системы любым членом команды, уменьшение количества мусорного кода, упрощение поддержки, ускорение и удешевление стоимости разработки для вас нецелесообразно?
Сильное заявление, проверять я его, конечно, не буду. Если сделаете рабочее приложение и выложите на GitHub, будет очень круто. Ну а пока я просто вижу несколько проблем, которые, конечно, можно решить, но надо посмотреть как это всё будет работать вместе и не усложнит ли всю архитектуру. Далее привожу естественно возникшие вопросы
- В каком компоненте будет реализована навигация?
- Я так понимаю, что данные в DataStorage пока не чистятся. В какой момент будет происходит очистка?
- Будет ли активность использовать несколько Request и DataStorage для переиспользования кода?
- Могу ли отменить Request?
- Как обрабатываются ошибки?
Думаю хватит, не буду к каждой мелочи придираться. Вообще это хорошо, что ты придумываешь как было бы лучше писать приложения, но трудно оценить реальную пользу на искусственном примере
А от статей по VIPER у вас волосы дыбом не встают?
Я Android разработчик, у нас VIPER не так популярен как на iOS, но благодаря Вам я прочёл одну статью, и на удивление мне всё понятно. Это обычная реализация Clean Architecture
Сразу скажу, предлагаемая архитектура в статье описывает вопросы по проектированию приложения, а не то, на какой секунде выполения удалять данные из кеша, это зависит от задачи
Зависит от вашей задачи и требований. Самый частые кейсы — перезаписывать новыми данными, удалять лишние при обновлении.
Я имел ввиду законченное клиент-серверное приложение среднего масштаба. Например небольшой клиент для GitHub.Если будет свободное время, то выложу конечно
Сильное заявление, проверять я его, конечно, не буду.Аргументация уровня ТНТ
В каком компоненте будет реализована навигация?Что вы имеете ввиду под навигацией? Переходы между Activity? Как правило в Activity. В кейсах когда Activity на экране нет, то подходящий вариант — Application
Я так понимаю, что данные в DataStorage пока не чистятся. В какой момент будет происходит очистка?
Зависит от вашей задачи и требований. Самый частые кейсы — перезаписывать новыми данными, удалять лишние при обновлении.
Будет ли активность использовать несколько Request и DataStorage для переиспользования кода?Вопрос вообще не очень корректно поставлен. Request\DataStorage — статик классы, вы можете использовать их из любой части приложения. В RESS рекомендуется делать по одному Request и DataStorage на все приложение, и разбивать их на несколько только в случае сильного разрастания их объема(Например, при широком API, или большом разнообразии данных)
Могу ли отменить Request?Опять же, не корректный вопрос. Request — статик класс с набором методов, делающим запросы к REST-API, а не отдельный запрос. Если вы хотели, спросить можно ли отменить запрос посланный к сервису, этого нет в примере, но никаких ограничений архитектура не накладывает.
Как обрабатываются ошибки?Зависит от задач и типа ошибок. Ошибки от сервиса приходят вместе с answer в листенер подписанный на Request. Подписывайтесь где вам удобно и обрабатывайте. Визуальные можете в Activity, с данными в DataStorage, или вообще вынести отдельный статик ErrorHandler. Не думаю что это имеет смысл разжовывать, это очевидно
Я Android разработчик, у нас VIPER не так популярен как на iOS, но благодаря Вам я прочёл одну статью, и на удивление мне всё понятноХорошо. Вот, например, мне не все понятно. Если вы разобрались, распишите почему разбиение одного экрана приложения, даже очень простого, на ~10 сущностей(Router, Configurator, Presenter, Interactor, View и интерфейс к каждому) и файлов некоторые люди, в том числе видимо и вы, считают адекватным инженерным подходом?
Далее не вижу смысла задавать вопросы, лучше посмотрю на реализацию всего этого чуда. Лучше отвечу про VIPER, а точнее про то как я реализовываю Clean Architecture в своём приложении. Становится ясно, что вы не поняли её смысл. Никаких 10 сущностей на каждый экран нет. На каждый экран есть View и Presenter, причём презентер в некоторых редких случаях можно переиспользовать. Роутер у вас один на всё приложение, а не на каждый экран, не знаю откуда вы это взяли вообще. Далее интеракторы и репозитории тоже на всё приложение и разбиты по фичам, то есть максимально переиспользуются во всём приложении. Далее даю ссылки на статью1 и статью2 для ознакомления. Вы же пишите в топик по Android и должны их в пример приводить, а не VIPER с реализацией под iOS. Судя по вашему коду и ответам на вопросы у вас не так много опыта в разработке больших приложений под Android. Не хотелось бы ещё разводить холивар по поводу переноса фигурной скобки на новую строку, но в Java так не пишут, есть устоявшийся стиль форматирования (Ctrl + Alt + L в помощь)
но в Java так не пишут, есть устоявшийся стиль форматированияВсю жизнь в джаве скобку на новую строку ставил и никто не умер. В тексте прям чувствуется ваше желание меня поучить. Вы на чем-то кроме джавы писали?
Вы же пишите в топик по Android и должны их в пример приводить, а не VIPER с реализацией под iOSВы видите прям такую принципиальную разницу между этими системами в части реализации архитектуры?
На каждый экран есть View и PresenterПро интерфейс для View не забыли? Итого, классический MVP. По 3 сущности на экран. Уже не 10 конечно, но тоже перебор.
Далее интеракторы и репозитории тоже на всё приложение и разбиты по фичамАга, видимо по одному интерактору и репозиторию на фичу, а фича чаще всего соответствует экрану. Т.е добавили новую фичу, впилили кучу классов и интерфейсов на всех уровнях, и это еще без реализации самой фичи. Это адекватный инженерный подход? Ок
В приведенных вами статьях, нет ни слова про VIPER. А в той, что привел я, автор предлагает делать ViewController, Presenter, Iteractor, Configurator под каждый экран, и говорит что это соотвествует принципам Clean Architecture. Вы же говорите третье.
Где же правда?
В любом случае даже в приведенных вами статьях, как и в VIPER подходах, общий посыл это наплодить 100500 сущностей, где можно обойтись двумя-тремя. Автор вероятно в детстве порезался бритвой Оккама
Дабы не быть многословным, я просто подскажу книгу, которая поможет тебе в твоём познании в архитектуре приложений. У тебя огромные пробелы в понимании чистого кода и архитектуры. Я просто не хочу сейчас разводить бессмысленные споры в комментариях
Мартин Роберт. Чистая архитектура. Искусство разработки программного обеспечения
Мартин Роберт. Чистая архитектура. Искусство разработки программного обеспечения
Наконец-то свидетели MVP подъехали, без вас было скучно
Как сказал один мой друг увидев ваш комент:
1. См.цитату
2. См.цитату
3. См.цитату
4. В листенере несколько методов? Проблема проблем. См.цитату
5. Показывать после второго? State
6. Плохо читали статью. dataStorage отвечает в том числе и за приведение данных в удобоваримый вид
7. См. пункт 6
8. Натягиваение глобуса на сову
9. Какие конкретно? Скобка не там — ррря, проблемы с кодстайлом!
Архитектура регламентирует подход к проектированию, а не количество ифов в методе. Вы не можете элементарно модифицировать простейший код чтобы несколько ифов убрать, как маленькие прямо.
Зато считаете что разбираетесь в проектировании, прочитав пару статей про Clean и MVP
Как сказал один мой друг увидев ваш комент:
Чувак не может url в конфиг вынести, о чем ещё говорить?)
1. См.цитату
2. См.цитату
3. См.цитату
4. В листенере несколько методов? Проблема проблем. См.цитату
5. Показывать после второго? State
6. Плохо читали статью. dataStorage отвечает в том числе и за приведение данных в удобоваримый вид
7. См. пункт 6
8. Натягиваение глобуса на сову
9. Какие конкретно? Скобка не там — ррря, проблемы с кодстайлом!
Архитектура регламентирует подход к проектированию, а не количество ифов в методе. Вы не можете элементарно модифицировать простейший код чтобы несколько ифов убрать, как маленькие прямо.
Зато считаете что разбираетесь в проектировании, прочитав пару статей про Clean и MVP
1. Аннотации
2. Я и не спорю что код в примерах не идеален, это не главное в статье
3. Запросы в мапку, отменять по idшнику. Один метод cancel(id). Очевидные вещи нужно расписывать?
4. В чем проблема то вообще? Вы предлагаете делать по одному листенеру на ответ или что?
5. А вы ответ читали? Обновлять UI после последнего ответа из нескольких и никаких флагов
6. Проблема проблем. Ну назовите подругому
8. Вы в качестве плюса MVP приводите смехотворный и вообще сомнительный пример. Обычно чем занимается экран понятно по названию, или проблемы в нейминг?
9. Нечего сказать — докопайся до орфографии. Так и вопрос был, какие именно проблемы со структурой? И как сделать лучше, по-вашему?
Ну в целом я согласен, что видимо стоит в примеры вылизанный вариант выкладывать, чтобы можно было сразу в проект копировать, а не головой думать
2. Я и не спорю что код в примерах не идеален, это не главное в статье
3. Запросы в мапку, отменять по idшнику. Один метод cancel(id). Очевидные вещи нужно расписывать?
4. В чем проблема то вообще? Вы предлагаете делать по одному листенеру на ответ или что?
5. А вы ответ читали? Обновлять UI после последнего ответа из нескольких и никаких флагов
6. Проблема проблем. Ну назовите подругому
8. Вы в качестве плюса MVP приводите смехотворный и вообще сомнительный пример. Обычно чем занимается экран понятно по названию, или проблемы в нейминг?
9. Нечего сказать — докопайся до орфографии. Так и вопрос был, какие именно проблемы со структурой? И как сделать лучше, по-вашему?
Если ты не согласен с моим мнением, то удоли статью!Я смотрю вы критику и сами не воспринимаете толком. Вы приводите недостатки кода в конкретном примере. Я же отвечаю что, конкретно к архитектуре большая часть этих недостатков отношения не имеет. Код в статье чтобы показать общую схему работы, а не чтобы его копипастить.
Ну в целом я согласен, что видимо стоит в примеры вылизанный вариант выкладывать, чтобы можно было сразу в проект копировать, а не головой думать
1. Решают
2. Еще, раз, в статье описан подход, а вы хотите чтобы я каждый чих регламентировал. А потом набежит еще десяток таких как вы и будет спорить сколько на самом деле методов должно быть в листенере по фен-шую. Пусть лучше каждый сам для себя эти мелочи решает. На AsyncTask я не настаивал, в статье прямым текстом написано, используйте че хотите если не нравится AsyncTask. AsyncTask там для примера, чтобы показать тем, у кого с ним возникают проблемы, что проблемы не с ним, а в архитектуре. И в RESS с ним никаких проблем нет
Вся суть RESS это:
1. сетевые запросы в отдельный статик\синглтон класс
2. все данные в хранилище данных в отдельный статик\синглтон класс
3. активити и фрагменты как стандартные viewcontroller, данные берут только из хранилища
4. однонаправленный поток данных через эвенты -> Request -> Storage -> UI
Как это будет реализовано, не особо важно
Да, теперь я согласен с вами, что в статье стоит приводить вылизанный код.
3. А вы видимо часто 3 строчки кода заменяете на готовую библиотеку. Юношеский максимализм, что поделать
4. То что вы описываете, это вообще не проблема. нравится делать сотню разных листенеров вместо 1-2 — делаете, если считаете что так правильнее.
6. Непонятно пока только вам.
8. Вы высасываете преимущество из пальца. Да, давайте сделаем 3 класса место одного, наделеем между ними мусорных связей, раздуем код, будем заниматься бессмысленными рассуждениями о том, какая часть кода относится чисто ко view, а какая еще и логику содержит.
9. Так и что конкретно вам не нравится в стркутуре класса?
P.S. спорю с человеком, который вопросы на StackOverflow задает в русскоязычном разделе, мне стыдно
2. Еще, раз, в статье описан подход, а вы хотите чтобы я каждый чих регламентировал. А потом набежит еще десяток таких как вы и будет спорить сколько на самом деле методов должно быть в листенере по фен-шую. Пусть лучше каждый сам для себя эти мелочи решает. На AsyncTask я не настаивал, в статье прямым текстом написано, используйте че хотите если не нравится AsyncTask. AsyncTask там для примера, чтобы показать тем, у кого с ним возникают проблемы, что проблемы не с ним, а в архитектуре. И в RESS с ним никаких проблем нет
Вся суть RESS это:
1. сетевые запросы в отдельный статик\синглтон класс
2. все данные в хранилище данных в отдельный статик\синглтон класс
3. активити и фрагменты как стандартные viewcontroller, данные берут только из хранилища
4. однонаправленный поток данных через эвенты -> Request -> Storage -> UI
Как это будет реализовано, не особо важно
Да, теперь я согласен с вами, что в статье стоит приводить вылизанный код.
3. А вы видимо часто 3 строчки кода заменяете на готовую библиотеку. Юношеский максимализм, что поделать
4. То что вы описываете, это вообще не проблема. нравится делать сотню разных листенеров вместо 1-2 — делаете, если считаете что так правильнее.
Спойлер
5. Конечно. Обработка нескольких запросов, приходящих в разном неопределенном порядке в любой архитектуре будет выглядеть убогоне правильнее
6. Непонятно пока только вам.
8. Вы высасываете преимущество из пальца. Да, давайте сделаем 3 класса место одного, наделеем между ними мусорных связей, раздуем код, будем заниматься бессмысленными рассуждениями о том, какая часть кода относится чисто ко view, а какая еще и логику содержит.
Спойлер
В итоге получим либо кашу, либо кашу которую нужно регулярно рефакторить. Естественно наделаем больше ошибок и багов. И чтобы эту проблему решить, обложим тестами. В итоге пишем херовый код, чтобы потом его тестами сделать менее херовым. Но ЗАТО, вы можете взглянуть на интерфейс и понять что происходит, и это если в интерфейсе хороший нейминг.В клиентских приложениях — все приложение одно большое View, нет четких критериев чтобы разделить значительную часть логики и представления
9. Так и что конкретно вам не нравится в стркутуре класса?
потому что меня сейчас не критикуютКак это? Я вас критикую.
все недостатки имеют отношение к архитектуреРеально? Т.е. если я сейчас перепишу код из статьи на идеальный, оставив ту же архитектуру, вы скажете что недостатки архитектуры исчезли? Браво
«mvp — слишком сложна, я не хачу думать»Думать надо над решением задач, а не над тем как побольше абстракций в архитектуру запихать. MVP — не сложна, а избыточно сложна, дополнительный слой абстракции должен упрощать систему, а в MVP он усложняет, это fail. Ваше поколение почемуто считает, что чем сложнее — тем круче, нет — чем сложнее в архитектуре тем хуже. Сделать просто сложнее, чем сделать сложно. Думать не хочет не тот, кто видит лишнюю сложность, а тот кто усложняет вместо того чтобы подумать и упростить.
P.S. спорю с человеком, который вопросы на StackOverflow задает в русскоязычном разделе, мне стыдно
Чтобы вы совсем со стыда сгорели можете еще с 1сником поспорить).
По теме — сильно не вникал в спор, читал ради развлечения, но вроде как
вполне нормально должна выглядеть с RX, Observable.combineLatest. Или чем то подобным, по крайней мере интуитивно кажется что должно лечь.
По теме — сильно не вникал в спор, читал ради развлечения, но вроде как
Конечно. Обработка нескольких запросов, приходящих в разном неопределенном порядке в любой архитектуре будет выглядеть убого
вполне нормально должна выглядеть с RX, Observable.combineLatest. Или чем то подобным, по крайней мере интуитивно кажется что должно лечь.
Ох, мой юный друг, в вашем возрасте я точно так же рассуждал и думал что все знаю. Только ваше поколение в добавок к этому еще думает догмами и паттернами, а не головой. Чистая Архитектура — манна небесная, разделять логику и представление нужно во что бы ты ни стало, чем больше абстракций — тем лучше, на каждый чих по отдельному классу — идеально, 100% покрытие тестами и т.п.
Реальность же состоит в том, что везде нужен баланс. Нет 100% правильного варианта, но ударяться в крайности почти всегда — неправильно. Где-то нужно оставить задел на будущее, а где-то нафиг не надо. Гдето нужно разбить класс или интерфейс на несколько, а где-то хватит одного. Где-то нужно выделить абстракцию, а где-то написать все в одном месте. Вам это еще предстоит понять, вы пока нахватались модных веяний с строго им следуете.
Нужно не каждый раз выносить отдельный слой дата, на случай если бек поменяется, а сначала оценить вероятность того что это вообще случится, и время на внесение изменений в код в данном случае. Если выгоднее будет переписать, то смысла оставлять задел нет.
Тем более что в моем случае изменений будет ровно столько же, если не меньше, тупо потому что кода меньше.
Про разделение логики и представления я уже писал. В клиентских приложениях это разделение весьма условно и размыто. В большинстве случаев разнесение View и Presenter приводит тупо к дублированию мусорного кода в обоих классах и либо говнокоду, либо постоянному рефакторингу.
То что вы этого не понимаете, говорит о том, что проектировать вы не умеете, и опыта самостоятельного проектирования архитектуры у вас нет. Прочитать книжку про Clean Arhitecture еще не значит уметь проектировать. * Шутка про фотографов и ноутбук *
Если задача стоит сделать табуретку — тупо доска + 4 ножки это идеальное решение, если этого мало то можно приделать спинку. Вы же считаете что нужно всегда делать кресло с кожаной обивкой, подлокотниками, пружинами и гидравлическим механизмом. И обязательно модульное, а то вдруг нужен будет не гидравлический механизм, а электрический. А о том, что вероятность этих изменений в данной задаче равна 0.001% вы естественно не думаете.
Вы сами то крупные проекты делали? То, что лежит у вас на гитхабе, это откровенная мелочь. Они конечно кому-то могут казаться средними, но это исключительно из-за раздутой архитектуры. И половина коммитов — рефакторинг, think about it.
Поработайте в реальных проектах, реальных командах с реальными людьми, состоящими не целиком из адептов вашей секты Чистого Кода, сильно удивитесь. Это когда пишешь все один по фану и дедлайнов нет, можно бесконечным рефакторингом и написанием лишнего кода заниматься, а в реальной жизни и времени это все у вас не будет, и соседи по команде будут пачкать ваши чистые абстракции, и MVP они будут понимать по-другому, потому что фанатеют от другого гуру.
И все ваши влажные мечты про просто поменять слой data пойдут прахом, когда будете за 5 минут до дедлайна за джуном код рефакторить, потому что он наплевал на ваши абстракции и убежал в универ экзамены сдавать.
Реальность же состоит в том, что везде нужен баланс. Нет 100% правильного варианта, но ударяться в крайности почти всегда — неправильно. Где-то нужно оставить задел на будущее, а где-то нафиг не надо. Гдето нужно разбить класс или интерфейс на несколько, а где-то хватит одного. Где-то нужно выделить абстракцию, а где-то написать все в одном месте. Вам это еще предстоит понять, вы пока нахватались модных веяний с строго им следуете.
Нужно не каждый раз выносить отдельный слой дата, на случай если бек поменяется, а сначала оценить вероятность того что это вообще случится, и время на внесение изменений в код в данном случае. Если выгоднее будет переписать, то смысла оставлять задел нет.
Тем более что в моем случае изменений будет ровно столько же, если не меньше, тупо потому что кода меньше.
Про разделение логики и представления я уже писал. В клиентских приложениях это разделение весьма условно и размыто. В большинстве случаев разнесение View и Presenter приводит тупо к дублированию мусорного кода в обоих классах и либо говнокоду, либо постоянному рефакторингу.
ваш вариант является самой тупой реализацией
реализация очень тупаяХа-ха, так вот что вы не понимаете, вы считаете что тупо это проблема. Нет, в проектировании систем — тупо это хорошо, чем тупее тем лучше. Вот когда слишком тупо, чтобы решать поставленные задачи — тогда плохо, нужно усложнять.
То что вы этого не понимаете, говорит о том, что проектировать вы не умеете, и опыта самостоятельного проектирования архитектуры у вас нет. Прочитать книжку про Clean Arhitecture еще не значит уметь проектировать. * Шутка про фотографов и ноутбук *
Если задача стоит сделать табуретку — тупо доска + 4 ножки это идеальное решение, если этого мало то можно приделать спинку. Вы же считаете что нужно всегда делать кресло с кожаной обивкой, подлокотниками, пружинами и гидравлическим механизмом. И обязательно модульное, а то вдруг нужен будет не гидравлический механизм, а электрический. А о том, что вероятность этих изменений в данной задаче равна 0.001% вы естественно не думаете.
поучаствуйте в крпных проектах, поймёте недостатки, а сейчас вы мыслите слишком недалёкоЯ учавствовал, и в этих проектах использовали RESS, она прекрасно масштабируется до больших размеров, особенно если головой думать, а не догмам по инструкции следовать. Если в проектах такого масштаба использовать Чистую Архитектуру, там половину времени будет занимать рефакторинг, а IDE от количества файлов повесится просто, не говоря уже о том что размер проекта выйдет за рамки понимания.
Вы сами то крупные проекты делали? То, что лежит у вас на гитхабе, это откровенная мелочь. Они конечно кому-то могут казаться средними, но это исключительно из-за раздутой архитектуры. И половина коммитов — рефакторинг, think about it.
Поработайте в реальных проектах, реальных командах с реальными людьми, состоящими не целиком из адептов вашей секты Чистого Кода, сильно удивитесь. Это когда пишешь все один по фану и дедлайнов нет, можно бесконечным рефакторингом и написанием лишнего кода заниматься, а в реальной жизни и времени это все у вас не будет, и соседи по команде будут пачкать ваши чистые абстракции, и MVP они будут понимать по-другому, потому что фанатеют от другого гуру.
И все ваши влажные мечты про просто поменять слой data пойдут прахом, когда будете за 5 минут до дедлайна за джуном код рефакторить, потому что он наплевал на ваши абстракции и убежал в универ экзамены сдавать.
ps в чём проблема русскоязычного StackOverflow? комьюнити тупое?Да, именно так. Все, кто могут идут сразу на англоязычный
я говорил, что в мелкие проекты тащить клин не нужноДа, вот только во все свои мелкие и опубликованные проекты клин вы затащили
такие «крупные» проекты на «великой архитектуре ress», которые никто не хочет поддерживать, потому что написано полное и унылое, я тоже видел достаточноОчевидно, у вас пробелы в понимании того, что такое RESS
вы так аккуратно опустили моё замечание про хабр и тостер,Да потому что это замечание ниочем, подкалывать вы не умеете. Русский SO — бедный родственник англоязычного для тех кто не знает английский с аудиторией из вчерашних школьников. А хабр и тостер самодостаточные сайты, если они вам не нравятся, зачем вы тогда тут сидите?
Про то что, вы неаккуратно опустили 80% моих замечаний, я промолчу, т.к. вам на них видимо ответить нечего.
что я тащу в мелкие проекты — это уже моё делоВ любом случае ваши утверждения расходятся с делом. Вы советуете одно, а делаете другое.
вам же не нравится, что сайт русский, так не пишите на русском сайтеПовторите свой, как вам кажется, очень-очень удачный подкол, четвертый раз, может после этого он станет хоть немного остроумным. Я вам на него уже ответил намного больше раз, чем он этого заслуживает.
ибо слишком скудоумныРаз уже перешли на личности, значит точно по существу ответить нечего.
на медиуме пишут умные люди, знающие англ, а все остальные остались на хабреЕсли судить исключительно по вашим комментариям, то такая мысль конечно может придти в голову, да
Давайте уже закончим этот спор. Очевидно что по существу, вам ответить больше нечего, вы уже начали заниматься сплошной демагогией.
Очень простая архитектура TEA (The Elm Architecture) хорошо себя зарекомендовала в веб-приложениях. В том числе и в работе с http.
Думаю, для мобильных приложений она бы тоже подошла.
Думаю, для мобильных приложений она бы тоже подошла.
Полностью поддерживаю автора. Ушел на похожую «архитектуру» год назад (с MVP, кстати). Не пожалел ни разу:
1. «Эфемерность» андроидных вью решается встроенным объектом стейта (vanilla/Bundle, Icepick), либо «улучшенными фрагментами Conductor».
2. Однонаправленный поток данных? Сетевой слой в сервис (по возможности IntentService — чтобы о байндингах и экземплярах при множественных запросах не думалось). Никаких ответов во вью слой: результат — в удобный storage ObjectBox.
3. Обновление вью? Подписка на представление хранилища (Rx рулит).
4. Несколько сетевых API, использование аппаратных провайдеров, логика на стороне клиента? О да, достаем DI. Только не монструозного Dagger2, а лаконичного Toothpick.
— И, ой! Это же классический MVC?! Ему же лет 40! Фу! Да, это так.
— И что, приложение магазина «весит» меньше 10МБ вместе с картинками? Да, но мне и не за LOC (количество строк кода) платят.
— А какая «магия» нужна для обновления данных отображаемых в неактивном parentView при изменениях в его Child? Никакой, это дефолтная особенность «архитектуры».
Тоже поддерживаю автора. Плюсанул бы, да кармы нет)
Вообще за 5 лет тоже пришел к тому, что существующие решения переусложнены. Сам часто делаю на упрощенной clean, да и только потому, что заказчик непредсказуем, а чистого rest становится всё меньше.
Не понимаю всего фана по архитектуре- многие воспринимают mvp\viper как стандарт де-факто. Ни шагу в сторону. На практике- да, знать их надо, но использовать надо как базу, а не идентичное решение. Как паттерны. Потому чем больше типовых архитектур- тем лучше.
И вообще, всё чаще прихожу к тому, что миром девелоперов сегодня больше управляет мода нежели здравый смысл.
На мой взгляд, RESS (как бы его не называли) выглядит вполне рабочим решением для определенного круга проектов (не только rest).
Два вопроса:
1. Я не против асинктасков, но Вам не кажется, что сегодня ходить в веб через HttpUrlConnection банально опасно, например, отказом нормальной работы? Например, у OkHttp свое обращение с сокетами- бесшовный реконнект, более грамотная работа с heartbeat, нет проблем с gzip и много еще чего. От того HttpUrlConnection, начиная с 5го андроида, основан на OkHttp в кишках.
Пример из практики- надо закачать файл на сервак. Реализация на HttpUrlConnection. На 4.4+ всё норм, на 4.3 возвращалась ошибка. Как выяснилось- рано закрывался сокет, на 4.3 и ниже HttpUrlConnection не умеет его переоткрывать. Решилось переделкой на OkHttp.
На мой взгляд, асинктаски можно использовать в ряде задач вместе с грамотным управлением потоками (экзекуторы), но внутри от HttpUrlConnection лучше отказаться.
2. А что с тестированием на моках? Получается, так или иначе, придем к DI на Gradle Flavours\Dagger и репозиториям? а там уже «привет clean architecture»?
Вообще за 5 лет тоже пришел к тому, что существующие решения переусложнены. Сам часто делаю на упрощенной clean, да и только потому, что заказчик непредсказуем, а чистого rest становится всё меньше.
Не понимаю всего фана по архитектуре- многие воспринимают mvp\viper как стандарт де-факто. Ни шагу в сторону. На практике- да, знать их надо, но использовать надо как базу, а не идентичное решение. Как паттерны. Потому чем больше типовых архитектур- тем лучше.
И вообще, всё чаще прихожу к тому, что миром девелоперов сегодня больше управляет мода нежели здравый смысл.
На мой взгляд, RESS (как бы его не называли) выглядит вполне рабочим решением для определенного круга проектов (не только rest).
Два вопроса:
1. Я не против асинктасков, но Вам не кажется, что сегодня ходить в веб через HttpUrlConnection банально опасно, например, отказом нормальной работы? Например, у OkHttp свое обращение с сокетами- бесшовный реконнект, более грамотная работа с heartbeat, нет проблем с gzip и много еще чего. От того HttpUrlConnection, начиная с 5го андроида, основан на OkHttp в кишках.
Пример из практики- надо закачать файл на сервак. Реализация на HttpUrlConnection. На 4.4+ всё норм, на 4.3 возвращалась ошибка. Как выяснилось- рано закрывался сокет, на 4.3 и ниже HttpUrlConnection не умеет его переоткрывать. Решилось переделкой на OkHttp.
На мой взгляд, асинктаски можно использовать в ряде задач вместе с грамотным управлением потоками (экзекуторы), но внутри от HttpUrlConnection лучше отказаться.
2. А что с тестированием на моках? Получается, так или иначе, придем к DI на Gradle Flavours\Dagger и репозиториям? а там уже «привет clean architecture»?
HttpUrlConnection лучше отказаться.Так я и не против, для примера взял то что под руку подвернулось.
А что с тестированием на моках?А какой в нем смысл? REST-клиент это приложение на 80% состоящее из UI, если и тестировать то UI. А учитывая качество UI-компонентов в Android, то и большая часть багов там. Усложнять код, только для того чтобы протестировать копеечную бизнес логику, не выглядит хорошей идеей
Если говорить о простеньком варианте приложения (который Вы, как я понял, подразумеваете)- то да, тут Вы правы. Но ведь такие rest-клиенты никто (ну или почти никто) в продакшене не ждет?
Добавим сюда кеширование или возможность работы оффлайн, пуши, авторизацию, обновляемые токены. Возможно даже простенький чат на rest. И вот это уже похоже на определенный минимум, который (на мой взгляд) вполне укладывается в RESS, и бизнес-логика там не такая уж и копеечная. Так или иначе придем к тому, что минимум 1-2 компонента надо тестировать
Добавим сюда кеширование или возможность работы оффлайн, пуши, авторизацию, обновляемые токены. Возможно даже простенький чат на rest. И вот это уже похоже на определенный минимум, который (на мой взгляд) вполне укладывается в RESS, и бизнес-логика там не такая уж и копеечная. Так или иначе придем к тому, что минимум 1-2 компонента надо тестировать
То что вы описали, вполне стандартная и не сложная логика, половина вообще обертка над запросами ответами к REST-API, которое и так тестами обложена.
Я вообще скепьтически отношусь к обкладыванию всего и вся тестами, особенно если игнорируется UI. Смысл тратить время на тестирование Presenterа, если потом всеравно косяки во View нам наделают багов. Это вообще какаято малоосмысленная затея, как по мне. Больше похоже на культ карго, чем на реальную необходимость.
Мы усложняем архитектуру, плодим абстракции, затем пишем мусорный код для их связи, как следствие получаем больше багов, тратим больше времени. А потом еще тратим время и пишем тесты, чтобы эти баги отловить. Выгода тут вообще сомнительная
Я вообще скепьтически отношусь к обкладыванию всего и вся тестами, особенно если игнорируется UI. Смысл тратить время на тестирование Presenterа, если потом всеравно косяки во View нам наделают багов. Это вообще какаято малоосмысленная затея, как по мне. Больше похоже на культ карго, чем на реальную необходимость.
Мы усложняем архитектуру, плодим абстракции, затем пишем мусорный код для их связи, как следствие получаем больше багов, тратим больше времени. А потом еще тратим время и пишем тесты, чтобы эти баги отловить. Выгода тут вообще сомнительная
чтобы протестировать копеечную бизнес логику
Ну так Вы рассматриваете простой REST-клиент, для него, естественно, нет нужды брать MVP/VIPER/CA и тестировать бизнес-логику, которой (почти) нет. Но давайте рассмотрим другое приложение, для какого-нибудь интернет-магазина со своими плюшками (стандартный кейс, по мотивам реального приложения).
Берем экран «Корзина», в нем отображается список всех товаров, у каждого своя цена, скидка (для разных клиентов может быть разная), количество (его можно изменить), товар можно удалить. Тут же есть специальные подарки по акциям, у них все аналогично, только сущность другая (и работать с этими данными надо отдельно). Также на экране отображается общая цена и общая скидка, есть другие данные, есть возможность применить купон на доп скидку.
Если бы это был простой REST-клиент, то проблем нет. Но заказчик еще требует, чтобы приложение работало оффлайн. И тут возникает необходимость 1) хранить все данные в приложении, 2) отправлять это данные на сервер, 3) подсчитывать самому всю корзину и все скидки при оффлайн-работе, 3) как-то синхронизировать локальную и серверную корзину и все сопутствующие данные (делать это нужно сначала локально, а потом еще и отправлять серверу и как-то обрабатывать ошибки от сервера) и т.д. Вот тут-то ваша «копеечная бизнес логика» перерастает в огромнейший пласт логики, которую надо протестировать (иначе не оберетесь проблем с заказчиком и с пользователями, которые видели в корзине одну цену и одну скидку, а в итоговом заказе они другие).
Не забывайте, что это все нужно еще и красиво показывать (дизайнера приложения никто не отменял). А значит и отображение, и бизнес-логика по своим объемам значительны (и это все для одного лишь экрана), и их обоих нужно тестировать.
Попробуйте реализовать данный кейс в качестве примера на Вашей архитектуре, и Вы поймете, для чего были придуманы MVP/VIPER/CA.
А можно привести пример, чуть конкретнее? Я не понял, где же, собственно, логика? Или «клиент»-«серверов» несколько?
Ну во приложение с двумя компонентами: 1) поле ввода текста, 2) div, отображающий текст из компонента 1. Тут как будет устроено?
То есть микросервис «поле вывода»: поле-клиент, модель-сервер; микросервис «дисплей вывода»: вью-сервер; и еще сессия. Правильно?
И сессия выступает для каждого из микросервиса и клиентом, и сервером?
И сессия выступает для каждого из микросервиса и клиентом, и сервером?
Несостыковка:
А вообще, создаетсся впечатление, что это эволюция MVC/MVP/etc. Там у нас одна Model, один View/etc., один Controller/etc. А тут: одна Session (похожая на контроллер?) и много Client'ов и Server'ов, которые могут выполнять, в т.ч., роли моделей и вьюх. Итак, отличия: 1) замена на «абстрактные» Client и Server, 2) не по одному, а много.
клиентами могут быть все компоненты кроме Сессии
в Сессию, а та рассылает по своим Вью
А вообще, создаетсся впечатление, что это эволюция MVC/MVP/etc. Там у нас одна Model, один View/etc., один Controller/etc. А тут: одна Session (похожая на контроллер?) и много Client'ов и Server'ов, которые могут выполнять, в т.ч., роли моделей и вьюх. Итак, отличия: 1) замена на «абстрактные» Client и Server, 2) не по одному, а много.
Спасибо за новую архитектуру!
Я правильно понимаю, что «под мобильные приложения» здесь важно, и имеется ввиду «под нынешние фреймворки Android/iOS»? Я не занимался мобильными приложения, но в веб-, используя, полагаю, MVP, я не наблюдал проблемы «усложненной архитектуры», но, надо признать, для этого я написал свою микро-библиотеку (а-ля урезанный React.JS, видимо), то есть я не был стеснен ничем, кроме «вид — это DOM».
P.S. Я не спорю с Вами, я просто хочу сравнить с MVP подробнее. Ибо как увидел схему VIPER, так срочно закрыл вкладку от ужаса. Там все понятно, а про MVP интересно.
Я правильно понимаю, что «под мобильные приложения» здесь важно, и имеется ввиду «под нынешние фреймворки Android/iOS»? Я не занимался мобильными приложения, но в веб-, используя, полагаю, MVP, я не наблюдал проблемы «усложненной архитектуры», но, надо признать, для этого я написал свою микро-библиотеку (а-ля урезанный React.JS, видимо), то есть я не был стеснен ничем, кроме «вид — это DOM».
P.S. Я не спорю с Вами, я просто хочу сравнить с MVP подробнее. Ибо как увидел схему VIPER, так срочно закрыл вкладку от ужаса. Там все понятно, а про MVP интересно.
Вспоминаю — использовал я EventBus и забыл я что такое слушатели. Опыт использования Контроллера Прерываний при проектировании железа как никак был. И было все шустро и красиво. Но народ почему то плевался. Ну очень нравятся слушатели народу. И перешел я на Service Locator. И плевать мне, делим ли мы на View/Presenter/Router или не делим. И плевать мне на все, что выдумает Google, а завтра это же и обосрет. Главное — решает ли проблемы архитектуры андроид вкупе с задачами клиента или нет.
github.com/shishkin1966/CleanArchitecture5
github.com/shishkin1966/CleanArchitecture5
С виду ваша архитектура — обычное MVC.
Не понимаю откуда столько агрессии к MVP, отличная архитектура, которая позволяет отлично разделять логику и переиспользовать компоненты, на данный момент у меня в проекте VIPER(проект больше 200к строчек кода), без випера давно утонул уже километровых классах( презентер в главном экране, где есть куча бизнесс логики — 300 строчек, большая часть методов по 5-10 строчек и обращаются с многочисленными интеракторами, каждый из которых отвечает строго за свою логику), как результат легко тестировать, легко поддерживать, для маленьких и тестовых проектов можно хоть всю логику писать в активити
Не понимаю откуда столько агрессии к MVP, отличная архитектура, которая позволяет отлично разделять логику и переиспользовать компоненты, на данный момент у меня в проекте VIPER(проект больше 200к строчек кода), без випера давно утонул уже километровых классах( презентер в главном экране, где есть куча бизнесс логики — 300 строчек, большая часть методов по 5-10 строчек и обращаются с многочисленными интеракторами, каждый из которых отвечает строго за свою логику), как результат легко тестировать, легко поддерживать, для маленьких и тестовых проектов можно хоть всю логику писать в активити
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
RESS — Новая архитектура для мобильных приложений