Sjongler innkjøp i app fra flere markeder

Innkjøp i appen gir iOS, Windows 8 og Android-utviklere flere måter å tjene inntekter på apper. For Android-utviklere er det en ekstra komplikasjon når du bringer apper til nye appbutikker: innkjøpsfunksjonene i appen (IAP) må endres.

Hvorfor det ikke er en universell faktureringsløsning

Denne komplikasjonen eksisterer fordi de fleste kjøpemuligheter i appen bare kan brukes til ett marked. For eksempel kan ikke Google Play InAB-fakturering (IAB) -biblioteket brukes i Amazon Appstore (og heller ikke Amazon Appstore IAP-biblioteket kan brukes på Google Play). Selv plattformagnostiske faktureringssystemer som PayPal er problematiske, fordi de store Android-app-butikkene alle har en bestemmelse i avtalevilkårene som forbyr denne praksisen.

Andre betalingsløsninger er fremdeles tillatt for andre kjøp, for eksempel å bestille fysiske varer. Poenget med striden og noen ganger forvirring er når utviklere og alternative betalingssystemer prøver å kutte app-butikken ut av loopen og deres 30% -andel av kjøpet i appen. Som alltid foreslår jeg ikke å spille på ikke å bli fanget; Jeg bygger apper på lang sikt, ikke for en rask pengegruppe.

Å bygge en universell løsning ville være en vanskelig oppgave, fordi økosystemet for Android-appbutikken utvikler seg kontinuerlig, med nye appmarkeder dukker opp og forsvinner kontinuerlig. Dette etterlater oss et problem: å distribuere en app til flere appbutikker krever flere kjøpsløsninger i appen.

Tredjepartsalternativer

Det kan være fristende å henvende seg til en tredjepart for å få en faktureringstjeneste med flere plattformer, og det er alternativer for tjenester som håndterer faktureringsdetaljer for plattformen for deg. Det er også alternativer med åpen kildekode for å forenkle grensesnittet for Google Play-fakturering, noe som kan garantere oppmerksomhet når du bygger en ny IAP-løsning.

Problemet med å bruke en tredjeparts faktureringsløsning (minst så langt som de jeg har sett) er at de tar et kutt i inntekten, men ikke gir meg tilgang til andre markeder som jeg trenger. De kan håndtere Google og Amazon, men vil ikke håndtere Samsung eller andre markeder jeg kanskje vil undersøke. Inntil en slik tjeneste allerede støtter faktureringsplattformene jeg trenger når jeg ser på den, vil de ikke være det riktige valget for meg.

Mangelen på fleksibilitet er deal-breaker for meg. Jeg undersøker og engasjerer mange forskjellige Android-appmarkeder, og en delvis løsning vil være mer skadelig enn nyttig.

Vedlikehold din egen fleksible løsning

Min nåværende løsning på dette er en hybridversjon av appen min som kan håndtere Google Play og Amazon fakturering. Jeg styrer hvilken kode som aktiveres ved hjelp av et flagg på kompileringstidspunktet. Jeg har ikke tatt med Samsung ennå fordi tilleggstillatelsene garanterer å opprette et eget prosjekt for å holde rettighetene korrekte for andre plattformer.

Siden jeg bruker AndroidMarketManager-biblioteket for å sikre at app-koblingene mine til riktig app-butikk, er mekanismen allerede på plass for å utføre passende tiltak basert på det valgte appmarkedet. En enkel velger kunne se slik ut:

 if (AppConstants.MARKET_SELECTOR  == AMMConstants.MARKET_SELECTOR_GOOGLE) {  siste lang tid = ny dato (). getTime ();  final boolean requestSuccess = getBillingService (). requestPurchase (AppConstants.GOOGLE_PURCHASE_ID,  BillingConstants.ITEM_TYPE_INAPP,  String.valueOf (tid));  } annet hvis (AppConstants.MARKET_SELECTOR  == AMMConstants.MARKET_SELECTOR_AMAZON) {  final String requestId = PurchasingManager  .initiatePurchaseRequest (AppConstants.AMZ_PURCHASE_ID);  } 

Den viktigste plattformspesifikke koden ligger i PurchaseObserver-klassene (Amazon og Google bruker en lignende konstruksjon). Observer-klassen samhandler med varslene om vellykkede kjøp, samt refusjon og kansellering.

Dette er ikke en ett-trinns integrasjon - bortsett fra markedskoden for kjeleplaten (som Amazon gir, men Google bare gir deg et eksempel på), er det noen få ekstra integrasjonspunkter der jeg må beskytte Amazon- eller Google- spesifikk kode og bare kjør den riktige. Sluttresultatet er at mye av faktureringsrelatert kode - for eksempel logikk for å administrere kjøpte varer og levere informasjonen til resten av appen - er plattformagnostisk; Dette vil forenkle: vedlikehold, legge til nye IAP-plattformer og gjenbruke denne koden for fremtidige apper.

Gjør-ingenting-alternativet

Hvis de andre alternativene ikke virker verdt å bruke, kan du alltid unngå å kjøpe apper utenfor Google Play. Imidlertid tror jeg at du ville savnet inntekter hvis du tar den ruten. Jeg har sett bedre resultater med Amazon IAP enn fra Google Play ( figur A ) så langt. Figur A

Hva er riktig for appen din?

Du har flere alternativer for å håndtere fakturering i app for flere appmarkeder: bygg din egen, bruk en tjeneste eller unngå kjøp i appen på andre appmarkeder. Hver utvikler har forskjellige behov og forskjellige ressursnivåer tilgjengelig for å takle dette problemet.

Jeg foreslår at du balanserer potensielle inntekter med fremtidige vedlikeholdskostnader og gebyrer for å finne den rette løsningen for appen din. Å implementere kjøp i app for flere Android-app-butikker kan øke fortjenesten din hvis du kan holde implementeringskostnadene rimelige.

© Copyright 2021 | pepebotifarra.com