需求：有一個列表，列表中有一個edittext（只能輸整形），外部有一個整形變量Int，每次改變列表中其中一項的edittext的值時，外部的Int都會改變。

既然這樣，我們就需要對edittext進(jìn)行addTextChangedListener監(jiān)聽，一般做法是在afterTextChanged中對外部進(jìn)行循環(huán)累加，但是想想，每一次你改變edittext都要進(jìn)行一次時間復(fù)雜度為n的循環(huán)的話，想想就覺得這個算法很那啥，所以我想了另一個算法，每次改變其中一個item的值時，用總的值減去原item的edittext中的值加上item的edittext新輸入的值，這樣的復(fù)雜度為1，看著就很舒服。

但是這樣也引出了一個問題，就是今天要說的BUG

我要講的BUG是RecyclerView導(dǎo)致數(shù)據(jù)錯亂的問題

我要講的BUG是RecyclerView導(dǎo)致數(shù)據(jù)錯亂的問題

我要講的BUG是RecyclerView導(dǎo)致數(shù)據(jù)錯亂的問題

重要事情說三遍

你想想，對于addTextChangedListener這個方法，你每次對edittext進(jìn)行setText操作后都會調(diào)用這個方法，不巧的是recyclerview是復(fù)用容器，數(shù)據(jù)超出可用的容器時，會對edittext進(jìn)行復(fù)用，也就是說，我們本身只想在addTextChangedListener中去監(jiān)聽手動改變edittext的情況，而recyclerview重復(fù)調(diào)用setText也會導(dǎo)致默認(rèn)調(diào)用addTextChangedListener而會產(chǎn)生嚴(yán)重的數(shù)據(jù)錯亂。

舉個栗子，對我的需求原本是做這樣的操作。

edtItem.addTextChangedListener(new TextWatcher() {

        @Override
        public void beforeTextChanged(CharSequence charSequence, int i, int i1, int i2) {
             // todo 獲取到edit改變前的數(shù)字
             String befour = edtItem.getText().toString();
        }

        @Override
        public void onTextChanged(CharSequence charSequence, int i, int i1, int i2) {

        }

        @Override
        public void afterTextChanged(Editable editable) {
             // todo 獲取到edit改后的數(shù)字
             String now = edtItem.getText().toString();
        }
      });

這樣拿到當(dāng)前Item改變前的數(shù)字和改變后的數(shù)字，傳給外部（傳的做法我這沒寫，可以用觀察者），然后外部總int - befour + now 就能獲取到新的總數(shù)。

這邏輯看是完美，但是recyclerview幫你settext時，你的befour就是復(fù)用前的item中的數(shù)，而now就是新settext上去的數(shù)。
簡單來說，我們要的效果是手動修改editText時才進(jìn)行int - befour + now步驟，而現(xiàn)在你光滑動就莫名其妙進(jìn)行int - 復(fù)用前item的數(shù) + 復(fù)用后item的數(shù)。

那我們就需要解決一個問題，只有手動修改edittext時，才進(jìn)行正確的操作，滑動時，不進(jìn)行操作
其實我以前有說過reyclerview不能直接對它的容器進(jìn)行操作（也就是viewholder），而應(yīng)該對它的數(shù)據(jù)進(jìn)行操作。所以這里我們改成這樣的話，就不會受到滑動更新數(shù)據(jù)的影響。

edtItem.addTextChangedListener(new TextWatcher() {
        @Override
        public void beforeTextChanged(CharSequence charSequence, int i, int i1, int i2) {
             // todo 獲取到edit改變前的數(shù)字
             String befour = data;
        }

        @Override
        public void onTextChanged(CharSequence charSequence, int i, int i1, int i2) {

        }

        @Override
        public void afterTextChanged(Editable editable) {
             // todo 獲取到edit改后的數(shù)字
             data = edtItem.getText().toString();
             String now = data ；
        }
      });

data是adapter傳給viewholder的數(shù)據(jù)。這樣寫的話在beforeTextChanged方法中獲取的就不是復(fù)用前item的數(shù)據(jù)，而是當(dāng)前的數(shù)據(jù)。所以你滑動時發(fā)現(xiàn)befour 和now 會是一樣，這時就不用進(jìn)行更改總數(shù)的操作，而手動改變editText時befour 和now 是不一樣的。

總結(jié)

可能你看不懂我的需求和例子，說明你沒碰到過這樣的情況（列表的edittext影響外部某個狀態(tài)），我也不太好解釋，但是你基本會碰到過數(shù)據(jù)錯亂的情況，這就是我要說的。

在RecyclerView中，不管你要做什么操作，不要直接對容器（ViewHolder）操作，而是對數(shù)據(jù)進(jìn)行操作。

補(bǔ)充一點java的常識

如果你傳的是對象的話，這里對形參的改變，實參也會變，但是傳基本數(shù)據(jù)類型的話，你變形參是不會影響實參的，所以不管有多少個數(shù)據(jù)，在viewholder中最后應(yīng)該傳入對象而不是基本數(shù)據(jù)類型.

以上就是本文的全部內(nèi)容，希望對大家的學(xué)習(xí)有所幫助，也希望大家多多支持腳本之家。

最新評論