Size: a a a

Android Developers

2020 May 23

I

Ivansuper in Android Developers
An On
В общем-то, логичнее тогда дропнуть сразу весь кэш, если есть возможность получать данные из сети, независимо от их соответствия с локальной копией. И кэшировать по мере прогрузки (скроллинга списка). Потому что несколько "одинаковых" по содержимому страниц от бэкенде и в локальной копии всё ещё не гарантируют, что и дальше они идентичны, а туда пользователь может в итоге и недоскроллить.
Я так и сказал что дропать его полностью если не сошлось : )
источник

AO

An On in Android Developers
Quantum Harmonizer
как это на сервере реализовать?
Завести табличку с историей изменения данных
источник

AO

An On in Android Developers
Ivansuper
Я так и сказал что дропать его полностью если не сошлось : )
Я в том сообщении говорю, о том что надо дропать в любом случае, даже если сошлись
источник

I

Ivansuper in Android Developers
Понимаешь, у тебя есть локальный кеш, он валидный сам в себе. Пока точечные ответы сервера с ним совпадают, он остается валидным. Если один ответ где то не совпал, значит надо точно весь обновить. Как то так. Но тебе тогда надо делать дифф утилиту
источник

AO

An On in Android Developers
Не понимаю, почему он валидный сам по себе)
источник

AA

Ali Agzamov in Android Developers
Ivansuper
Я так и сказал что дропать его полностью если не сошлось : )
а не проще просто запрашивать данные порционно, чем  гонять трафик в пустую ?
источник

I

Ivansuper in Android Developers
Ali Agzamov
а не проще просто запрашивать данные порционно, чем  гонять трафик в пустую ?
Там и так постраничный запрос
источник

AO

An On in Android Developers
An On
Не понимаю, почему он валидный сам по себе)
В моём понимании, он должен априори считаться невалидным всегда, т.к. валидность его может быть доказана только получением абсолютно всех данных от бэкенда
источник

I

Ivansuper in Android Developers
An On
Не понимаю, почему он валидный сам по себе)
Попробуй расчертить на листке бумаги состояния кеша, запросы на сервер и его изменение, и проследи визуально что как
источник

I

Ivansuper in Android Developers
An On
В моём понимании, он должен априори считаться невалидным всегда, т.к. валидность его может быть доказана только получением абсолютно всех данных от бэкенда
Не верно. Это параноидальная точка зрения
источник

AO

An On in Android Developers
Ali Agzamov
а не проще просто запрашивать данные порционно, чем  гонять трафик в пустую ?
Порционность и вносит главную проблему. Т.к. данные мы можем сравнивать только кусочками
источник

I

Ivansuper in Android Developers
An On
Порционность и вносит главную проблему. Т.к. данные мы можем сравнивать только кусочками
Ты эти данные потом как то используешь для других запросов на сервер?
источник

I

Ivansuper in Android Developers
Если они используются в обе стороны, то тогда да, проблема актуальности есть
источник

AA

Ali Agzamov in Android Developers
An On
Порционность и вносит главную проблему. Т.к. данные мы можем сравнивать только кусочками
а тебе нужны все 100% для обработки?
источник

AO

An On in Android Developers
Ivansuper
Ты эти данные потом как то используешь для других запросов на сервер?
В общем случае нет, грубо говоря это "история действий". Кое-что может использоваться, но бэкенд вернёт ошибку и хуже никому не станет.

Но меня больше интересовало как вообще принято в таких ситуациях поступать) Задача выглядит весьма типичной)
источник

AA

Ali Agzamov in Android Developers
An On
В моём понимании, он должен априори считаться невалидным всегда, т.к. валидность его может быть доказана только получением абсолютно всех данных от бэкенда
ты пытаешся взять на себя отвественость за то что не контролируеш
источник

I

Ivansuper in Android Developers
Ну тебе вариантов накидали) Подумай как лучше будет
источник

AO

An On in Android Developers
Окей, спасибо) Я тут ещё докладик с мобиуса нагуглил на эту тему, пойду тоже посмотрю.
источник

I

Ivansuper in Android Developers
Тут надо обычно сидеть и говорить с заказчиком/бэкэндером
источник

Н

Николай in Android Developers
Ребят. Оцените данный списочек моих "скилов".
Хотел узнать чего мне ещё нужно доучить для того что бы
стать полноценным junior adnroid developer ?
Уже два года как знаком с разработкой под андроид.
Себя спецом далеко не считаю. Скорее придурком,
который временами гуглит даже то, что уже использовал.
Хочется уже увидеть горизонт необходимых скилов,
с которыми я смогу подать резюме в норм компанию,
а не шарагу.

1. Активности. Фрагменты. Их жизненный цикл и взаимодействие. Работа с Intent, PendingIntent, виды Intent.ACTION.
2. Базовые элементы View. Так же могу работать и с другими елементами и библиотеками(при наличии документации).
3. MVVM. MutableLiveData.
4. Service
5. Broadcast Receiver
6. Recycler View. Paging Library.
7. JSON, XML.
8. Room. SQL. Немного знаю проектирование и нормализацию БД.
9. Picasso (умею пользоваться).
10. Retrofit. OkHTTP.
11. Notification.
12. В основном в разметке работаю с linearLayout, constraintLayout, drawerLayout, frameLayout.
13. Умею применять FrescoImageViewer.
14. Умею делать SnackBar, Toast, Toolbar, выдвижную шторку в NavigationDrawer.
15. При необходимости могу написать кастомный type конвертер для GSON.
16. Могу работать с камерой, сканировать QR/Bar коды в оффлайн режиме.



Код пишу на Java. Перейду на Kotlin только при необходимости. Он меня уж очень отпугивает своим синтаксисом.

Знаком со стеком JAVA EE, также проходил в университете курс обучения C/С++ в котором была работа с WIN API и
многопоточностью.
Умею использовать:
1. Servlet, Filter, знаю как они работают, какие есть скоупы.
2. Знаю какие есть MIME типы. Умею работать с некоторыми.
2. JSP, JSF, HTML и чуток CSS.
3. JDBC.
4. JWT.
5. Session, Cookies
6. Умею работать с HTTP, WebScoket на стороне как клиента так и сервера.

О Spring, Hibernate я мало что знаю так как сделал выбор для старта карьеры в пользу ведроида и остановил изучение Enterprise.

Так же за спиной 2 части курса Cisco CCNA. Но они особо отношения к Android не имеют.
источник