Щас буду пробовать, спасибо. Адаптер пока стандартный. Запилен ради теста, но потом планирую делать свайп-ту-лоад + лоад-он-скролл

Может, сделать fitsSystemWindows="@boolean/fitsSystemWindows" и написать разны булеаны для разных версий?

таки не работает и совершенно неочевидно почему

таки не работает и совершенно неочевидно почему

Могут быть какие-то другие флаги, с ходу не помню, какие.

базовая тема: <item name="android:fitsSystemWindows">false</item> <item name="android:windowContentOverlay">@null</item> <item name="windowActionBarOverlay">true</item> v19 <item name="android:windowTranslucentStatus">true</item>

не ... наврал ... сорян базовая <item name="windowActionBar">false</item> <item name="windowNoTitle">true</item> <item name="android:windowFullscreen">false</item> v19 <item name="android:windowTranslucentStatus">false</item> v21 <item name="android:statusBarColor">@color/primary_dark</item>

так должно помочь

А правильно я понимаю, что активити должна подписываться на "сервис" и как то получать из него данные, или отдавать ему команды типа "загрузи список Х" а сервис будет отвечать - "загрузил" или что-то иное?

Я тут просто похоже, "пришел" к такой концепции архитектуры приложения, а потом осознал, что где-то я уже об этом слышал в книжках по андроиду )

Хочу решить проблему того, что иногда в приложении у меня может быть например 2 параллельных сетевых запроса к апи. И может быть такой кейс, когда токен протух, первый запрос перехватил 401 а второй тогда не должен обновлять токен. Т.е. их надо как то синхронизировать. Поможет ли мне тут сервис?

Хочу решить проблему того, что иногда в приложении у меня может быть например 2 параллельных сетевых запроса к апи. И может быть такой кейс, когда токен протух, первый запрос перехватил 401 а второй тогда не должен обновлять токен. Т.е. их надо как то синхронизировать. Поможет ли мне тут сервис?

Если уж по книжному хочешь - прям чтоб совсем правильно - AccountManager - тебе в помощь Так или иначе каждый запрос у тебя должен уметь перехватить ошибку протухания - перезапросить новый токен - и выполниться еще раз с новым(хочешь рекурсией через catch, хочешь фором, ифом - как удобней) только имей виду эта "красивая петля" может не сработать - если удаленно юзер поменял пароль - тогда твой кэшированый пароль - не спасет в перезапросе токена

У меня первый раз логинится, и выдается accessToken на месяц и refreshToken на год. Когда accessToken протухает, я иду получать новый через refreshToken. Если пользователь сменил пароль, то его refreshToken инвалидируется, и я из этой "красивой петли" выбиваю его на LoginActivity

У меня первый раз логинится, и выдается accessToken на месяц и refreshToken на год. Когда accessToken протухает, я иду получать новый через refreshToken. Если пользователь сменил пароль, то его refreshToken инвалидируется, и я из этой "красивой петли" выбиваю его на LoginActivity

ну тогда - ок ;)

Там у меня уже ад на самом деле. И AccountManager не совсем понимаю как мне поможет. Мне надо уметь при 401 на любой запрос пойти и обновить токен

Пароль и логин на устройсве не храню, как, наверное кто-то завещал.

Тут работает простое правило — когда хочешь сохранить пароль пользователя, осознай, что это заведомо херовая идея

ну кроме как все запросы оборачивать - через проверку на случай протухания - никак - ну я по крайней мере не вижу как

мы про ретрофит?

У меня щас в ретрофит воткнут интерсептор

в чем тогда проблема в нем освежить токен?

Но тут как я выше написал другая проблема. Походу, мне нужен менеджер запросов, ибо если 2 запроса ушло обновлять токен то конец

почему? :)

Потому что будет 2 запроса. 2 токена выписано

Даже если я первый на сервере инвалидирую, это какой то костыль

Я за такое одну студию уже ебал, они это долго фиксили. И вот мне воздалось походу

ну ок, если запрос на новый токен ушел - повесь где нибудь флаг

чтобы второй интерцептор не долбился, а чекал флаг

ну мож как-то перезапрашивалку тебе потоко-обезопасить?

или флаг

Да, нужна какая-то атомарная точка контроля

у тебя ходилка за токеном - получается должна быть - единственная на всех и конкурентная ... угу

У меня этот интерсептор ретрофитовский начинает иметь как-то много отвественности. Это меня пугает. Он щас умеет токены писать, сохранять предыдущий запрос, повторять его когда токен освежили и открывать LoginActivity когда тлен

Щас если туда потокобезопасную логику наверну, вообще никто не разберется )

Ну вот и получается, AccountManager - взял бы эту часть на себя, вместе с окном логина - и был бы атомарным

))

и нотификашки при сбое умеет выкидывать, при клики на которые - открывается логин активити)) а то пошел у тебя запрос - ты апп закрыл - а он через пол минуты в фоне понял что логин открывать - самое то )))

А, еще такая тема, я же тут все на асинхронные вызовы ретрофита переделал. В активити код стал в разы лучше. Но вот код в этом интерсепторе получается заимел примерно такой код: while (mUnauthorizedRequest != null) { try { Thread.sleep(500); } catch (InterruptedException e) { break; // pass } }

Что-то мне подсказывает, что это тоже не ахти. Но как то же мне надо в одном потоке "ждать" пока другой наконец токен обновит

Или просто сделать копии методов с суффиксом Sync?

ну если у тебя mUnauthorizedRequest - volatile - то тоже пойдёт синк тоже - как вариант

А, еще такая тема, я же тут все на асинхронные вызовы ретрофита переделал. В активити код стал в разы лучше. Но вот код в этом интерсепторе получается заимел примерно такой код: while (mUnauthorizedRequest != null) { try { Thread.sleep(500); } catch (InterruptedException e) { break; // pass } }

Thread.join()

тебе тока все синхронайзить не надо надо именно те два - которые один "дай токен" второй "обнови токен"

типа выполнение одного из них лочит - другой

и должно быть как часики

Thread.join()

Или нормально

А у всех в этом месте так сложно получается? Или у вас как-то по-другому реализовано?

А вообще лучше https://docs.oracle.com/javase/7/docs/api/java/util/concurrent/locks/Condition.html

Или присмотреться к RX

RX конечно может и клево, но я согласен на костыль с классической джавой )) Мне ж тут еще и бекенд делать. Голова и так пухнет

RX конечно может и клево, но я согласен на костыль с классической джавой )) Мне ж тут еще и бекенд делать. Голова и так пухнет

Ну дак значит посмотри механизмы синхронизации в Java, их полно

А то что у тебя вечный цикл со sleep - по нормальному очень хреновое решение, особенно для твоего юзкейса

Ну я думал, может что уже более-менее готовое для андроида есть. Задача то типовая поидее.

Ну я думал, может что уже более-менее готовое для андроида есть. Задача то типовая поидее.

Есть, rx называется, именно эти задачи и упрощает. Иначе смотри ссылон

Есть, rx называется, именно эти задачи и упрощает. Иначе смотри ссылон

Ясно, спасибо. Буду иметь ввиду.

))) на Андроиде на все есть "готовые" решения.... только уж больно они абстрактные )))

Так а вы все используете Rx получается?)

нет

Ну вот и получается, AccountManager - взял бы эту часть на себя, вместе с окном логина - и был бы атомарным

Волшебный менеджер

Волшебный менеджер

а то.... там тока поседеть можно пока по-фэншую его заимплементишь)) ...но на выходе - все самые вкусные фишки

Может вписаться в эту тему...

https://habrastorage.org/getpro/habr/post_images/bf2/121/401/bf21214012b53c345d548ab1fc31b3f7.png Чет, перехотелось ? (на самом деле нет)

Может вписаться в эту тему...

смотри по времени - это такая тема опасная (как контент провайдер) - заимплементишь - будет тебе счастье - но, еси честно - там не всё так просто - есть подводные камни

угу

Есть камни, по которым ты уже пршелся?

угу

Может вписаться в эту тему...

Однозначно стоит попробовать

угу

Например?

ERROR: S client not available

1 - Дофига деклараций ксмл - специальный у них там Пишешиь AuthService - переопределяешь - инвалидацию и возврат токена Пишешь authActivity - с созданием записи нового аккаунта в ак мэнеджер дальше - для секюрности рекомендуют криптовать там токен

Пишешь Активити-настройки аккаунта

Логин активити - дожна быть универсальная как для создания нового так и для подтверждения существующих credentials - там на входе надо интенты резолвить

http://blog.udinic.com/2013/04/24/write-your-own-android-authenticator вот тут все подробно изложено

там типа поддержка разных типов токенов, разных уровней доступа, можешь предоставлять токены внешним аппам - итд - ну всё заточено изначально было под совместное использование апами общих oauth-аккаунтов и токенов тут еще надо смотреть как это будет применимо к твоей системе авторизации

гугл в Api 5 -это запипилил для себя - чтоб все его апы имели общее хранилище токенов и единый аккаунт - а потом расшарили для девелоперов так с тех пор оно почти не менялось

Ну у меня OAuth2-like авторизация

Наполовину по драфту сделана руками, половина выкинута

Ну значит гармонично - вписываешься

... а самый главный камень!

аккаунт мэнэджер подразумевает что ты можешь иметь не тока залогиненого Васю но еще и Петю - и вообще скок хочешь аккаунтов - твоей системы, тока вот это вынуждает на дополнительную работу по переключению в аппе(как у гугловых аппов) этих аккаунтов - либо делаешь костыль как все соцсети - после добавление первого аккаунта - следующие добавлять нельзя - типа "Нельзя создать на устройстве более одного аккаунта skype" и тд

Ну скорее всего так и залеплю тогда

Ну скорее всего так и залеплю тогда

ну ... успехов тогда... но смотри - писанины там не мало - это всёж более фэншуйный и соответсвенно трудоёмкий путь - если что - спрашивай

Спасибо.

Кого лучше купить Рода Стивенса или Стивена Скиена (алгоритмы)?

Так это получается AccountManager хранит пароль. Эх. Одной проблемой больше )

кто что скажет по поводу новой архитектуры от Uber ? https://eng.uber.com/new-rider-app/?utm_source=Android+Weekly&utm_campaign=50fae67482-Android_Weekly_236&utm_medium=email&utm_term=0_4eb677ad19-50fae67482-338082521

Riblets

Так это получается AccountManager хранит пароль. Эх. Одной проблемой больше )

да, его еще и отгреха шифровать предлагают) но... типа чтоб юзера не задалбывать ui-ем каждый раз при протухании.... как то так

мужики .ogg без проблем можно воспроизводить?

Кстати на счет разных аккаунтов... Это даже будет полезно для меня )

Кстати на счет разных аккаунтов... Это даже будет полезно для меня )

Можешь на смартфоне в настройках "Аккаунты- Google-добавить" добавить еще гугл-аккаунт и посмотреть как у них в аппах (н-р gmail) - переключается текущий аккаунт (левый боковой шкафчик с навигацией - NavigationDrawer) - но это жесть - такое реализовывать

Чет я не понял одну вещь с этим AccountManager. Как мне контролировать, что токен который сохранен внутри не протух? ведь идея же в нем такая, что я оттуда получаю всегда валидные данные? А если нет, то у меня дублируется логика валидации access/refresh/и пр.

Т.е. вот я написал LoginActivity, Authenticator, Service, обмазался XML с ног до головы. Но теперь просто вопрос, как мне без запары получать тот самый токен? Дергать getAuthToken выглядит не тем путем, который должен быть для этого. Там в аргументах response и проч. peekAuthToken() тоже не варик, то возвращает сырые данные, т.е. надо валицию писать вокруг него. А где валидация там и запуск/перенаправление на LoginActivity что по сути дублирует getAuthToken() из Authenticator...

Чет я не понял одну вещь с этим AccountManager. Как мне контролировать, что токен который сохранен внутри не протух? ведь идея же в нем такая, что я оттуда получаю всегда валидные данные? А если нет, то у меня дублируется логика валидации access/refresh/и пр.

Ну ... не совсем... ему то откуда знать пока кто-нибудь не сходит и не уткнётся. ты пошёл взял у него токен (он отдаст кэшированый ничего у себя внутрях не вызывая) - если с этим токеном сервер тебя послал, ты тут же ему говоришь invalidateToken (он при этом клинит свой кэшированый) и еще раз getToken(на этот раз он вызовет тобой переопределённый метод, который достанет сохр логин-пароль - сходит на сервак - получит свежий токен - закэширует и вернет) - и с новым токеном - еще раз на сервак

Т.е. вот я написал LoginActivity, Authenticator, Service, обмазался XML с ног до головы. Но теперь просто вопрос, как мне без запары получать тот самый токен? Дергать getAuthToken выглядит не тем путем, который должен быть для этого. Там в аргументах response и проч. peekAuthToken() тоже не варик, то возвращает сырые данные, т.е. надо валицию писать вокруг него. А где валидация там и запуск/перенаправление на LoginActivity что по сути дублирует getAuthToken() из Authenticator...

сек...

Подскажите как лучше решить проблему. Нужно в приложение засунуть кучку иконок (.svg, ~50 шт). Потом нужно получить массив этих иконок и засунуть в recycler view чтобы пользователь выбрал одну.

хм токены придумывали чтоб пароль не хранить

хм токены придумывали чтоб пароль не хранить

да, однако гугл хром - на десктопе - по дефолту - все за тебя помнит(пароли в тч) - и это согласись облегчает

Подскажите как лучше решить проблему. Нужно в приложение засунуть кучку иконок (.svg, ~50 шт). Потом нужно получить массив этих иконок и засунуть в recycler view чтобы пользователь выбрал одну.

ну перегони их в xml векторный , да и используй

например этим http://inloop.github.io/svg2android/

Т.е. вот я написал LoginActivity, Authenticator, Service, обмазался XML с ног до головы. Но теперь просто вопрос, как мне без запары получать тот самый токен? Дергать getAuthToken выглядит не тем путем, который должен быть для этого. Там в аргументах response и проч. peekAuthToken() тоже не варик, то возвращает сырые данные, т.е. надо валицию писать вокруг него. А где валидация там и запуск/перенаправление на LoginActivity что по сути дублирует getAuthToken() из Authenticator...

Я делал так: перед тем как идти на сервак запрашиваю am.blockingGetAuthToken() - иду на сервак, если токен не валидный дергаю am.invalidateAuthToken(); и еще раз am.blockingGetAuthToken() - иду на сервак,