II
Как можно валидно авторизовать юзера на своем сервере, который совершил инапп?
А если это подписка?
А если это подписка?
что о пользователе точно известно на момент совершения покупки?
Size: a a a
2019 October 26
S
I I
что о пользователе точно известно на момент совершения покупки?
Самому интересно узнать, никогда инаппы не делал))
S
Ну известна о нем только публичная инфа - небезопасно (наверно)
S
А энвы приложения вроде можно декомпильнуть и посмотреть
II
Самому интересно узнать, никогда инаппы не делал))
в общем вот так, мб ниже описание в деталях норм https://stackoverflow.com/a/5364225/4742680
S
I I
в общем вот так, мб ниже описание в деталях норм https://stackoverflow.com/a/5364225/4742680
Есть отличия от обычной инаппки??
II
Есть отличия от обычной инаппки??
как я понял в случае обычных покупок ты обращаешься к серверу эпла. в случае своего сервака запросы проксируются сервом с целью обработки (сохранения/загрузки) данных о покупках.
II
S
I I
Вот это уже интересно, спасибо!
2019 October 27
SH
Доброй ночи господа
SH
Если кому интересно
SH
Здравствуйте, господа разработчики.
Кто-нибудь может подсказать какой deeplink для instagram ios для перехода в Direct Messages на конкретный тред (гугл молчит).
Вообще я думал что это будет что-то вроде instagram://direct?username=<USERNAME> - но это и еще штук 8 разных вариантов не работают.
Кто-нибудь может подсказать какой deeplink для instagram ios для перехода в Direct Messages на конкретный тред (гугл молчит).
Вообще я думал что это будет что-то вроде instagram://direct?username=<USERNAME> - но это и еще штук 8 разных вариантов не работают.
Я нашел решение, пример:
instagram://direct-thread?id=<INSTAGRAM USER_ID>
instagram://direct-thread?id=<INSTAGRAM USER_ID>
TF
привет! подскажите пожалуйста есть такая задача.
каждую секунду делать запрос и обновлять данные.
конечно можно просто обычные запросы делать с
но например там будет медленный инет и запросы будут "выстраиваться в очередь". и в идеале лучше отменять те запросы которые "не успели" произойти.
решения для этого это
каждую секунду делать запрос и обновлять данные.
конечно можно просто обычные запросы делать с
URLSession и тд.но например там будет медленный инет и запросы будут "выстраиваться в очередь". и в идеале лучше отменять те запросы которые "не успели" произойти.
решения для этого это
NSOperationQueue? или в какую сторону лучше почитать/покопать?РЛ
Если на второй стороне есть вебсокеты
РЛ
то лучше их
TF
Если на второй стороне есть вебсокеты
не, там нет..(
TF
тогда лучше оперейшн кью получается? @jeudesprits
РЛ
Да, начните с последовательной очереди
TF
Да, начните с последовательной очереди
понял. спасибо !
РЛ
Лучше почитайте про Dispatch.async(when: .. .