Täielik juhend Google Play arveldusteegi v7 värskendamiseks ja juurutamiseks

Kui töötate Androidis rakendusesiseste ostudega, peate varem või hiljem sellega tegelema Google Play arveldusteek v7See pole lihtsalt järjekordne värskendus: see sisaldab API muudatusi, uusi tellimisfunktsioone, konsoolinõudeid ja Google'i väga selgeid tähtaegu. Selle ignoreerimine pole enam võimalik, kui soovite oma rakenduse avaldamist või värskendamist Google Plays ilma üllatusteta jätkata.

Selles artiklis näete, kuidas Värskenda ja rakenda Google Play arveldusteegi v7 Samm-sammult: sellest, mis erineb PBL 5-st ja 6-st, kuni tellimuste, ühekordsete ostude, RTDN-i ja Play Billing Labiga testimise integreerimiseni ning selleni, kuidas ellu jääda sellistes ökosüsteemides nagu .NET MAUI, kus ametlik tugi on maha jäänud. Idee seisneb selles, et pärast lugemist saate migratsiooni enesekindlalt ja sentigi kulutamata ette valmistada.

Google Play arveldusteegi v7 ülevaade

Google Play arveldusteek 7 toob kaasa olulisi täiustusi arvete haldamisel. Maksed, tellimused ja eripaketidSiiski on see loodud nii, et migratsioon oleks suhteliselt sujuv. Hea uudis on see, et paljud uued API-d on valikulised: saate sõltuvust värskendada, mõnda viidet muuta ja teie põhiline integratsioon töötab endiselt.

See versioon keskendub kolmele põhivaldkonnale: uued tellimisvõimalused (nagu virtuaalsed kvoodid), parem tugi ettemakstud pakettidega ootel olevad ostudja API muudatused, mis kõrvaldavad eelmistes versioonides (PBL 5 ja 6) juba vananenud osad. Lisaks kohandab Google mõningaid veakäsitlusi ja seda, kuidas peaksite pooleliolevate tehingute käsitlemist tegema, et vältida ebajärjekindlust.

Alustuseks peate oma rakenduse moodulis oma failis sõltuvust värskendama. ehita.kõrv:

dependencies {
    def billingVersion = "7.0.0"
    implementation "com.android.billingclient:billing:$billingVersion"
}

Kui see on tehtud, on aeg üle vaadata kood, mis kasutab pärand-API-sid. Paljud sellega seotud kõned tellimuste proportsionaalne jaotus ja alternatiivne arveldamine Need on ümber nimetatud või eemaldatud, seega on enne millegi kompileerimist ja Play Console'i ​​üleslaadimist hea mõte hoolikalt üle vaadata kõik viited BillingClientile ja BillingFlowParamsile.

Ühekordsete ostude ja tellimustega monetiseerimisstrateegiad

Kui müüte oma rakenduses digitaalseid tooteid, ei piisa ainult ostudialoogi kleepimisest ja asja lõpetamisest: kujundage sujuv kasutajakogemus kogu ostuprotsessi vältelSee kehtib nii üksikute toodete (nii tarbitavate kui ka mittetarbitavate) kui ka tellimuste kohta. Mida loomulikum ja sujuvam on protsess, seda rohkem on konversioone ja seda madalam on tühistamiste määr.

Tüüpiline ostuprotsess Play arveldusega, olgu see siis tellimuse või üksiku toote puhul, järgib tavaliselt neid täpselt määratletud etappe, millest teie taustsüsteem peaks samuti teadlik olema:

• Kasutaja uurib saadaolevaid tooteid ja valib ühe.
• Rakendus käivitab Google Play arveldusprotsessi makse lõpuleviimiseks.
• Ost on sooritatud ja teie rakendus saab tulemuse.
• Teie server valideerib ostu Google Play arendaja API abil.
• Vastav sisu või õigus antakse teie süsteemis kasutajale.
• Google'ile teatatakse, et ost on töödeldud (tarbitud või kinnitatud).

Tarbekaupade puhul on oluline, et tarbi žetooni õigel ajal sujuva tagasiostu võimaldamiseks ja abistamiseks Blokeeri juhuslikud ostud Google PlaysTellimuste puhul peate kontrollima pikendamisi, armuperioode, peatamisi ja tühistamisi, et kasutaja saaks täpselt selle, mille eest ta on maksnud, ja mitte päevagi vähem.

Rakendusse integreerimine on vaid pool tööd: teie server peab säilitama usaldusväärne õiguste ja ostustaatuste registerSee on eriti oluline, kui pakute platvormideülest juurdepääsu või vajate üksikasjalikku statistikat tulude, klientide hoidmise ja klientide lahkumise kohta. Siin tulevadki mängu reaalajas arendajate teavitused (RTDN-id), mis toimivad ostutsükli "musta kastina".

RTDN-i abil saate reageerida peaaegu reaalajas kriitilistele sündmustele: uus ost, uuendamise ebaõnnestumine, tellimuse armuperioodi sisenemine või tühistatud ost. See võimaldab teil välja töötada strateegiaid abonentide taastamine ja pettuste ennetamine, näiteks automaatne e-kirja saatmine makse ebaõnnestumise korral või õiguste kohandamine, kui klient võrguprobleemide tõttu sõnumit kätte ei saa.

Reaalajas arendajate teavitused (RTDN) ja Google Cloud Pub/Sub

RTDN-id kasutavad Google Cloud Pub/Sub reaalajas sõnumsidesüsteemina Google Play ja teie taustsüsteemi vahel. Google Play avaldab sündmusi avaldamise/tellimise teemal ja teie tellite selle teema, et saada sõnumeid iga kord, kui ostu või tellimuse olek muutub.

Põhivoog on lihtne: Google Play saadab Pub/Sub teemale base64-kodeeringuga sõnumi, teie tellija eraldab selle, dekodeerib selle ja töötleb teatist. Välja sees data Sõnumis leiad JSON-objekti Arendaja teatismis sisaldab teavet nagu sõnumi versioon, paketi nimi, sündmuse aeg ja konkreetsed andmed ühekordsete ostude, tellimuste, tühistatud ostude või prooviperioodide kohta.

{
  "version": string,
  "packageName": string,
  "eventTimeMillis": long,
  "oneTimeProductNotification": OneTimeProductNotification,
  "subscriptionNotification": SubscriptionNotification,
  "voidedPurchaseNotification": VoidedPurchaseNotification,
  "testNotification": TestNotification
}

Tänu nendele sõnumitele saate Hoidke oma taustsüsteem sünkroonis isegi siis, kui kasutaja seade rikki lähebKujutage ette, et kasutaja sooritab edukalt ostu, Google Play kinnitab selle, kuid mobiilseade kaotab ühenduse enne, kui teie rakendus saab arveldusteegist tagasihelistamise teate. Ilma RTDN-ita ei pruugi te seda kunagi teada. Pub/Sub-i puhul saab teie server eraldi teate ja saab õiguse kliendist sõltumatult anda.

Pilvepõhise avaldamise/sub-konfiguratsioon RTDN-i jaoks

Enne RTDN-i aktiveerimist Google Play konsoolis peate projekti ette valmistama Google'i pilveplatvorm (GCP) ja konfigureerige seal Pub/Sub. Protsess on suhteliselt lihtne, kuid kõige parem on seda hoolikalt järgida, et vältida üllatusi õiguste või ressursside nimedega.

Teema loomine

Esmalt peate looma Avaldamise/tellimise teema mis toimib teie Google Play avaldamispunktina. Valige Google Cloudi konsoolis oma projekt, minge jaotisse „Avalda/Telli” ja looge uus teema ametliku „teema loomise” juhendi järgi. Tulemusel on nimi järgmises vormingus:

projects/{project_id}/topics/{topic_name}

See täisnimi tuleb teil märguannete aktiveerimisel Play Console'i ​​kleepida.

Tellimuse loomine

Selle teema sõnumite lugemiseks on vaja Pub/Sub tellimusSaate seda konfigureerida järgmiselt lükkama või nagu vedamaViitekoodilaboris töötame pull-tellimusega, kus teie taustsüsteem algatab sõnumite toomise päringud.

Peaksite üle vaatama Cloud Pub/Sub tellijate juhendi valikud, et otsustada, kas teie arhitektuurile sobib paremini push- või pull-tüüpi lähenemine. Kui olete otsuse teinud, järgige dokumentatsiooni „Lisa tellimus” ja linkige see varem loodud teemaga. Sellest hetkest alates on kõik Google Play poolt teemas avaldatud sõnumid teie tellijale kättesaadavad.

Google Play load teie teemas avaldamiseks

Pub/Sub ei luba Google Playl midagi avaldada, kui te pole selleks selgesõnalist luba andnud. teenusekontoGoogle Cloudi konsoolis peate minema teema õiguste seadetesse ja lisama peamise:

[email protected]

Anna sellele kontole roll Avaldaja/tellija (Väljaandja). Salvestage muudatused ja sellest hetkest alates saab Google Play teie teemale RTDN-e saata ilma autoriseerimisprobleemideta.

Aktiveeri RTDN Google Play Console'is

Kui Pub/Sub on seadistatud, pead Play Console'ile ütlema, kuhu märguanded saata. Google Play Console'i ​​rakenduses mine aadressile Monetiseeri Playga > Monetiseerimise seaded ja leidke reaalajas arendajate teavituste jaotis.

Seal on vaja:

• Märkige ruut, et lubada reaalajas teavitused.
• Sisesta vastavale väljale avaldamise/tellimise teema täielik nimi, järgides vormingut projects/{project_id}/topics/{topic_name}.
• Saatke testsõnum testnupu abil.

Testsõnum on oluline selle kontrollimiseks, et Integratsioon on hästi rakendatud.Kui teil on pull-tellimus, saate minna pilvekonsoolile, valida tellimuse, klõpsata nuppu „Kuva sõnumid” ja ekstraktida testsõnumi. Ärge unustage seda teha ack igast loetud sõnumist, et vältida korduvat vastuvõtmist.

Tõuketellimuste puhul veenduge, et teie lõpp-punkt saab teate ja vastab kehtiva HTTP-koodiga. Kui midagi läheb valesti, kuvab konsool testi avaldamisel vea, mis on tavaliselt seotud teema nime või teenusekonto õigustega.

Seotud artikkel:

Täielik juhend Google Play poe rakenduste prooviversioonidele registreerumiseks ning beetaversioonidele, varajasele juurdepääsule ja tasuta prooviversioonidele juurdepääsuks.

Lõpuks saate seadistada, milliseid teavitusi soovite saada: ainult tellimuste ja tühistatud ostude kohta või kõik teated, sh ühekordsed ostud (sündmused nagu ONE_TIME_PRODUCT_PURCHASED ja ONE_TIME_PRODUCT_CANCELED). Kui kasutate ka unikaalseid tooteid, on tavaline tavaks aktiveerida kogu komplekt, et säilitada kõige nähtavus.

Loo oma taustsüsteemis Pub/Sub tellija

Kui teema ja tellimus on valmis, on aeg see ellu viia abonent, kes loeb ja töötleb RTDN-eGoogle pakub näiteid mitmes keeles; tüüpiline juhtum Javas kasutab Cloud Pub/Sub klienditeegid käivitamiseks Subscriber kes kuulab sõnumeid ja helistab MessageReceiver.

Üldine muster on alati sama: sa saad sõnumi kätte, sa dekodeerid välja data Teisendate base64 tekstiks, parsite JSON-i ja ekstraheerite vastavad väljad (näiteks packageName, oneTimeProductNotification o subscriptionNotification) ja otsustage, mida oma süsteemis teha. Pärast teate edukat töötlemist peate Kinnitage sõnum kinnitusega et Pub/Sub seda uuesti ei saadaks.

Näidiskood näitab, kuidas vastuvõtja versiooni ja paketi nime välja prindib, aga reaalses rakenduses läheksite kaugemale: Sa kinnitaksid ostu, andes õiguse õigele kasutajaleSa uuendaksid oma andmebaasi ja vajadusel kutsuksid ostu tarbimiseks või tuvastamiseks Play Developer API-t.

Kasutajaga teavituste lingimine: obfuscatedAccountId kasutamine

Serverist ostude haldamisel on levinud probleem teadmine, millisele kasutajale konkreetne RTDN-teatis kuulub. Selleks võimaldab arvelduskliendi API teil lisada hägustatud konto identifikaator ostuprotsessi käivitamisel: obfuscatedAccountId.

Idee seisneb selles, et kasutate oma süsteemist stabiilset identifikaatorit (näiteks kasutaja sisemist ID-d), aga privaatsuse ja turvalisuse kaalutlustel hägustatudSee väärtus seostatakse ostuga ja kuvatakse seejärel Google Play arendaja API tagastatud teabes, nii et kui saate RTDN-i ja kontrollite tunnust, teate üheselt, millisele oma andmebaasi kontole peaksite õiguse andma.

Kliendi poolel, ettevalmistamisel BillingFlowParamsSa pead lihtsalt nimekirja koostama ProductDetailsParams ja helistage setObfuscatedAccountId(obfuscatedAccountId) enne voo käivitamist. See ei muuda nähtavat kasutajakogemust, kuid lihtsustab protsessi oluliselt. tagumise ostude jaotamise loogika ja aitab Google'il pettusi tuvastada.

Ostude kinnitamine Google Play arendaja API abil

Enne serverile õiguste andmist on kohustuslik kontrollida ostu õigsust, helistades Google Play arendaja APIKliendi või isegi RTDN-i öeldule lootmisest ei piisa: peate valideerima purchaseToken otse ametlike lõpp-punktide vastu ja vajadusel tagasimaksete haldamine.

Unikaalsete toodete puhul kasutate lõpp-punkti purchases.products:getTellimuste puhul viib tee läbi purchases.subscriptionsv2:getSoovitatav voolukiirus on:

• Väljavõte purchaseToken avaldamise/tellimise sõnumist.
• Kontrollige oma andmebaasi, et näha, kas olete selle juba töödelnud; iga märk on globaalselt ainulaadneSeega sobib see suurepäraselt primaarvõtmena duplikaatide vältimiseks.
• Kui see on uus, kutsuge Google Play arendaja API paketi, SKU ja purchaseToken.
• Veenduge, et vastus näitab ostu staatust OSTETUD (pole OOTEL ega tühistatud).
• Kui kõik sobib, registreerige token ja andke vastav õigus seotud kasutajale.

Java kaudu Play Developer API-ga suhtlemiseks saate kasutada AndroidPublisher, mis on initsialiseeritud JSON-vormingus teenusekonto mandaatidega. Teie konfigureerite ulatuse AndroidPublisherScopes.ANDROIDPUBLISHERSa lood kliendi ja kutsud välja meetodi purchases().products().get(...)Kui kõne ebaõnnestub ajutise võrgu- või teenuseprobleemi tõttu, on soovitatav rakendage uuesti proovimisi eksponentsiaalse tagasilükkamisega et üritusest mitte ilma jääda.

Kinnitage või viige ost serverist lõpule

Kui olete ostu kinnitanud ja süsteemis autoriseerinud, on järgmine samm Google'ile tehingu edukast töötlemisest teatamine. Ühekordsete toodete puhul on teil kaks võimalust: tarbida ostetud või lihtsalt tunne teda ära.

Tarbekaubad (nt virtuaalne valuuta, elud jne) peavad läbima lõpp-punkti purchases.products:consumeSee märgib žetooni kasutatuks ja võimaldab kasutajal sama eset konfliktideta uuesti osta. Mittetarbitavate toodete (näiteks premium-versiooni eluaegseks avamiseks) puhul peate helistama purchases.products:acknowledge, mis teavitab Google'it, et kasutajal on juba vastav õigus olemas.

Tellimusi kasutatakse purchases.subscriptions:acknowledgemis näitab, et tellimus on edukalt töödeldud ja kasutajale määratud. Kui te ostu mõistliku aja jooksul ei kinnita, võib Google eeldada probleemi ja tehingu tagasi võtta, seega on oluline, et te tagasipöördumine toimub kohe pärast õiguse andmist.

Oma AndroidPublisheri abimehes saate lisada meetodeid, näiteks executeProductPurchasesConsume y executeProductPurchasesAcknowledge mis kutsuvad vastavaid lõpp-punkte. Jällegi on soovitatav juhuslike tõrgete korral rakendada uuesti katseid, et tagada, et ükski märk ei jääks ohtlikku vahepealsesse olekusse.

Täiustatud testimine Play Billing Labiga

Üks aspekt, mida paljud arendajad alahindavad, on testimise etapp. Mingil määral enesekindlalt käivitamiseks peate suutma simuleerida võrguvead, mittestandardsed vastused ja äärejuhtumidSiin tulebki mängu Play Billing Lab – Google Plays saadaval olev tasuta rakendus, mis on loodud spetsiaalselt Play Billing Library integratsioonide testimiseks.

Play arvelduslabor sisaldab järgmist vastuste simulaator mis võimaldab sundida erinevaid BillingResponseCode teie rakenduse kõnedes arveldusteegile. Nii saate luua stsenaariume, kus näiteks klient ei saa võrguprobleemi tõttu ostu sooritada, kuid teie taustsüsteem töötleb RTDN-i õigesti ja annab lõpuks õiguse ilma kasutaja sekkumiseta.

Selleks, et teie rakendus simulaatoriga suhtleks, peate metaandmete abil lubama arvelduse tühistamise testimise. AndroidManifest.xml:

<manifest ... >
  <application ... >
    ...
    <meta-data
        android:name="com.google.android.play.largest_release_audience.NONPRODUCTION"
        android:value="" />
    <meta-data
        android:name="com.google.android.play.billingclient.enableBillingOverridesTesting"
        android:value="true" />
  </application>
</manifest>

Silt enableBillingOverridesTestimine Aktiveeri arveldusteegis simuleeritud vastusetestid. Silt NONPRODUCTION on omamoodi meeldetuletus, et seda versiooni ei tohiks aktiivsete ülekirjutustega tootmiskeskkonda minna. Lõpliku versiooni kasutajatele ettevalmistamisel veendu kindlasti, et Eemaldage see metaandmed või kasutage eraldi manifesti.

Kui see on konfigureeritud, logige Play Billing Labi rakenduses sisse litsentsi testija kontoga, aktiveerige valik „Simule Play Billing Library response” ja valige iga API jaoks tagastatavad veakoodid (näiteks konkreetne viga consumeAsyncSeejärel avage lihtsalt oma rakendus ja käivitage voog, mida soovite testida: simulaator tagastab konfigureeritud vastused ja saate kontrollida, kas teie uuesti proovimise loogika, veakäsitlus ja RTDN toimivad ootuspäraselt.

Peamised API muudatused Play arvelduskogu 7-le üleminekul

Lisaks RTDN-ile ja testimisele hõlmab PBL 7-le üleminek ka mõne spetsiifilise API-punkti lahendamist. PBL 5-lt või 6-lt tulijatel tasub üle vaadata kõige olulisemad muudatused, et tagada projekti sujuv kompileerimine ja äriloogika järjepidevus.

Esiteks API-d, mis on seotud Proportsionaalne režiim Tellimuse muutmise valikud on eemaldatud. Nüüd kasutatakse järgmist: Asendusrežiim plaanimuudatuste (täiendamised, alandamised jne) haldamiseks. Kui kasutate endiselt selliseid meetodeid nagu setReplaceProrationMode o setReplaceSkusProrationModePeate need uutele variantidele üle viima setSubscriptionReplacementMode ja kohandage loogikat vastavalt ajakohastatud dokumentatsioonile.

API on samuti eemaldatud. launchPriceConfirmationFlowmis oli juba märgitud aegunuks. Tellimuse hinnamuudatustega tegelemiseks peaksite tutvuma hinnamuudatuste juhendi uute töövoogude ja soovitustega, kus on üksikasjalikult kirjeldatud, kuidas kasutajat õigesti teavitada ja kuidas nõusolekut hallata.

Teine oluline punkt on Alternatiivsed arveldusliidesedMeetodid BillingClient.Builder.enableAlternativeBilling, AlternativeBillingListener y AlternativeChoiceDetails on kadunud ühtlasema nomenklatuuri kasuks: nüüd peate kasutama BillingClient.Builder.enableUserChoiceBilling() kõrval UserChoiceBillingListener y UserChoiceDetailsGoogle'i enda sõnul on tegemist põhimõtteliselt nimevahetusega ilma käitumise muutusteta, kontekstis, mida iseloomustavad sellised kokkulepped nagu Google ja Epic Games lepivad kokku Androidi avamise.

Lõpuks sisestatakse uus veakood. VÕRGU_VIGA en BillingResultja tähendused ja tingimused SERVICE_TIMEOUT ja SERVICE_UNAVAILABLEKui teil on kohandatud veakäsitlusloogika (näiteks otsustate, millal kasutajale teadet kuvada, millal vaikselt uuesti proovida jne), on soovitatav see üle vaadata, et neid uusi nüansse arvesse võtta.

Ootel tehingud ja tellimuse ID puudumine kuni ostuni

PBL 7 väike muudatus on see, et teek ei genereeri enam Ootel ostude tellimuse ID. Nendel juhtudel on orderId See on saadaval alles siis, kui ost jõuab olekusse OSTETUD. See mõjutab eriti töövooge, kus tellimuse ID-d kasutati algusest peale peamise viitena.

Google'i soovitus on, et te toetuksite sellele purchaseToken teie arhiivi ja leppimiste jaoksvähemalt seni, kuni tehing on ootel. Kui leiate ostu, mis on Playst kadunud, kontrollige Mida teha, kui ost kaob ära.

Kui te pole veel tasumata saldodega tegelenud, vaadake üle arveldusteegi integreerimise juhend ja dokumentatsioon aadressil hanke elutsükli haldamineSealt leiad erinevad olekud, kuidas igaühele reageerida ja kuidas RTDN-id sellesse puslesse sobituvad.

PBL 7 uued valikulised võimalused: virtuaalsed osamaksed ja ettemaksed

PBL 7 "toredate" uute funktsioonide hulka kuuluvad virtuaalsed tasulised tellimused (virtuaalsed osamaksetega tellimused) ja laiendatud tugi ettemakstud tellimuste ootel ostudele. Need funktsioonid ei ole kohustuslikud, kuid need võivad anda teile suurema paindlikkuse oma ärimudeli kohandamisel erinevatele turgudele.

Virtuaalsed osamaksed võimaldavad kasutajal maksta pikemaajalise tellimuse eest väikesed perioodilised maksedGoogle selgitab, et arendajate arvelduse eesmärgil saate ühekordse suure makse asemel jätkuvalt igakuiseid makseid aastase plaani alusel, kus igakuised osamaksed tehakse. Kui kasutaja jätab makse tegemata, ei tohiks teie ega Google proovida varasemaid osamakseid sisse nõuda. See muudab selle praktilise kasutamise üsna sarnaseks tavalise kuutellimusega, vähemalt esialgu.

Praegu on need tellimustasud saadaval ainult järgmistes riikides: Brasiilia, Prantsusmaa, Itaalia ja HispaaniaGoogle soovitab Play Console'il silma peal hoida, et näha, kas riike on äsja toetatud. Konfiguratsioon toimub järgmise kaudu: ProductDetails.InstallmentPlanDetails ja järgides konkreetset juhendit nende integreerimiseks oma rakendusse.

Paralleelselt laiendatakse tuge ettemakstud tellimuste ootel olevad ostudNüüd saate pakkuda mudeleid, kus kasutaja alustab ostu rakenduses ja viib makse hiljem lõpule muul viisil ning arveldusteek teab, kuidas seda voogu õigesti käsitleda. Aktiveerimine toimub kutsudes enablePendingPurchases() BillingClienti initsialiseerimisel ja eriti ettemaksuga pakettide puhul PendingPurchasesParams.Builder.enablePrepaidPlans().

Play arveldusteegi 5 ja 6 amortisatsiooniperioodid

PBL 7 tulekuga on Google seadnud selged kuupäevad versioonide 5 ja 6 toe lõpetamineKui olete endiselt mõnes neist, peate kalendri punasega märkima:

• Google Play arvelduskogu 5 tugi uutele rakendustele ja värskendustele lõpetatakse ametlikult 31. augustil 2024. Pikendust on võimalik taotleda kuni 1. novembrini 2024, kuid sellele ei tohiks pikas perspektiivis loota.
• Google Play arvelduskogu 6 saab uute rakenduste avaldamiseks kasutada kuni 1. augustini 2025 ja olemasolevate rakenduste värskendamiseks kuni 1. novembrini 2025.

Pärast seda kuupäeva, kui te pole veel vähemalt versioonile 6 või ideaaljuhul versioonile 7 üle läinud, peate värskendama uusimale versioonile. versioon 7Play Console'is blokeeritakse värskendused. Kuigi teie rakendus töötab kasutajate seadmetes edasi, on see hangunud ega saa vigu parandada ega uusi funktsioone lisada, mis sõltuvad poes avaldamisest.

.NET MAUI juhtum ja praegused piirangud

Kui töötate Androidis .NET MAUI ja tellimustega, olete ilmselt juba lugenud või kogenud, et see pole nii lihtne. Paljudes projektides kasutati Plugin.InAppBilling James Montemagno poolt, kuid plugin on arhiveeritud ja hooldamata, seega seda ei värskendata Billing Library 7 toetamiseks. Samal ajal ametlik pakett Xamarin.Android.Google.BillingClient See on jäänud Xamarin.Androidi ökosüsteemi külge ankurdatuks ega ole otseselt ühilduv .NET MAUI-ga.

Praktiline tagajärg on see, et Play Console hoiatab Teie rakendus ei kasuta arveldusteegi versiooni 7.0.0 või uuemat, mis blokeerib värskendused, kui jätkate vanemate teekide kasutamist. Mõned arendajad on valinud drastilisi lahendusi, näiteks tellimuste ajutise keelamise versiooni üleslaadimiseks, kuid ilmselgelt pole see jätkusuutlik, kui teie ärimudel sõltub sellest monetiseerimisest.

Selles kontekstis kaaluvad paljud meeskonnad alternatiive, näiteks Kolmanda osapoole SDK-d Need teenused toetavad juba PBL 7-t ja pakuvad stabiilsemat platvormideülest API-t (näiteks tellimuspõhised taustlahendused SDK-dega Androidile, iOS-ile ja teistele platvormidele). Need teenused tegelevad tavaliselt arveldusteegi versioonide migreerimisega ja pakuvad stabiilset ümbrist, vähendades oluliselt stressi iga uue Google'i toe aegumisega.

Kuni Microsoft ja MAUI meeskond pakuvad Ametlik pakett on uuendatud ja täielikult ühilduv Billing Library 7 puhul on valikuteks: oma sidumine algupärase Billing Libraryga, kolmanda osapoole teenuse kasutamine või ostude MAUI-projekti integreerimise ümbermõtestamine. Igal juhul on parem mitte jätta otsust viimasele minutile, sest Play tähtajad on fikseeritud.

Seotud artikkel:

Kuidas samm-sammult Google Plays ostude eest tagasimakset taotleda

Üldiselt hõlmab Google Play arveldusteegi v7 värskendus sõltuvuste ülevaatamist, vananenud API-de puhastamist, taustloogika tugevdamist ostude kinnitamise ja RTDN-iga ning testimistööriistade (nt Play Billing Lab) kasutamist kõigi vigade avastamiseks enne avaldamist. Need, kes võtavad aega selle migratsiooni täpsustamiseks, saavad paremini hakkama ettemakstud pakettide, virtuaalsete tasude, võrguvigade ja tellimuste elutsükli muudatustega ning neil on palju suurem võimalus säilitada Google Plays stabiilne tulu ja laitmatu kasutajakogemus. Jaga infot, et rohkem kasutajaid saaksid teema kohta rohkem teada.