пушей и мне надо чтобы он был на беке всегда актуальным.
Как правильно реализовать такое на мобилке?
Т.е. надо хранить старый токен (чтобы когда появится новый - знать какой заменить на беке, т.к. у юзера может быть несколько устройств), новый токен и инфу о том что надо ли передавать на бек вообще эту инфу. Т.е. я делаю это не сразу после генерации в Арр, а только после успешного логина юзера.
override fun onNewToken() { sendToServer() }
На что обижен?
А что это за прикол с твоим ответом? Я буквально стараюсь совета получить как такую логику реализовывать и норм ли использоваться SP в таком казалось бы простом моменту, ты мне буквально говорил отправляй токен при получении нового. Если не удосужился даже дочитать вопрос = 🤡 А если это твоё реально не рофл решение, то аминь, пуши будут приходить только на одно устройство, не говоря уже о том что onNewToken это не первое получение токена и только, а только новые токены, а всякие getTokens() будут вызываться из App при каждом старте, + постоянными перезаписями бек задудосим
лень читать мысли школьника
На кой ты отвечаешь на вопрос вообще если посчитал меня школьником, просто настроение испортить или самоутвердиться? Если уж интересно - то не угадал, я не школьник уже 6 лет, код пишу столько же и первый раз с настолько специфичным кейсом о пушах встретился, где у юзера может быть несколько устройств и полноценная оффлайн работа по приложению, потому очень не хочется положить бек в стиле "миша, вот тебе диплинк"
Можешь попробовать информацию об устройстве передавать еще, и в зависимости от устройства токен менять
Ну в этом вопросе по проще ситуация, когда у юзера несколько устройств, то считается что на все устройства одинаковые пуши нужны и желательно одновременно, потому менять их просто так не приходится. Скорее вопрос инвалидации очень остро встаёт, чтобы не накапливались мертвые на беке
А через что у вас пуши отправляются? Мне кажется для каждого девайса нужны отдельные токены. Просто на беке хранить список токенов для одного аккаунта и по каждому токену отправлять пуши, если я верно понял твой кейс
Так и делаем, для каждого устройства отдельные токены. Вопрос именно в толковой реализации контролирования этого процесса с мобилки. Пуши от рустора, универсальные, потому и хмс и фб тоже будут потом к ним подключены, следовательно токенов будет ещё больше, но это другая история.
Вот вы авторизовались, получили два токена - accessToken и refreshToken. У вас поменялся пуш токен, вы его отправляете на бек через эндпойнт с акксесс токеном, бек понимает что для этой сессии токен поменялся, обновляет. Бывает так что запрос не проходит, а сервис, который отправляет пуши говорит что ваш пуш токен протух, тогда бек удаляет из списка пуш токенов для этого аккаунта. То есть гарантии того что с мобильного приложения будет всегда прилетать актуальный токен нет.
Заметил что многие компании заменяют токены пин-кодом
Токены на беке привязаны к userId, т.к. в привязке к jwt у них проблемы (не знаю какие, честно говоря), потому сессию они не могут отслеживать самостоятельно, а потому мобилка сама скидывает айдишник юзера при запросах. Сейчас мобилка токен насильно инвалидирует и запросом просит удалить с бека при выходе из аккаунта например. При входе схема обратная, генерит и отправляет. Т.е. бек удаляет токены самостоятельно только при условии что сервис пушей при попытке отправки склад что токен мертв. Если вдруг токен сменился во время сессии (рустор иногда удивляет этим, но редко) то тут мы ивент ловим, отправляем старый токен и новый, чтобы заменили на беке. Естественно чтобы лишние разы не отправлять на бек запросы - boolean переменную в кеше, знает ли о нынешнем токене бек (с оффлайн работой приложения это особенно необходимо) и так это все в целом то и работает вроде. Но вот звучит как костыли, понимаю что переложить на бек это было бы логичнее, но имеем что имеем и вот думал мб в таких условиях есть решение по изящнее
Обсуждают сегодня