Это просто стандартный код для реализации адаптера пейджера? - PullRequest
0 голосов
/ 31 октября 2018

Чтобы реализация PagerAdapter работала правильно, в производном классе настраиваемого адаптера должно быть реализовано следующее.

 @Override
 public boolean isViewFromObject(@NonNull View view, @NonNull Object object) {  
        return view == object;  
 }  

 @Override
 public void destroyItem(@NonNull ViewGroup container, int position, @NonNull Object object) {  
        container.removeView((View) object);  
    }  
}  

Мне кажется, это всего лишь стандартный код.
Почему это должно быть сделано в производном классе? Есть ли причина, по которой этот код не является частью PagerAdapter, а производный класс заменяет его чем-то другим, только когда (если) необходимо? Когда это будет?

1 Ответ

0 голосов
/ 01 ноября 2018

Я думаю, это потому, что объект не гарантированно будет представлением. В документации даже сказано так:

instantiateItem

Возвращает объект, представляющий новую страницу. Это не обязательно должен быть View, но может быть какой-то другой контейнер страницы.

Если аргумент object не a View, то destroyItem() завершится ошибкой и приведет к сбою приложения.

isViewFromObject() не будет аварийно завершать работу, но он всегда будет возвращать значение false, что может стать причиной нескольких часов головной боли при попытке отследить ошибку.

Даже если это View, и вы используете PagerAdapter в его самой базовой форме, я думаю, что методы были сделаны абстрактными, чтобы 1 вы знали о них, 2 вы использовали их для реализации и знали, что делать, если вы не используете View в качестве своего объекта.

В вашем представлении могут быть объекты, которые необходимо уничтожить, такие как BroadcastReceivers, обратные вызовы и т. Д. Хотя для уничтожения этих данных не требуется , это хорошая практика.

...