В iOS, если пользователь пытается приобрести IAP, а проверка моего сертификата на квитанцию не удалась, что такое правильное поведение? При тестировании в песочнице я просто получаю тонну всплывающих окон, просящих мой пароль. Если я назову финишную обработку, он перестанет запрашивать мой пароль, но я считаю, что это может привести к тому, что пользователь получит заряд без получения продукта.Что делать, если проверка IAP не удалась?
Pop Up A UIlertView. См ниже код ...
self.alert("Purchase Failed", Message: "Please Make Sure You are connected to the internet and try agian")
func alert(title:String, Message:String){
let actionSheet:UIAlertController = UIAlertController(title: "\(title)", message: "\(Message)", preferredStyle: UIAlertControllerStyle.Alert)
// for alert add .Alert instead of .Action Sheet
// start copy
let firstAlertAction:UIAlertAction = UIAlertAction(title: "OK", style: UIAlertActionStyle.Default, handler:
{
(alertAction:UIAlertAction!) in
// action when pressed
})
actionSheet.addAction(firstAlertAction)
// end copy
self.presentViewController(actionSheet, animated: true, completion: nil)
}
Я думаю, что обработка ошибок при выполнении в приложении покупки является одним из менее говорили о трудностях ведения в приложении покупки. Здесь есть несколько вопросов. Например: 1) Если вы выполняете валидацию квитанции о покупке на устройстве (т. Е. Валидация стиля дефиниции стиля> = iOS7), и эта проверка не выполняется, что вы должны делать? 2) Если вы выполняете валидацию с веб-сервером и что не удается, что вы должны делать? 3) Если вы храните квитанции на свой собственный веб-сервер и что это не удается, что вы должны делать? Я приведу некоторые идеи из своего приложения. Было бы здорово увидеть, что делают другие подобные методы обработки ошибок.
1) Если вы выполняете валидацию квитанции о покупке на устройстве (т. Е.> = Проверка стиля дешифрования iOS7), и эта проверка не выполняется, что вы должны делать?
Apple рекомендует обновить квитанцию (SKReceiptRefreshRequest), если ваша первоначальная проверка на устройстве не удалась. Но что, если проверка после обновления не удалась? Вы могли бы интерпретировать эту ситуацию, поскольку есть что-то серьезное (например, пользователь каким-то образом взломал ваше приложение, чтобы умышленно дать вам плохую квитанцию), сообщите пользователю, что покупка потерпела неудачу с отказом подтверждения чека, и завершите транзакцию (SKPaymentQueue finishTransaction :), не работает постоянно. Однако мне не нравится быть таким окончательным. Возможно, это моя уверенность, но что-то не так с моим программированием. Мне нравится давать пользователю больше шансов. Итак, мое решение состоит в следующем: 1) Сообщите пользователю, что валидация не удалась, 2) переведите SKPaymentTransaction в состояние «hold» и 3) call finishTransaction. Эта идея состояния удержания - это мое изобретение, и ничто не предлагалось (или поддерживалось) Apple. Я создал измененный подкласс SKPaymentTransaction и имею очередь этих объектов (назовите их SPASMutablePaymentTransaction), которые я храню (используя NSCoding) в NSUserDefaults. Почти всегда эта очередь пуста, но если я получаю отказ проверки, как я здесь говорю, я создаю объект SPASMutablePaymentTransaction, копирую информацию о SKPaymentTransaction (включая квитанцию, например, из пакета), и сохраняю эту транзакцию в мою очередь хранения. Я делаю видимым (обычно скрытую) часть моего пользовательского интерфейса, что позволяет пользователю повторить транзакции состояния.
Сложный? Да, немного. Однако, поскольку мы имеем дело с пользователем, дающим вам деньги, я стараюсь быть уверенным. Кажется, что это хорошо работает до сих пор в тестировании. У меня нет отзывов от пользователей по этому поводу (или аналитики), но он развернут в хранилище приложений.
2) Если вы выполняете валидацию с помощью веб-сервера и что не удается, что вам делать?
Для меня это аналогичный случай для 1), выше. Вы попытались сделать валидацию квитанции, и она не удалась. Сначала попробуйте обновить квитанцию (см. Выше), а затем повторите попытку проверки вашего сервера. В моем приложении, так как я всегда делаю подтверждение приема на устройстве первым, поэтому мне не имеет смысла обновлять квитанцию снова (так как я сделал бы это, если бы проверка на подтверждение приема на устройстве не удалась). Итак, я снова поместил квитанцию в состояние «держа» (как указано выше) и разрешил пользователю повторять транзакции состояния холдинга по своему усмотрению.
3) Если вы храните квитанции на свой собственный веб-сервер и это не удается, что вы должны делать?
(a) Предположительно, это определенно не должно быть случаем, когда вы надолго не можете дать пользователю их покупку. Это отказ от ваших услуг. В моем случае это может произойти, например, если я получаю сетевую ошибку при общении с моим сервером. Я делаю что-то совсем другое. Я не сразу даю пользователю доступ к их покупке, и я не помещаю транзакцию в состояние «удерживания». Вместо этого я настроил таймер, чтобы повторить процесс хранения чека на моем сервере. Он повторяет попытку через пару минут. Я говорю пользователю, что я делаю. Я храню данные квитанции в NSUserDefaults (снова используя объект SPASMutablePaymentTransaction), поэтому будет сохраняться в этой повторной попытке, даже если приложение завершится с ошибкой /. Когда мне удается сохранить квитанцию на моем сервере, я предоставляю пользователю доступ к покупке.
(b) В этом случае I do call finishTransaction: и я еще не предоставил пользователю доступ к покупке. Я мог бы избежать некоторых этих подробностей, не вызвав функцию finishTransaction :, и просто позвольте моему наблюдателю транзакций снова обработать этот процесс (например, когда приложение запустится), но пользователю, вероятно, придется снова ввести свой идентификатор Apple. Я полагаю, что это моя проблема (т. Е. Мне не удалось сохранить информацию о квитанции на моем сервере), поэтому я пытаюсь обработать ее под обложками.