Был и второй вид комментаторов, считающий, что моя статья, должна быть панацеей. Но так как я явно об этом не написал в предыдущей статье, напишу в этой — это всего лишь пример, вы можете написать свою реализацию как хотите, я всего лишь скромно пишу о идее, а будет ли реализация лучше моей или хуже — это не важно, вы же не обижаетесь на то что примеры из какой нибудь книги по программированию нельзя скопипастить и вставить их в свой проект? Правильно, ведь их задача совсем не в этом. Я уже не говорю о том, что статья была о бесконечных потоках, а не об библиотеке RxJava
Итак, собственно вот ссылка на гит, можете склонировать, собрать apk и проверить сами, cpu в пике чуть больше 3%, сборщик мусора, тоже замечательно делает свою работу, утечек нет, по крайней мере это все на моем устройстве, чтож, проверьте сами, если интересно: git clone Xsinh@bitbucket.org/Defolte/infinitytest.git
Подведем итоги: надеюсь, сейчас я предельно ясно выразил свою мысль, код — всего лишь пример, статья — это повод осмыслить концепцию бесконечных потоков данных, в моем проекте была необходимость поступать похожим образом, а не через фоновые потоки или сервисы, в вашем, наверняка этой необходимости не будет, моя цель была зажечь в вас искорку интереса, чтобы вы сами решили что с ней сделать — погасить, если не нужно, или разжечь пламя идей (тут я подразумеваю, что вы дальше сами найдете информацию в интернете, без моей помощи, если вам это действительно интересно и сделаете свою реализацию, какую только захотите)
Комментарии (17)
mayorovp
21.09.2017 06:14+2Теперь о том почему ваше доказательство доказательством не является.
Во-первых, вы не используете все возможности, предоставляемые библиотекой RxJava. Нужно начать с того, что заменить явный вызов
Handler.postнаobserveOn. И накидать еще несколько вызовов стандартных методов, чтобы их протестировать.
Во-вторых, использование 3% CPU для такой фигни — это очень много. У меня на стартовом экране системный виджет с 8 подобными индикаторами. Если бы его разработчики следовали вашим советам — он бы потреблял 24% CPU, то есть четверть процессорного времени сжиралась бы на никому не нужные перерисовки!
Теперь по поводу утечек. С чего бы им быть когда в проекте всего один Activity? Утечки могут возникнуть при навигации между разными Activity. Если бы в программе было хотя бы два разных экрана, между которыми можно было ходить туда-сюда — то ее можно было бы использовать для доказательства отсутствия утечек. Но сейчас потенциальные утечки ресурсов при таком подходе не проверяются.
DocentTSR
21.09.2017 14:15По поводу утечек, чтобы утекла Activity, не обязательно чтоб в проекте было их несколько и между ними происходила навигация. Если вы написали, код который удерживает ссылку на Activity (или View), то при пересоздании Activity, у вас появится новая Activity, но старая не соберется GC. И при каждом пересоздании Activity количество НЕ собранных будет расти.
mayorovp
21.09.2017 14:17Да, но если просто запустить программу и смотреть на нее — то Activity просто так пересоздаваться не будет. Чтобы проверить программу на утечки — нужен способ «пнуть» пересоздание Activity.
anegin
21.09.2017 09:10+1Смотрите, я прикрутил квадратные колеса к велосипеду. Стало так удобно спускать его по лестнице, я проверил только у себя в подъезде, но думаю будет удобно везде. Вот вам чертеж и концепция — уверен, каждый сможет придумать, что с этим всем делать.
Implozia Автор
21.09.2017 09:25-5Все верно, кроме того, что я сказал, что данный пример будет удобен везде. А что ты предлагаешь, придумать кучу идеальных кейсов на все случаи жизни? Может еще и зарплату за вас получить?
gildor
21.09.2017 09:48+1Концепция прерывания потока или спин для ожидания не является чем то новым и используется повсеместно.
Вас справедливо критикуют, что ваши примеры предлагают плохие не оптимальные решения конкретных проблем (вроде проверки состояния сети), а так же того, что вы использовав RxJava очень странным способом, и уж если использовали можно попытаться сделать намного более нативное решение через кастомный оператор или комбинацию существующих.
И критикуют прежде всего не по причине наличия нерабочего кода, а так как есть опасение, что новички, не разобравшить применят ваш код.Implozia Автор
21.09.2017 09:51-2Если так, то справедливо, но я исходя из других комментариев — пришел к другому выводу)
Implozia Автор
21.09.2017 11:38-1Ребят, я тут погосил пожарище, перечитал свою статью, понял что все-таки за мной есть косяки, раз не один человек указывает мне на ошибки, значит на это стоит обратить внимание. Хочу извиниться, учту ваши мнения, когда будет о чем написать в следующий раз.
Implozia Автор
21.09.2017 18:53-5Хотя это и не отменяет тот факт, что мне испортили карму обиженные codemonkeys(
virtustilus
22.09.2017 15:20Правила habrahabr никто не отменял, и работают они на каждом Вашем комментарии (даже если уж очень хочется выплеснуть все эмоции в этот момент).
Implozia Автор
22.09.2017 15:27-1Я писал не ради кармы, но признаться не ожидал своей реакции, дело не в том, что я не прав, я еще сам не понял так ли это, но на мой взгляд — по делу было очень мало комментариев, никто не захотел проверить примеры, а кто-то просто скопипастил код, наверняка не добавив зависимости к проекту, и поэтому он не запустился, и начали писать — не рабочий код, create() мол бред, надо observeOn() и прочую ерунду, причем не зная для чего каждый из методов нужен, и когда его надо применять, в какой ситуации.
virtustilus
22.09.2017 15:29+1Я вот не понимаю, почему Вы до сих пор не отредактировали код в своем посте?
Там же Ваш текст не соответствует коду.
У вас вот эта часть кода:
while (!subscriber.isUnsubscribed())
while (true) subscriber.onNext(i);
i = i.add(ONE);
А теперь подробнее — что же происходит в первом и втором случае? В первом случае, рекурсия блокирует поток, по скольку вычисления никогда не кончится, и вы сами, наверняка, догадываетесь к чему это приведет. Поэтому, создадим явную конкурентность. Во втором примере мы создаем отдельный поток и будем делать события в нем.
Во втором случае у Вас такой же бесконечный поток. То есть люди читают этот код и думают «а зачем он добавил while (!subscriber.isUnsubscribed()), если код while (true) subscriber.onNext(i); все равно бесконечен и проверка не будет срабатывать более одного раза в момент старта?»
Вот и минусуют, т.к. код не подходит по качество постов на этом ресурсе. Разберитесь с чем-то сложным, напишите правильный код сюда, сделайте описание короткое или длинное и пост наберет плюсы в карму.Implozia Автор
22.09.2017 15:43Я вас услышал, перепроверю это еще раз, как только появится время, но ответ на этот вопрос я только что написал в другом посте, в комментариях
mayorovp
Ваш код в репозитории:
```java
while (!subscriber.isUnsubscribed())
subscriber.onNext(hasConnection(context));
```
Ваш код в прошлом посте («пример с отпиской или как нужно делать»):
```java
while (!subscriber.isUnsubscribed())
while (true) subscriber.onNext(i);
```
Вы правда не видите разницы?
mayorovp
PS извиняюсь за разметку
Implozia Автор
ты вообще о чем, может ты пересмотришь предыдущую статью полностью? Там пример, а не реальный код
mayorovp
Так что, если это лишь пример — то можно в нем и ошибки не исправлять уже?