RxJava. Борьба с вызовами суровой действительности

Да, действительно, у RetroFit есть такое возвращаемое значение, как Call.
RetroFit ругнется, если вы вместо concatMap подставите flatMap, но это несколько другая история.
Но можно к примеру добавить параллельные вызовы в БД для записи или чтения, и уже добавляется настоящая асинхронность, и цикл синхронных вызовов уже не сработает так, как хотелось бы.

RxJava. Борьба с вызовами суровой действительности

Добрый день! Спасибо за замечания.
Про reduce согласен. Он лучше подходит.
Про scan, я точно не помню уже, при каких конкретно условиях он падал (или выдавал исключение). По-моему, при условии, если в вышестоящем observable, только один «выпущенный» элемент. Нужно вспомнить будет)
Про «потратил силы» я скорее имел в виду, как это реализовать в Rx, потому что подобного не нашел.
Замечание про то, что можно использовать мой первый пример и отталкиваться от него, так как все необходимо будет выполнять только в одном фоновом потоке, отчасти согласен. В принципе можно. Но тут встает вопрос, что по циклу вы вот так запросы не сможете посылать. RetroFit ругнется и выкинет нас. Если использовать свой кастомный клиент, то все зависит от реализации очереди. И без пробрасывания колбэков не обойтись. А вот если использовать библиотеку Volley, которая возвращает RequestFuture, уже можно будет поиграться.
Но не стоит забывать про то, что код то в Rx выглядит проще. Уж Вы то со мной согласитесь) Плюс мы довольно легко сможем подключить, если необходимо, еще дополнительные операции и не переживать, что что-то отвалиться. Ну и обработка ошибок. В Rx она тоже удобнее, нежели в асинхронном коде.

Реактивное программирование под Android

Было бы классно, если бы Вы добавили в статью решение еще одного примера.
Есть у нас метод запроса в сеть с параметрами offset, limit. Назовем метод request(int offset, int limit). Нам нужно получить весь массив данных. То есть скорее всего придется вызвать несколько раз request с разными параметрами offset и limit, и полученные массивы соединить в один.
Один облегчающий фактор в том, что метод request возвращает Observable (то есть работаем через RetroFit).
Собственно как должна выглядеть вся портянка итогового Observable, чтобы при подписке к нему, мы сразу получали весь массив данных?
Честно говоря, сколько гуглил, так и не смог найти понятного примера. Может вы с этим уже сталкивались?)

Реактивное программирование под Android

Теоретически CachedThreadPool тоже может положить приложение, если, к примеру, одновременно в пул на выполнение отправляются штук 20 немаленьких задач, таким образом создается штук 20 потоков.
В AsyncTask, например, создается ThreadPoolExecutor c параметрами CORE_POOL_SIZE = CPU_COUNT + 1 и MAXIMUM_POOL_SIZE = CPU_COUNT * 2 + 1, где CPU_COUNT — количество процессоров на устройстве. Таким образом, если на устройстве 2 процессора, то количество потоков не будет превышать 5. По идее данный вариант самый безопасный. Но и с вашим вероятность падения очень маленькая.
А так, спасибо за статью, весьма полезная)

Best practices от Google по разработке Android приложений

Ааа, точно) согласен, это не относится к категории «Новое».
Спасибо за замечание)

Best practices от Google по разработке Android приложений

Так никто и не спорит) Но очень распространены случаи, когда пути к директориям прописывают вручную.

Best practices от Google по разработке Android приложений

Это было бы слишком жестко)
Приведу пример того, что имел в виду
При создании файла мы можем использовать такой код:

myFile = new File("/sdcard/" + txtName.getText() + ".txt");

где путь к директории, в которой должен храниться файл, задается вручную.
А нужно использовать такой код:

myFile = new File(Environment.getExternalStorageDirectory().getAbsolutePath() + "/"+ txtName.getText() + ".txt");

где путь к директории задается через специально предназначенный для этого метод Environment.getExternalStorageDirectory().getAbsolutePath()

Best practices от Google по разработке Android приложений

Точно! Я почему-то перепутал Vector с массивом, хотя вроде во время просмотра математику вроде не читал…
Спасибо Вам большое! Подправлю!

Best practices от Google по разработке Android приложений

Немножко не ясно ответил я. В обычных ситуациях вьюшкам hardware acceleration не нужен. Только если появляется у этого элемента анимация, прозрачность (кстати прозрачность — это большое зло для производительности UI, как говорит Гугл), включается для них hardware acceleration. Анимация закончилась — hardware acceleration отключается, чтобы разгрузить GPU.
Но еще раз говорю, я тут могу ошибаться, так как тему еще не полностью изучил.

Best practices от Google по разработке Android приложений

У Гугла написано, что hardware accelaration для всех стандартных view включен по-умолчанию. Собственно ничего дополнительно выставлять не нужно)
Если же Вы делаете какую-нибудь кастомную view, или Вам нужно применить к элементу анимацию, то как раз применяете данный код:

View.setLayerType(View.LAYER_TYPE_HARDWARE, null);
ObjectAnimator animator = ObjectAnimator.ofFloat(view, "rotationY", 180);
animator.addListener(new AnimatorListenerAdapter() {
    @Override
    public void onAnimationEnd(Animator animation) {
        view.setLayerType(View.LAYER_TYPE_NONE, null);
    }
});
animator.start();

Но в чем соль, как я понял. Посмотрим на вышеприведенный пример. Вы выставляете hardware accelaration перед анимацией:

View.setLayerType(View.LAYER_TYPE_HARDWARE, null)

, а после анимации снимаете данный флаг:

 View.setLayerType(View.LAYER_TYPE_NONE, null) 

.
То есть перед началом анимации Вы для данной view подключаете использование GPU, оптимизирующее прорисовку элемента. После завершения GPU для данной view не нужен, поэтому мы снимаем флаг hardware acceleration.
Соственно и поэтому View.isHardwareAccelerated() всегда возвращает false. Во время выполнения анимации по идее должен тогда возвращать true.
Я могу ошибаться, поэтому поправьте меня. Если честно, данная тема не очень хорошо и подробно раскрыта Гуглом. Скорее всего полный анализ hardware accelaration и создания качественный кастомных view рассмотрен в данном видео 2013 года еще — www.youtube.com/watch?v=NYtB6mlu7vA
Но у меня еще не дошли руки с этим видео и вообще вопросом качественно разобраться :)

Best practices от Google по разработке Android приложений

Вы знаете, я с Вами полностью согласен. Для нас, для кого английский не родной, текстовая информация воспринимается гораздо быстрее и лучше. А главное, всегда можно вернуться и посмотреть еще раз.
Но, увы, Google выкладывает свои Best practices в виде видео. И мне пришлось потратить гораздо больше, чем полня, на просмотр, учитывая, что у некоторых спикеров тяжкое произношение)
Поэтому собственно и появилась идея сделать набор кратких тезисов. И если читатель заинтересуется и захочет более глубоко понять тему, он сможет сам просмотреть указанные ссылки)