How to become an author
Search
Write a publication
Pull to refresh

Comments 27

Талант!
В первый раз на хабрахабре вижу статью на 70% состоящую из баззвордов.
Total votes 13: ↑10 and ↓3+7
Сорри, я старался быть максимально понятным, не вышло.
Total votes 1: ↑1 and ↓0+1
Я так и не понял, что автор хотел сказать…
Total votes 8: ↑4 and ↓40
Короче это такая супер крутая модная штука, не все пока понимают даже как она и что конкретно делает, но на всякий случай лучше её использовать, потому что вдруг выстрелит и через год во всех вакансиях будут её требовать
Total votes 2: ↑1 and ↓10
Если дату вашего комментария перевести года на 2, то ~правда.

Сейчас это уже штука, которая выстрелила и знание желательно в нормальных вакансиях.
Total votes 8: ↑7 and ↓1+6
знание желательно в нормальных вакансиях

Не знаю, где вы смотрите вакансии, но зашел на jobs.dou.ua, из 60 вакансий по android слово "rxjava" встречается в 3-х. "Rx" нет нигде. То есть, 5% вакансий. И не факт, что эти 3 — самые нормальные.

This comment wasn’t rated yet0
Я соглашусь с Артемом. Дело в том, что этого не называют конкретно в вакансии, но на собеседовании многие компании, которые использую всякие новый технологии, наверняка будут рады, если вы будете знать что-нибудь связанное с Rx. Не говоря о том, что самих проектов на ней под Android становится все больше и больше.
Total votes 3: ↑3 and ↓0+3
А откуда информация про двагис? Я так понимаю 2gis называют дубльгисом, лишь только потому, что он так назывался до ребренгинга.
This comment wasn’t rated yet0
Вроде как продукт называется ДВАгис, а сама компания до сих пор ДульГис
Total votes 1: ↑1 and ↓0+1
в правильной архитектуре под Андроид взаимодействие с сетью, кэширование и вообще вся общая бизнес-логика не должна быть завязана на какие-то андроидные части

Вот это мнение меня всегда удивляло. Мы пишем под android, значит, надо завязываться на это, оптимизироваться под это, использовать там структуры данных из библиотеки саппортов ради скорости, компоненты системы. Это ж мобилка, здесь не до архитектурного оверхеда, надо память экономить, батарейку, а не гонять данные по слоям туда-сюда, как в clean architecture

This comment wasn’t rated yet0
Зря вы про архитектурный оверхед.
Это вовсе не оверхед, и никак оно на производительность приложения в худшую сторону не влияет. Другое дело, что приложение у вас становится четко декомпозированным, разбитым на модули. Плюс вы сможете покрывать свой код тестами, что придаст большую стабильность коду. Еще вы сможете легко разбивать какую либо задачу между разработчиками — один на ui, один на бизнес-логику, другой на data-уровень.
Вообще преимуществ у чистой архитектуры много. Другое дело — чтобы понять их и прочувствовать, нужно садиться, пробовать и писать. Иначе ну никак. Количество абстракций и уровней всегда будет пугать. Но разобравшись, понимаешь, что все это необходимо и нужно.
Total votes 3: ↑3 and ↓0+3
никак оно на производительность приложения в худшую сторону не влияет

Вы замеряли? :) Как бы чем больше объектов мы создаем, тем больше работы у GC. Как минимум.


Еще вы сможете легко разбивать какую либо задачу между разработчиками — один на ui, один на бизнес-логику, другой на data-уровень

Ну, во-первых, 3 разработчика на одно android-приложение — это многовато. Во-вторых, на обычном каком-нибудь rest-клиентике "бизнес-логики" — минимум (поэтому xamarin не слишком популярен — количество общего кода не во всяких там корпоративных приложениях невелико, а интерфейс для каждой платформы надо свой делать), поэтому лишний слой нужен очень редко.


Понятное дело, архитектура нужна, но не в таком виде. Мне понравились несколько примеров. Из них хотелось бы выделить недавно появившийся гугловый, в котором ветка clean есть, но она выглядит самой перегруженной.


Архитектуру вполне можно организовать и на основе компонентов android: contentprovider-ов/observer-ов, service-ов, но это, вилите ли, не модно :)

Total votes 2: ↑1 and ↓10

Или вот philm. Даже несмотря на то, что давно не обновлялся, этот репозиторий содержит очень стройный код.

Total votes 1: ↑1 and ↓0+1
1. Спасибо за ссылки, посмотрю внимательно)
2. Нет, не замерял. Но у GC больше работы, это да. Вопрос только в том, на сколько критично и велико это увеличение. Мне кажется, вообще не критично. Но опять таки, лучше измерить.
3. 3 разработчика на одно приложение — это нормально. Как и пять) Приложения то разные бывают. Вообще очень разные. И какой бы не был rest-клиент, все начинает меняться, когда вам необходимо эти данные кешировать, синхронизировать. Мне в этом отношении очень нравится подход, как был в конкурсе Telegram — https://vk.com/durovschallenge?w=wall-55882680_69. Суть в том, что есть некая нативная библиотечка с API. И эта библиотеска полностью берет на себя вопросы кеширования, синхронизации. Единое такое решение для всех платформ для data-уровня.
4. То, что можно все организовать на contentprovider-ов/observer-ов, service-ов, никто не спорит) Но я вот, честно говоря, не знаю, на сколько это будет поддаваться тестированию. С Clean architecture вы каждый слой спокойно можете покрыть юнит тестами (кроме ui) без дополнительных тулзов, так как там нет android компонент.
Total votes 3: ↑3 and ↓0+3
Вы мобилки-то видели вообще текущие? Каждая из них помощнее моего нетбука 4-летней давности. А чистая архитектура для развесистого приложения поможет сохранить код понятным и доступным для поддержки.
Total votes 1: ↑1 and ↓0+1
Читал на Хабре как минимум ещё 2 статьи по Rx, но так и не понял, что это и зачем может мне понадобиться. Гугление тоже ничем не увенчалось. Не посоветуете годное, понятное описание?
Total votes 1: ↑1 and ↓0+1
https://github.com/kaushikgopal/RxJava-Android-Samples
Посмотрите эти примеры. Дают вполне нормальное представление, как Rx может помочь)
Total votes 2: ↑1 and ↓10
На самом деле очень сложно поначалу вникнуть и понять, зачем все это нужно. Мне кажется, что некоторые люди просто ее используют, потому что это «модно», а не потому, что дает им какие-то выгоды.

Если говорить про понимание, то, возможно, саам стоит начать с лекций и видео каких-нибудь. Из довольно много и про Android и про iOS, про веб фронтенд и даже про бекенды. Там частенько бывают вещи, которые раскрывают всю суть реактивного подхода
Total votes 1: ↑1 and ↓0+1
Если кратко, то Rx — это Iterable, вывернутый наизнанку: вместо того, чтобы самому просить данные в цикле и что-то с ними делать, вы предоставляете «обработчики», которые Rx вызывает, когда приходят данные. Только вместо лапши из callback и состояний получаются потоки данных, в которых ваши «обработчики» на каждом шаге преобразуют данные, а Rx их протаскивает далее по цепочке. Этакая смесь асинхронности с функциональщиной.

Посмотрите выступление Эрика Мейера — может, станет понятнее:
https://www.youtube.com/watch?v=sTSQlYX5DU0
Total votes 3: ↑3 and ↓0+3
В мире джаваскрипт их описывают как смесь Promises + Events завернутую в объекты первого рода
This comment wasn’t rated yet0

Занятно, кстати: очередная статья, в которой "реактивщина" незаметно приравнивается к Rx (окей, здесь еще Akka Streams припомнили, но это тоже поток событий). Хотя Кун — один из авторов цитируемого Reactive Manifesto, — скажем, считает акторы не менее жизнеспособной моделью.

Total votes 2: ↑2 and ↓0+2
Ну ладно, что уж вы) Я не приравнивал Rx к самому подходу. Конечно, это лишь одна из многих реализаций, тут я полностью с вами согласен.
Другое дело, что для Android все таки сильно чаще используется именно RxJava или RxKotlin или еще что из Rx.

Кстати, акторы и streams идут на самом деле достаточно параллельно, как мне кажется. Никто же не запрещает их вместе использовать их в одном проекте и они хорошо могут вместе работать.

Но соглашусь, что чаще говорят именно про RxJava и меньше про другие фреймворки и подходы.
Total votes 2: ↑2 and ↓0+2
Я не приравнивал Rx к самому подходу.

Ага. Статья с заголовком "The Art of Rx" и тизером "Что такое правильное реактивное программирование на Android?"


Никто же не запрещает их вместе использовать их в одном проекте

Да понятно, что никто не запрещает, но вот только многие люди уже уверенно считают, что Rx и реактивное программирование — это одно и то же. Хотя как Rx позволяет, например, достичь resiliency — это открытый вопрос.

Total votes 1: ↑1 and ↓0+1
с трудом заставил себя прочитать статью по теме которой интересуюсь, а виной всему
гайдлайны
импакт
сабжекты
мутабельность
импрувмент

Total votes 3: ↑2 and ↓1+1
Я с трудом читаю какие-то статьи, где вместо «Активити» или «Activity» написано «Активность» а вместо сабджекта «объект» или «субъект».

Без мутабельности и импрувментов можно было и обойтись в тексте, да. Но это транскрипт с записи речи, а с языка мне и не хочется их убирать, поэтому так и вышло.
Total votes 2: ↑1 and ↓10
Есть разница между упоминанием в тексте Activity и импрувментом. Первое — совершенно нормально и не удивит никого знакомого с предметом статьи, насчет второго наши мнения скорее всего могут разойтись. А subject — всегда «субъект», по крайней мере должен быть, но не прямой противоположностью самому себе, то есть никак не «объектом»
Total votes 2: ↑2 and ↓0+2
Sign up to leave a comment.

Your account

Sections

Information

Services

Support
© 2006–2024, Habr