Как функционира IN_APP_NOTIFY, когато възстановяването се извършва с таксуването в Android App? - Android, покупка в приложение, таксуване в приложението, титанови модули

Ние разработихме нашето приложение, използвайки Titanium Studio и Appcelerator предлага безплатен модул Фактуриране в приложението, което поддържа само API v2 (Знам, че трябва да използваме v3, но ние сме инди група, така че $ 100 за модула, който поддържа API v3, не е за момента).

Прочетох документацията на Работен процес за таксуване в приложението за API v2и досега логиката на покупката работи като чар.

Това е, докато не стигнем до частта от възстановяванията. Ние управлявахме продукти и абонаменти в нашето приложение.

Съгласно документацията, когато се прави възстановяване на сумата,. \ T IN_APP_NOTIFY събитие се задейства, което изисква от нас да направим getPurchaseInformation обадете се. Това, което се съмняваме, е това, което се случва след като направим getPurchaseInformation обадете се. Има ли a PURCHASE_STATE_CHANGED Събитието се задейства? Ако е така, подписаните данни с поръчките се връщат актуализирани?

Например, да кажем, че потребител Uriel купува Managed Product A, а след това Uriel иска възстановяване. getPurchaseInformation е направено обаждане.

Какво събитие ще се задейства, за да мога да актуализирам приложението, за да заключва съдържанието, което преди това е било достъпно за потребителя? Ще PURCHASE_STATE_CHANGED да се задейства? Ако е така, подписаните данни с информацията за поръчките ще бъдат върнати празни? В моето PURCHASE_STATE_CHANGED Удостоверявам дали има поръчки, ако не са намерени поръчки, тогава цялото съдържание се блокира.

Така че накратко, правилно ли е моето предположение или работният поток за възстановяване е различен?

За справка, тук са моите PURCHASE_STATE_CHANGED функция:

function PURCHASE_STATE_CHANGED_EVENT(e)
{
Ti.API.info("PURCHASE STATE CHANGED CALLED");
Ti.API.info("Signature Verification Result:n" + VerificationString(e.result));
Ti.API.info("Signed Data:n" + e.signedData);
/*
* We receive an object that might look like this
* {
*  "nonce":-2458019374247073515,
*  "orders":[
*   {
*    "notificationId":"notificationId",
*    "orderId":"transactionId",
*    "packageName":"my.package",
*    "productId":"in_app_identifier",
*    "purchaseTime":1394062412214,
*    "purchaseState":0
*   }
*  ]
* }
*/

if (e.signedData != null) {
var response = JSON.parse(e.signedData);
/*
* We are not guaranteed to have any orders returned so
* we need to make sure that this one exists before using it.
*
* If there is no notificationId then there is no need to confirmNotifications().
* This happens when restoreTransactions() triggers a PURCHASE_STATE_CHANGED_EVENT.
*/
if(response.orders.length === 0)
{
Ti.API.info("nothing to restore");
setNoTransactionsToRestore();
return;
}
for(var i = 0; i < response.orders.length; i++)
{
if(typeof response.orders[i] !== "undefined")
{
Ti.API.info("set purchase flag");
setPurchaseFlag(response.orders[i].productId);
}
if (response.orders[i] && response.orders[i].notificationId)
{

Ti.API.info("confirming notification for order " + JSON.stringify(response.orders[i]));
var synchronousResponse = InAppBilling.confirmNotifications({
notificationIds: [response.orders[i].notificationId]
});
displaySynchronousResponseCodes(synchronousResponse);
}
}
}
else
{
Ti.API.info("signed data was null");
}
}

InAppBilling.addEventListener(InAppBilling.PURCHASE_STATE_CHANGED_EVENT, PURCHASE_STATE_CHANGED_EVENT);

и моят IN_APP_NOTIFY функция:

function NOTIFY_EVENT(e)
{
Ti.API.info("NOTIFY CALLED n" + "Notify Id:n" + e.notifyId);

var synchronousResponse = InAppBilling.getPurchaseInformation({
notificationIds: [e.notifyId]
});
displaySynchronousResponseCodes(synchronousResponse);
}
InAppBilling.addEventListener(InAppBilling.NOTIFY_EVENT, NOTIFY_EVENT);

Отговори:

Прочетох част от документацията, която дава повече подробности за работния процес, особено за събитие IN_APP_NOTIFY. Тук намерих това:

Обработката на възстановявания и други нежелани IN_APP_NOTIFY съобщения

Има два случая, при които молбата ви можеполучавате IN_APP_NOTIFY намерения за излъчване, въпреки че молбата ви не е изпратила Съобщение REQUEST_PURCHASE. Фигура 5 показва последователността на съобщенията за и двата случая. Типове заявки за всеки sendBillingRequest () метода са показани с удебелен шрифт, намеренията за излъчване са \ t За яснота, фигура 5 не показва намеренията за излъчване на RESPONSE_CODE които се изпращат за всяка заявка.

Фигура 5. Последователност на съобщенията за възстановявания и други непоискани IN_APP_NOTIFY съобщения.

В първия случай молбата ви може да бъде полученаIN_APP_NOTIFY намерение за излъчване, когато потребителят е инсталирал приложението ви на две (или повече) устройства и потребителят прави покупка в приложение от една от устройства. В този случай Google Play изпраща съобщение до IN_APP_NOTIFY второто устройство, информиращо за това, че има покупка промяна на състоянието. Вашето приложение може да обработи това съобщение по същия начин обработва отговора от инициирано от приложението REQUEST_PURCHASE съобщение, така че в крайна сметка вашето приложение да получи PURCHASE_STATE_CHANGED съобщение за намерение, което включва информация за закупения артикул. Това важи само към елементи, чийто тип на продукта е зададен на "управляван на потребител сметка."

Във втория случай молбата ви може да бъде полученаIN_APP_NOTIFY намерение за излъчване, когато Google Play получи известие за възстановяване от Google Wallet. В този случай Google Play изпраща IN_APP_NOTIFY съобщението към вашата заявка. Приложението ви може да обработи това съобщение по същия начин, по който обработва отговорите от инициирано от приложението Съобщение REQUEST_PURCHASE, така че в крайна сметка вашето приложение да получи съобщение PURCHASE_STATE_CHANGED, което включва информация за елемент, който е бил възстановен. Информацията за възстановяване е включена в JSON низ, съпътстващ излъчването на PURCHASE_STATE_CHANGED умисъл. Също така, полето buyState в JSON низ е зададено на 2.

Това означава, че всяко възстановяване на средства от Центъра за търговец ще задейства IN_APP_NOTIFY, когато: getPurchaseInformation се осъществява повикване, a PURCHASE_STATE_CHANGED събитие ще задейства и възстановената поръчка вече няма да се показва, което означава, че валидирането ми за никакви поръчки няма да задейства и съдържанието ще блокира.