Я понимаю, что приложение тестовое, но вы же все-таки статью пишите, на которую кто-то будет равняться.
Насчет оберток, я про разницу между boolean и Boolean, int и Integer и тд.
Создание Activity вручную. Да еще и чтобы просто вызвать паблик метод. Вы хоть представляете на сколько тяжелый это компонент и на сколько бессмысленно это делать? Не говоря уже о том, что это ужасно с точки зрения архитектуры и вообще создавать Activity — ответственность ОС?
Хардкод ключей в префах. Необходимость помнить везде что под каким ключом записал, это абсолютно не поддерживаемый код и источник кучи багов.
Код стайл, форматирование, название переменных, классов.
Использование оберток над примитивами там, где можно обойтись примитивами. (Подозреваю, что даже автор даже не задумывался над разницей)
Сам подход к задаче. Как уже написали, это может высадить батарею, да и вообще решение не выглядит элегантно. Повторять предложенные варианты не буду.
Да много преимуществ. Как минимум Api поприятнее, чем у того же Loader'a, хоть это и не замена ему.
Меньше кода (не во вред читаемости), простая и удобная обработка ошибок.
Удобная работа с сетью, базой, отсутствие тонны вложенных коллбеков.
Возможность красиво распределять операции по различным потокам с разными приоритетами.
Комбинирование операций над данными (как одновременно, так и последовательно). Это, в принципе, основная фишка. Бывают случаи, что просто не представляю как соорудить что-то адекватное без Rx, чтоб без кучи каких-то тредов, атомиков, мютексов и кэшей.
На каком планировщике обработать результат, пусть решает сам подписчик.
Кроме того, у вас все операторы под queryURLs(...) выполняются на планировщике с Looper'ом, то есть каждый из них постит результат в очередь событий. Хотя можно было бы это сделать только для метода subscribe.
Как уже написали выше, у вас проблемы с методами getURLs и getTitles. Следовало бы поймать exception внутри Observable и вернуть его подписчику в onError, чтобы он решил, что с ним делать.
— Observable queryURLs(String url) — строка объявляет метод, который порождает строку ссылки на сайт для парсинга и возвращающего список ссылок.
Если уж решили зачем-то вдаваться в такие мелочи, выражайтесь корректно.
— new Observable.OnSubscribe() — интерфейс OnSubscribe создает подписчика
Интерфейс OnSubscribe ничего не создает, это просто интерфейс с 1 методом, который вызовется при подписке.
— subscribeOn(Schedulers.io()) — метод subscribeOn запускает наш код в дополнительном потоке;
Не совсем так. Этот метод подписывает всех Observable выше по цепочке на определенный планировщик. Повторный вызов метода ниже по цепочке (с другим планировщиком) не даст никакого результата, например.
Названия методов Example0...1 и т.д. с заглавной буквы.
Я бы не рекомендовал новичкам учиться по этой статье, даже если забыть, что есть Retrofit, и рассматривать это как просто как базовый пример.
Масса недочетов, плохой код-стайл и беспорядок в терминах и понятиях.
проект перестал собираться ссылаясь на ошибки во всех ресурсах
Это из-за того, что невозможно было сгенерировать класс R.
А lint должен был говорить, что проблема в имени png, вы скорее всего просто не те логи смотрели.
Самое основное отличие в том, что в 500px нужно самому решать когда перерисовывать блюр. Дело даже не в том, что это неудобно, а в том, что это в принципе не всегда возможно.
Еще я попробовал на своем демо-проекте заюзать их либу и вижу, что их BlurringView почему-то не нарисовала блюр в правой части таба. Просто пустое место. А если в качестве blurredView ей указать root layout окна, она вообще крашится со StackOverflowError.
В целом, мне кажется, что она менее гибкая и менее удобная. Единственный плюс (имхо), это XML атрибуты для настройки. Надо взять на вооружение.
Собственно, блюр с помощью RenderScript как раз выполняется на GPU, и пока что является самым быстрым вариантом.
Может можно придумать действительно что-то еще быстрее на шейдерах, но я пока не пробовал.
Возьмите, отпишите о производительности. Может взять еще телефон на 1.6 Андроиде? :)
На Galaxy Nexus, который тоже довольно старый и не шибко мощный, все работает быстро.
Претензия странная.
Насчет оберток, я про разницу между boolean и Boolean, int и Integer и тд.
Хардкод ключей в префах. Необходимость помнить везде что под каким ключом записал, это абсолютно не поддерживаемый код и источник кучи багов.
Код стайл, форматирование, название переменных, классов.
Использование оберток над примитивами там, где можно обойтись примитивами. (Подозреваю, что даже автор даже не задумывался над разницей)
Сам подход к задаче. Как уже написали, это может высадить батарею, да и вообще решение не выглядит элегантно. Повторять предложенные варианты не буду.
Меньше кода (не во вред читаемости), простая и удобная обработка ошибок.
Удобная работа с сетью, базой, отсутствие тонны вложенных коллбеков.
Возможность красиво распределять операции по различным потокам с разными приоритетами.
Комбинирование операций над данными (как одновременно, так и последовательно). Это, в принципе, основная фишка. Бывают случаи, что просто не представляю как соорудить что-то адекватное без Rx, чтоб без кучи каких-то тредов, атомиков, мютексов и кэшей.
А она пыталась? Или вообще предназначена для этого? Это типа микроскопом гвозди забивать, как бы заезженно это не звучало.
Но observeOn(...) не стоит там вызывать, уже объяснил почему.
На каком планировщике обработать результат, пусть решает сам подписчик.
Кроме того, у вас все операторы под queryURLs(...) выполняются на планировщике с Looper'ом, то есть каждый из них постит результат в очередь событий. Хотя можно было бы это сделать только для метода subscribe.
— Observable queryURLs(String url) — строка объявляет метод, который порождает строку ссылки на сайт для парсинга и возвращающего список ссылок.
Если уж решили зачем-то вдаваться в такие мелочи, выражайтесь корректно.
— new Observable.OnSubscribe() — интерфейс OnSubscribe создает подписчика
Интерфейс OnSubscribe ничего не создает, это просто интерфейс с 1 методом, который вызовется при подписке.
— subscribeOn(Schedulers.io()) — метод subscribeOn запускает наш код в дополнительном потоке;
Не совсем так. Этот метод подписывает всех Observable выше по цепочке на определенный планировщик. Повторный вызов метода ниже по цепочке (с другим планировщиком) не даст никакого результата, например.
Названия методов Example0...1 и т.д. с заглавной буквы.
Статьи в списке источников куда полезнее.
Добавил бы еще это, Rx далеко не заканчивается на сетевых запросах:
Пагинация 1
Пагинация 2
Shake detector
Доклад Артема Зинатулина
И просто десятки статей всяких блоггеров, не знаю почему вдруг «хороших материалов мало»
Масса недочетов, плохой код-стайл и беспорядок в терминах и понятиях.
Это из-за того, что невозможно было сгенерировать класс R.
А lint должен был говорить, что проблема в имени png, вы скорее всего просто не те логи смотрели.
По поводу
У вас включен Instant run? Я у себя его отключаю, т.к. тоже подобные проблемы возникают иногда.
Немного позже попробую сделать workaround.
Еще я попробовал на своем демо-проекте заюзать их либу и вижу, что их BlurringView почему-то не нарисовала блюр в правой части таба. Просто пустое место. А если в качестве blurredView ей указать root layout окна, она вообще крашится со StackOverflowError.
В целом, мне кажется, что она менее гибкая и менее удобная. Единственный плюс (имхо), это XML атрибуты для настройки. Надо взять на вооружение.
А в демо-проект 16 версия, видимо, случайно попала. Спасибо, сменю на 14.
Может можно придумать действительно что-то еще быстрее на шейдерах, но я пока не пробовал.
На Galaxy Nexus, который тоже довольно старый и не шибко мощный, все работает быстро.
Претензия странная.
Может и не истина в последней инстанции, но мысли правильные, как по мне.