Николай Unknown

PagedListAdapter, серьёзно? Гугол в очередной раз родил какую-то хренотень. Похоже, создатели RecyclerView не рассказали автору этой либы, что адаптер никакого отношения к получению данных(коим, конечно, является пагинация) не имеет.

Короче, как надо. Данные должны прилетать в адаптер списком и он их должен отображать. Где-то во вью слое должна быть подписка на события скроллов ресайклера и определение, доскроллился ли он до конца. Когда доскроллился, нужно оповещать об этом презентационный слой, который попросит у модели ещё данных. Модель вытянет данные, отдаст презентации, данные сконвертятся и отдадутся во вью слой, который передаст их снова в адаптер, который их покажет.

Конец.

Никакая либа, которая трогает адаптер и вообще навешивает кучу сущностей, не нужна.

P.S. статья использует Rx в качестве фреймворка коллбеков. Божественно.

Можно переопределить метод intercept() и в нем добавлять header с токеном:

OkHttpClient.Builder builder = new OkHttpClient.Builder();
        builder.addInterceptor(new Interceptor() {
            @Override
            public Response intercept(@NonNull Chain chain) throws IOException {
                Request original = chain.request();
                String token = ""; // Get token from prefs
                if (!TextUtils.isEmpty(token)) {
                    Request.Builder requestBuilder = original.newBuilder()
                            .addHeader("Token", token);
                    Request request = requestBuilder.build();
                    return chain.proceed(request);
                } else {
                    return chain.proceed(original);
                }
            }
        });

1. VDS с линуксом, ставим туда java
2. jar
3. java -jar filename.jar

внутренние объекты сервера и клиента вообще никак не связаны, даже если полностью совпадают по полям
на клиента уходят специальные DTO объекты (data transfer), и это не то же самое что сущности из моделей клиента или сервера

Вопрос сформулирован так как будто вы еще и не знаете зачем он вам вообще понадобился) В двух словах токен это некая последовательность достаточно уникальная, чтобы ее было трудно угадать. На сервисе должна быть функция аля Авторизация(логин пароль) или что у вас в нем используется, эта функция должна проверить корректность пользователя и если он корректный сгенерить ему некий Токен, для этого можно например использовать объект GUID или просто MD5 от некой достаточно уникальной строки. Этот токен возвращается при авторизации и сохраняется где то в БД, далее при обращении к сервису вместо пары логин\пароль отправляется этот токен и идет проверка уже не по логину или паролю а по наличию токена в БД. Соответственно если на каком то токене идет подозрительная активность его можно удалить из БД тем самым "заблокировав" токен, но не пользователя.