Посмотрел примеры на Гитхабе про сохранение токена (Firebase), и заметил, что часто его сохраняют в SharedPreferences. В доках Firebase есть пример кода, где предполагается, что токен будет сохраняться на сервере. Достаточно ли сохранить токен только в SharedPreferences и нужно ли на сервере тоже его сохранить?

а как проверить тогда токен на валидность, если не хранить его на сервере?

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

а, я подумал про юзер токен

Не, это токен экземпляра приложения

Похоже, на сервере тоже нужно сохранять токены, иначе я просто не смогу отправить сообщение на другое устройство не зная токена этого устройства.

onLayout() не срабатывает когда вызываю setX()

onLayout() не срабатывает когда вызываю setX()

и не должен

https://developer.android.com/reference/android/view/View.html#setX(float)

https://developer.android.com/reference/android/view/View.html#setTranslationX(float)

This effectively positions the object post-layout, in addition to wherever the object's layout placed it.

view.animate().translationX(0);

тем более

Анимирую виюху. А могу ли слушать где о том что меняется X у виюхи?

анимация ни в коем случае не должна вызывать layout

Анимирую виюху. А могу ли слушать где о том что меняется X у виюхи?

вью ничего не знает о своем местонахождение в леяуте

вью ничего не знает о своем местонахождение в леяуте

Спасибо за короткий и самый полезный ответ

прицепи прогресс листенер на анимацию

Вот листенер начиная с 19 апи оказывается))

Что бесят)

https://developer.android.com/reference/android/view/ViewPropertyAnimator.html#setUpdateListener(android.animation.ValueAnimator.AnimatorUpdateListener)

Вот листенер начиная с 19 апи оказывается))

но есть же ViewCompat.animate(view)

он дублирует апи проперти аниматора до апи 9

но есть же ViewCompat.animate(view)

Спасибо. Я больше Архитектор бизнес логики. И Интерпрайз. А в UI полный рак))

он дублирует апи проперти аниматора до апи 9

Спасибо тебе чувак за помошь.

а я обожаю работать с юай )

Да видно чувак))

Мне доменный слой больше ближе)

Мне доменный слой больше ближе)

тянешь MVC в андроид? )

)) Хехе)) Нету такого патерна в МВС в чистом виде сейчас)

У всех свои тараканы в голове. И не только на ведре, и на ЖаваЭфИкс и в веб фремворках.

)) Хехе)) Нету такого патерна в МВС в чистом виде сейчас)

потому что надо считаться с самим андроидом

Рожали чего то и назвали МВС) 35 лет тому назад МВС был совсем инным)

потому что надо считаться с самим андроидом

Да не. Не согласен. Хорошому кодеру фремворк не помеха

Вот насколько хорошо или плохо сделан это другой вопрос. А сушествования платформы всегда мешал многим.

Дроид это не просто фреймворк :)

Если проектировать именно доменный слой правильно и работать с сервисами как "СЕРВИСЫ" а не писать внутри них код или логики приложении все будет круто

просто добавь немного абстракции ©

просто добавь немного абстракции ©

Да. Всегда можно писать афигенно. Чисто. По слоям. UseCase driven development... Если... есть дхуя времени)

ТОнны я бы сказал)

Я понял одного) Лучше избежать овер инжениринг) Если есть задача нужно его решать и все))

я использую гугловый мвп, в принципе ок. имхо

И тем боле если не долгосрочный проект то подавно нафиг)

я использую гугловый мвп, в принципе ок. имхо

Вопрос зачем?)))

Вопрос зачем?)))

Предлагаешь просто из говна и палок?)

Я тоже вроде юзаю) Но... Думаю теперь плюну на это дело(Если не долгосрочный проект)

Предлагаешь просто из говна и палок?)

Он имеет в виду зачем для этого тащить либу

Предлагаешь просто из говна и палок?)

Главное что бы работал)

Он имеет в виду зачем для этого тащить либу

нет либы ныкакой

Он имеет в виду зачем для этого тащить либу

Нет, Я не говорю так)

Он имеет в виду зачем для этого тащить либу

Гугловый мвп это не либа

Я сторонник либ.

Я думаю нафиг писать самому с нулья если есть велтестед инструмент.

Юзай и кайфуй)

Гугловый мвп это не либа

Я подумал про мосби или как там оно

Их мног. Мосби, мокси итд.

Если тул делает за тебя задачу то нужно использовать

Почему и нет.

Нуюно даже юзать

Нуюно даже юзать

мне не тяжело написать 2 интерфейса для активити

Я подумал про мосби или как там оно

Не, у Гугла есть на гитхабе репа с примером архитектур

https://github.com/googlesamples/android-architecture

Я не давно подумал что проблема у андроид разработчиков в том что они не писали EE апы.

У них нету доменного уровня. У них нету цельная представления о проекте в контекте доменных объектов и юзкейсов(Я не о том юз кейсе который анкл боб говорил)

У них нету доменного уровня. У них нету цельная представления о проекте в контекте доменных объектов и юзкейсов(Я не о том юз кейсе который анкл боб говорил)

Это оверхед.

90% приложений получает джсон и парсит его

ERROR: S client not available

Какой там доменный слой

ОВерхед это кгда у тебя клинархитекче И так далее+МВП + другие хернии

А любой софт с начало должен определить свою бизнес логику.

90% приложений получает джсон и парсит его

А это совсем не в тему. Причем жсон, причем нетворк.

Мы про апп говорим.

Про продукт.

А как получить, откуда получить это другой разговор.

Это вопрос КАК? А мы сначало должны отвечать на вопрос Что это?

Потом КАК)

есть пример того что ты говоришь?

Ну дак а что в доменном слое делать, если ты просто отображаешь список новостей к примеру.

Какие там тесты писать

Ну дак а что в доменном слое делать, если ты просто отображаешь список новостей к примеру.

Ну тогда да. Согласен. Это не продукт который инкапсулирует определенную бизнес логику. Это просто фронтЭнд.

Вот, а учитывая что это мобильная разработка, то почти все приложения это фронтенд

За редким исключением

есть пример того что ты говоришь?

Завтра когда буду в универе скину код. У меня там проект был. Там где МВП. Домен слой формирует бизнеслогику.

Вот, а учитывая что это мобильная разработка, то почти все приложения это фронтенд

ну а такие как клиенты социалок?

И этого домен слоя юзаю в Андроиде и в JavaFx аппе

ну а такие как клиенты социалок?

А там что? Получили распарсили отобразили

Вот, а учитывая что это мобильная разработка, то почти все приложения это фронтенд

Телеграмм? Нет. Музыкальные приложении? Нет. Трелло? Нет.

А там что? Получили распарсили отобразили

вк, фейсбук

Телеграмм? Нет. Музыкальные приложении? Нет. Трелло? Нет.

Prism

они достаточно сложные

А там что? Получили распарсили отобразили

Здрасте))

Телеграмм? Нет. Музыкальные приложении? Нет. Трелло? Нет.

Что нет? Не совсем понял

Prism

В присме обработка на сервере.

Они же не могут обучать нейронку на телефоне)

ОВерхед это кгда у тебя клинархитекче И так далее+МВП + другие хернии

«клинакитекче» тогда уж.

они достаточно сложные

Сложные то сложные, но какая там логика?

«клинакитекче» тогда уж.

Если простой апп. Который тянит что то и показывает тогда ни чего не надо

А если долгосрочный продукт то лучше писать как надо.

Что бы доменный слой был покрыт тестами.