Convert Android View # post (Runnable) to RxJava

-1

Использует немного RxJava и может видеть его преимущества. Одно из них заключается в том, что анонимные внутренние классы получают сбор мусора, когда подписка отменяется в onStop().Convert Android View # post (Runnable) to RxJava

Я новичок в RxJava, так что извините, если это не так.

Может быть что-то вроде:

pager.post(new Runnable() { 
    public void run() { 
     final int currentItem = pager.getCurrentItem(); 
     pager.setAdapter(new MyAdapter(getSupportFragmentManager())); 
     pager.setCurrentItem(currentItem); 
    } 
});

становится:

Observable.just(pager) 
    .observeOn(AndroidSchedulers.mainThread()) 
    .subscribeOn(AndroidSchedulers.mainThread()) 
    .subscribe(pager -> { 
     final int currentItem = pager.getCurrentItem(); 
     pager.setAdapter(new MyAdapter(getSupportFragmentManager())); 
     pager.setCurrentItem(currentItem); 
    });

Причина Я спрашиваю, что я сталкивался с проблемой при повороте и обновлении ViewPager и оказалось, анонимный внутренний Runnable перешел на post(Runnable). Сэкономит время, чтобы создать статический внутренний класс с заданием WeakReference.

источник

2017-01-12 Tim Kist

Какая проблема именно в том, где вы столкнулись в первую очередь? Reactive приносит довольно много сложностей с его преимуществами, поэтому было бы разумно думать, действительно ли вам это нужно в первую очередь. –

Я делал обновление ViewPager, но может случиться так, что обновление произойдет, когда действие будет уничтожено и произойдет сбой, например https://code.google.com/p/android/issues/detail?id=218912. –

когда вы делаете этот управляемый пост?

Короче:

RxJava не особенно полезно в этом сценарии, и это может быть сделано с обработчиком.

Подробнее:

Оба сегмента кода будут делать почти то же самое, они в конечном итоге оставить исполняемую/действие на основной обработчик потока (который будет обрабатываться в порядке с другими действиями в очереди в основной поток).

Если вы делаете это из другой темы, может быть «гонка» с активностью закончить/уничтожить в основной теме, то есть действие, которое сделает недоступным viewpager больше, будет вызвано перед вашими действиями, которые требуют «жить» 'viewPager, и это может сделать исключение crash/null.

Это правда, что если вы отмените подписку на наблюдаемый в главном потоке с операцией finish/destroy (любое событие жизненного цикла, в результате чего viewPager не будет «жить»), действие не будет вызываться, а сбой будет предотвращен ,

Это можно сделать аналогичным образом с помощью Handler.removeCallbacks и вместо использования View.post (который внутренне использует обработчик) с использованием Handler.post().

источник

2017-01-12 16:12:23 yosriz

Convert Android View # post (Runnable) to RxJava

ответ

Смежные вопросы