Summary
Yıllık I/O konferansı sırasında Google, Google Play Faturalandırma Kitaplığı’nın yeni ana sürümünü tanıttı. Buna ek olarak klasik yöntemler ve silme işlemlerinin yanı sıra uygulama içi satın alma işlemlerini oluşturma, yönetme ve satma yönteminizi basitleştirmeyi amaçlayan yeni abonelik mimarisi hakkında da geniş bilgiler verdi. Bu yazıda, Google Play Faturalandırma Kitaplığı 5.0’a ait güncellemeleri inceleyecek ve en ilginç olanlarını derinlemesine inceleyeceğim.
Yeni Abonelik Modeli
Yeni Abonelik Satın Alma
Kodla ilgili bir diğer konu, Google Play Faturlandırma Kitaplığı 5.0’da SkuDetails sınıfı ve Sku içeren diğer tüm varlıklar veya yöntemler kullanımdan kaldırılmıştır. Bu yüzden artık bu amaç için ProductDetails kullanmayı düşünebilirsiniz. Ürün detayları, temel planlar ve teklifler de dahil olmak üzere abonelikle ilgili birçok bilgiyi içerir.
Önceden aşağıdaki gibi abonelik detayları isteği yapıyordunuz:
val params = SkuDetailsParams.newBuilder() .setType(BillingClient.SkuType.SUBS) .setSkusList(listOf("premium")) .build() billingClient.querySkuDetailsAsync(params) { billingResult, skuDetailsList -> // Process the result } Copy
Artık şu şekilde yapmalısınız:
val productList = listOf( QueryProductDetailsParams.Product.newBuilder() .setProductType(BillingClient.SkuType.SUBS) .setProductId("premium") .build() ) val params = QueryProductDetailsParams.newBuilder() .setProductList(productList) .build() billingClient.queryProductDetailsAsync(params) { billingResult, productDetailsList -> // Process the result }Copy
Ve satın alma akışını başlatmak için aşağıdaki yapıları kullanıyordunuz:
val billingFlowParams = BillingFlowParams.newBuilder() .setSkuDetails(skuDetails) .build() val billingResult = billingClient.launchBillingFlow(activity, billingFlowParams)Copy
Ama artık aşağıdaki gibi görünecek:
// Note that `subscriptionOfferDetails` can be null if it is an in-app product, not a subscription. val offerToken = productDetails.subscriptionOfferDetails?.get(selectedOfferIndex)?.offerToken ?: return val productDetailsParamsList = listOf( BillingFlowParams.ProductDetailsParams.newBuilder() .setProductDetails(productDetails) .setOfferToken(offerToken) .build() ) val billingFlowParams = BillingFlowParams.newBuilder() .setProductDetailsParamsList(productDetailsParamsList) val billingResult = billingClient.launchBillingFlow(activity, billingFlowParams) Copy
Ayrıca Google Migration adımlarındaki geçiş örneklerine de göz atabilirsiniz. Şunu unutmayın ki bu örneklerde birkaç harf hatası bulunuyor ve bu hatalar burada düzeltiliyor.
Hadi gelin değişikliklere bir göz atalım.
Daha önceden de bahsettiğim gibi abonelik detaylarını ve satın alma akışını sorgulamak için artık ProductDetails kullanabilirsiniz. Ayrıca her bir ProductDetails içinde birkaç teklif bulunabileceğinden dolayı faturalandırma akışı parametrelerine bir offerToken sağlamalısınız. Teklif detayları dizisinin (productDetails.subscriptionOfferDetails) her zaman temel plan detaylarını içerdiğini (herhangi bir temel plan varsa) unutmayın; bu sebeple aboneliğiniz yalnızca teklifleri olmayan bir temel plan içeriyor olsa bile satın alma için hala offerToken sahibi olacaklardır.
Yeni satın alma akışının önceki sürümde olduğu gibi SkuDetails yerine birden fazla ProductDetails kabul ettiğini siz de fark edebilirsiniz. Ancak birden fazla ProductDetails sağlarsanız akış hata verebilir. Resmi entegrasyon rehberi setProductDetails ve setOfferToken yöntemlerini, BillingFlowParams. Builder sınıfı üzerinde kullanırken yanlış bir örnek verir fakat bu amaçlar için mevcut yöntem yalnızca setProductDetailsParamsList’dir. Görünüşe göre Google, Faturalandırmanın aynı anda birden fazla farklı abonelik satın alımını destekleyeceği bir gelecek vizyonuyla son zamanlarda tek ürün ayrıntısından birden fazla ürün ayrıntısına geçmeye karar vermiş.
Geri kalan akış — yani satın alma işlemi — Google Play Faturalandırma Kitaplığı 4.0’daki ile aynı kalır.
Aboneliklerin Geriye Dönük Uyumluluğu
Şimdilik her şey yolunda görünüyor fakat eğer ya şimdi geçiş yapmak istemiyorsanız? Google bunu da düşündü.
Google Play Konsolu zaten yalnızca yeni abonelik modeliyle çalışıyor olsa da tüm eski abonelikler otomatik olarak yeni aboneliklere dönüştürülecek ve geriye dönük uyumlulukları da kaydediliyor. Yani, aboneliklerinizi Google Konsolunda yeni formatta gördüğünüz ancak uygulamada daha önce yaptığınız gibi yine de onlarla çalışabileceksiniz.
Ayrıca, tüm eski aboneliklerin geçişten sonra salt okunur hale getirildiğini de göreceksiniz. Google, düzenlemenin söz konusu olduğu abonelikler için InAppProducts API desteğini devre dışı bırakacağı konusunda sizi uyarmakta.
Bazı ürün detaylarını görmek için bu API’yı arka planda kullanıyor olabilirsiniz, bu nedenle dikkatli olun — aboneliği düzenlenebilir hale getirdikten sonra, dönüştürülmüş abonelik bilgilerini almaya çalışırsanız bu API’dan hata (aşağıda gösterildiği gibi) alacaksınız. Aynı durum 11 Mayıs’tan sonra oluşturulan tüm yeni abonelikler için de geçerli olacaktır.
HTTP code - 422 Non-existent in-app product: com.qonversion.sample\/ProductId{productId=article_test_trial}Copy
Bu nedenle, InAppProducts API kullanıyorsanız yeni abonelik oluşturmadan veya eski abonelikleri düzenlemeden önce yükseltmeyi düşünün.
Google Play Console’daki yeni abonelikler arayüzünde gezinirken temel planların ve abonelik tekliflerinin yanında “Geriye dönük uyumlu” gibi etiketler bulacaksınız. Yani, bu abonelikleri kullanımdan kaldırılmış SkuDetails ile satın alırsanız (Tıpkı Google Play Faturalandırma Kitaplığı 4.0’da olduğu gibi) kelimenin tam anlamıyla bu uyumlu temel planları/teklifleri satın alacaksınız. Eğer hiçbir uyumluluk teklifine sahip olmayan bir uyumlu temel plan varsa o halde o temel plan satın alınacaktır. Hem uyumlu temel plan hem de teklif mevcutsa, teklif mevcut kullanıcı için uygunsa, satın alınacaktır, aksi takdirde — temel plan satın alınacaktır. İsterseniz geriye dönük uyumlu olarak başka bir temel plan/teklif seçebilirsiniz.
Not — bu Geriye dönük uyumluluk Google Play Faturalandırma Kitaplığı ile alakalıdır ve ayrıca InAppProducts API ile ilgili değildir. Önceden de belirtildiği üzere örneğin bir abonelik için birden fazla temel plan veya teklif gibi yeni özellikler kullanmaya başlarsanız ya da yalnızca salt okunurdan düzenlenebilir hale dönüştürürseniz, bu abonelik yine de uygulama için Geriye dönük olarak uyumlu olabilir, ancak API için uyumlu olmayabilir.
Diğer Güncellemeler
Google Play Faturalandırma Kitaplığı 5.0’da özet olarak bahsetmeye değer birkaç küçük güncelleme bulunuyor.
Google Play Faturlandırma Kitaplığı 4.0’da kullanımdan kaldırılan
queryPurchasesyöntemi de kaldırıldıArtık senkronize istekler yok, sadece
queryPurchasesAsync.launchPriceChangeFlowkullanımdan kaldırıldı — yeni tavsiye edilen fiyat değişimi akışı müşterinin Google Play abonelikleri sayfası aracılığıyla onayını gerektiriyor ve bu yüzden de BillingClient yöntemini kullanmak yerine gezinti için Derin Link (Deep Link) kullanmanız gerekiyor.Tüketici Hakları Yönetmeliği uyarınca AB kullanıcıları için kişiselleştirilmiş bir fiyat sunmak adına
setIsOfferPersonalizedyöntemi eklendi. Bu seçenek, Google Faturalandırma satın alma ekranının altına bir satır ekleyerek fiyatın kişiselleştirildiğini belirtir.
Yeni Abonelik Modeli ve Qonversion
Google Play Faturalandırma Kitaplığı 5.0 desteği üzerinde çalışırken, uygulama içi satın alımlarınızda Qonversion SDK’yı kullanabilirsiniz. Artık Google Play Faturalandırma Kitaplığı 4.0’ı kullanıyoruz, bu da yalnızca geriye dönük uyumlu temel planlar ve tekliflerle abonelikleri yönetebileceğimiz anlamına geliyor. Önceki abonelik modelinde bulunan bir fiyat, ödemesiz dönem, deneme süresi vb. özellikleri hala düzenleyebilir ve yeni abonelikler oluşturabilirsiniz. Endişelenmeyin, geriye dönük uyumlu en az bir temel planınız ve gerekirse geriye dönük uyumlu bir teklifiniz olacak. Ve yine de, temel plan veya teklif tanımlayıcıları değil, Ürün Merkezimizdeki ürünleri yapılandırmak için tam bir abonelik tanımlayıcısına ihtiyacımız bulunuyor.
Eğer herhangi bir sorunuz varsa, lütfen bize bildirin. Size yardımcı olmaktan mutluluk duyarız.
Yıllık I/O konferansı sırasında Google, Google Play Faturalandırma Kitaplığı’nın yeni ana sürümünü tanıttı. Buna ek olarak klasik yöntemler ve silme işlemlerinin yanı sıra uygulama içi satın alma işlemlerini oluşturma, yönetme ve satma yönteminizi basitleştirmeyi amaçlayan yeni abonelik mimarisi hakkında da geniş bilgiler verdi. Bu yazıda, Google Play Faturalandırma Kitaplığı 5.0’a ait güncellemeleri inceleyecek ve en ilginç olanlarını derinlemesine inceleyeceğim.
Yeni Abonelik Modeli
Yeni Abonelik Satın Alma
Kodla ilgili bir diğer konu, Google Play Faturlandırma Kitaplığı 5.0’da SkuDetails sınıfı ve Sku içeren diğer tüm varlıklar veya yöntemler kullanımdan kaldırılmıştır. Bu yüzden artık bu amaç için ProductDetails kullanmayı düşünebilirsiniz. Ürün detayları, temel planlar ve teklifler de dahil olmak üzere abonelikle ilgili birçok bilgiyi içerir.
Önceden aşağıdaki gibi abonelik detayları isteği yapıyordunuz:
val params = SkuDetailsParams.newBuilder() .setType(BillingClient.SkuType.SUBS) .setSkusList(listOf("premium")) .build() billingClient.querySkuDetailsAsync(params) { billingResult, skuDetailsList -> // Process the result } Copy
Artık şu şekilde yapmalısınız:
val productList = listOf( QueryProductDetailsParams.Product.newBuilder() .setProductType(BillingClient.SkuType.SUBS) .setProductId("premium") .build() ) val params = QueryProductDetailsParams.newBuilder() .setProductList(productList) .build() billingClient.queryProductDetailsAsync(params) { billingResult, productDetailsList -> // Process the result }Copy
Ve satın alma akışını başlatmak için aşağıdaki yapıları kullanıyordunuz:
val billingFlowParams = BillingFlowParams.newBuilder() .setSkuDetails(skuDetails) .build() val billingResult = billingClient.launchBillingFlow(activity, billingFlowParams)Copy
Ama artık aşağıdaki gibi görünecek:
// Note that `subscriptionOfferDetails` can be null if it is an in-app product, not a subscription. val offerToken = productDetails.subscriptionOfferDetails?.get(selectedOfferIndex)?.offerToken ?: return val productDetailsParamsList = listOf( BillingFlowParams.ProductDetailsParams.newBuilder() .setProductDetails(productDetails) .setOfferToken(offerToken) .build() ) val billingFlowParams = BillingFlowParams.newBuilder() .setProductDetailsParamsList(productDetailsParamsList) val billingResult = billingClient.launchBillingFlow(activity, billingFlowParams) Copy
Ayrıca Google Migration adımlarındaki geçiş örneklerine de göz atabilirsiniz. Şunu unutmayın ki bu örneklerde birkaç harf hatası bulunuyor ve bu hatalar burada düzeltiliyor.
Hadi gelin değişikliklere bir göz atalım.
Daha önceden de bahsettiğim gibi abonelik detaylarını ve satın alma akışını sorgulamak için artık ProductDetails kullanabilirsiniz. Ayrıca her bir ProductDetails içinde birkaç teklif bulunabileceğinden dolayı faturalandırma akışı parametrelerine bir offerToken sağlamalısınız. Teklif detayları dizisinin (productDetails.subscriptionOfferDetails) her zaman temel plan detaylarını içerdiğini (herhangi bir temel plan varsa) unutmayın; bu sebeple aboneliğiniz yalnızca teklifleri olmayan bir temel plan içeriyor olsa bile satın alma için hala offerToken sahibi olacaklardır.
Yeni satın alma akışının önceki sürümde olduğu gibi SkuDetails yerine birden fazla ProductDetails kabul ettiğini siz de fark edebilirsiniz. Ancak birden fazla ProductDetails sağlarsanız akış hata verebilir. Resmi entegrasyon rehberi setProductDetails ve setOfferToken yöntemlerini, BillingFlowParams. Builder sınıfı üzerinde kullanırken yanlış bir örnek verir fakat bu amaçlar için mevcut yöntem yalnızca setProductDetailsParamsList’dir. Görünüşe göre Google, Faturalandırmanın aynı anda birden fazla farklı abonelik satın alımını destekleyeceği bir gelecek vizyonuyla son zamanlarda tek ürün ayrıntısından birden fazla ürün ayrıntısına geçmeye karar vermiş.
Geri kalan akış — yani satın alma işlemi — Google Play Faturalandırma Kitaplığı 4.0’daki ile aynı kalır.
Aboneliklerin Geriye Dönük Uyumluluğu
Şimdilik her şey yolunda görünüyor fakat eğer ya şimdi geçiş yapmak istemiyorsanız? Google bunu da düşündü.
Google Play Konsolu zaten yalnızca yeni abonelik modeliyle çalışıyor olsa da tüm eski abonelikler otomatik olarak yeni aboneliklere dönüştürülecek ve geriye dönük uyumlulukları da kaydediliyor. Yani, aboneliklerinizi Google Konsolunda yeni formatta gördüğünüz ancak uygulamada daha önce yaptığınız gibi yine de onlarla çalışabileceksiniz.
Ayrıca, tüm eski aboneliklerin geçişten sonra salt okunur hale getirildiğini de göreceksiniz. Google, düzenlemenin söz konusu olduğu abonelikler için InAppProducts API desteğini devre dışı bırakacağı konusunda sizi uyarmakta.
Bazı ürün detaylarını görmek için bu API’yı arka planda kullanıyor olabilirsiniz, bu nedenle dikkatli olun — aboneliği düzenlenebilir hale getirdikten sonra, dönüştürülmüş abonelik bilgilerini almaya çalışırsanız bu API’dan hata (aşağıda gösterildiği gibi) alacaksınız. Aynı durum 11 Mayıs’tan sonra oluşturulan tüm yeni abonelikler için de geçerli olacaktır.
HTTP code - 422 Non-existent in-app product: com.qonversion.sample\/ProductId{productId=article_test_trial}Copy
Bu nedenle, InAppProducts API kullanıyorsanız yeni abonelik oluşturmadan veya eski abonelikleri düzenlemeden önce yükseltmeyi düşünün.
Google Play Console’daki yeni abonelikler arayüzünde gezinirken temel planların ve abonelik tekliflerinin yanında “Geriye dönük uyumlu” gibi etiketler bulacaksınız. Yani, bu abonelikleri kullanımdan kaldırılmış SkuDetails ile satın alırsanız (Tıpkı Google Play Faturalandırma Kitaplığı 4.0’da olduğu gibi) kelimenin tam anlamıyla bu uyumlu temel planları/teklifleri satın alacaksınız. Eğer hiçbir uyumluluk teklifine sahip olmayan bir uyumlu temel plan varsa o halde o temel plan satın alınacaktır. Hem uyumlu temel plan hem de teklif mevcutsa, teklif mevcut kullanıcı için uygunsa, satın alınacaktır, aksi takdirde — temel plan satın alınacaktır. İsterseniz geriye dönük uyumlu olarak başka bir temel plan/teklif seçebilirsiniz.
Not — bu Geriye dönük uyumluluk Google Play Faturalandırma Kitaplığı ile alakalıdır ve ayrıca InAppProducts API ile ilgili değildir. Önceden de belirtildiği üzere örneğin bir abonelik için birden fazla temel plan veya teklif gibi yeni özellikler kullanmaya başlarsanız ya da yalnızca salt okunurdan düzenlenebilir hale dönüştürürseniz, bu abonelik yine de uygulama için Geriye dönük olarak uyumlu olabilir, ancak API için uyumlu olmayabilir.
Diğer Güncellemeler
Google Play Faturalandırma Kitaplığı 5.0’da özet olarak bahsetmeye değer birkaç küçük güncelleme bulunuyor.
Google Play Faturlandırma Kitaplığı 4.0’da kullanımdan kaldırılan
queryPurchasesyöntemi de kaldırıldıArtık senkronize istekler yok, sadece
queryPurchasesAsync.launchPriceChangeFlowkullanımdan kaldırıldı — yeni tavsiye edilen fiyat değişimi akışı müşterinin Google Play abonelikleri sayfası aracılığıyla onayını gerektiriyor ve bu yüzden de BillingClient yöntemini kullanmak yerine gezinti için Derin Link (Deep Link) kullanmanız gerekiyor.Tüketici Hakları Yönetmeliği uyarınca AB kullanıcıları için kişiselleştirilmiş bir fiyat sunmak adına
setIsOfferPersonalizedyöntemi eklendi. Bu seçenek, Google Faturalandırma satın alma ekranının altına bir satır ekleyerek fiyatın kişiselleştirildiğini belirtir.
Yeni Abonelik Modeli ve Qonversion
Google Play Faturalandırma Kitaplığı 5.0 desteği üzerinde çalışırken, uygulama içi satın alımlarınızda Qonversion SDK’yı kullanabilirsiniz. Artık Google Play Faturalandırma Kitaplığı 4.0’ı kullanıyoruz, bu da yalnızca geriye dönük uyumlu temel planlar ve tekliflerle abonelikleri yönetebileceğimiz anlamına geliyor. Önceki abonelik modelinde bulunan bir fiyat, ödemesiz dönem, deneme süresi vb. özellikleri hala düzenleyebilir ve yeni abonelikler oluşturabilirsiniz. Endişelenmeyin, geriye dönük uyumlu en az bir temel planınız ve gerekirse geriye dönük uyumlu bir teklifiniz olacak. Ve yine de, temel plan veya teklif tanımlayıcıları değil, Ürün Merkezimizdeki ürünleri yapılandırmak için tam bir abonelik tanımlayıcısına ihtiyacımız bulunuyor.
Eğer herhangi bir sorunuz varsa, lütfen bize bildirin. Size yardımcı olmaktan mutluluk duyarız.
Yıllık I/O konferansı sırasında Google, Google Play Faturalandırma Kitaplığı’nın yeni ana sürümünü tanıttı. Buna ek olarak klasik yöntemler ve silme işlemlerinin yanı sıra uygulama içi satın alma işlemlerini oluşturma, yönetme ve satma yönteminizi basitleştirmeyi amaçlayan yeni abonelik mimarisi hakkında da geniş bilgiler verdi. Bu yazıda, Google Play Faturalandırma Kitaplığı 5.0’a ait güncellemeleri inceleyecek ve en ilginç olanlarını derinlemesine inceleyeceğim.
Yeni Abonelik Modeli
Yeni Abonelik Satın Alma
Kodla ilgili bir diğer konu, Google Play Faturlandırma Kitaplığı 5.0’da SkuDetails sınıfı ve Sku içeren diğer tüm varlıklar veya yöntemler kullanımdan kaldırılmıştır. Bu yüzden artık bu amaç için ProductDetails kullanmayı düşünebilirsiniz. Ürün detayları, temel planlar ve teklifler de dahil olmak üzere abonelikle ilgili birçok bilgiyi içerir.
Önceden aşağıdaki gibi abonelik detayları isteği yapıyordunuz:
val params = SkuDetailsParams.newBuilder() .setType(BillingClient.SkuType.SUBS) .setSkusList(listOf("premium")) .build() billingClient.querySkuDetailsAsync(params) { billingResult, skuDetailsList -> // Process the result } Copy
Artık şu şekilde yapmalısınız:
val productList = listOf( QueryProductDetailsParams.Product.newBuilder() .setProductType(BillingClient.SkuType.SUBS) .setProductId("premium") .build() ) val params = QueryProductDetailsParams.newBuilder() .setProductList(productList) .build() billingClient.queryProductDetailsAsync(params) { billingResult, productDetailsList -> // Process the result }Copy
Ve satın alma akışını başlatmak için aşağıdaki yapıları kullanıyordunuz:
val billingFlowParams = BillingFlowParams.newBuilder() .setSkuDetails(skuDetails) .build() val billingResult = billingClient.launchBillingFlow(activity, billingFlowParams)Copy
Ama artık aşağıdaki gibi görünecek:
// Note that `subscriptionOfferDetails` can be null if it is an in-app product, not a subscription. val offerToken = productDetails.subscriptionOfferDetails?.get(selectedOfferIndex)?.offerToken ?: return val productDetailsParamsList = listOf( BillingFlowParams.ProductDetailsParams.newBuilder() .setProductDetails(productDetails) .setOfferToken(offerToken) .build() ) val billingFlowParams = BillingFlowParams.newBuilder() .setProductDetailsParamsList(productDetailsParamsList) val billingResult = billingClient.launchBillingFlow(activity, billingFlowParams) Copy
Ayrıca Google Migration adımlarındaki geçiş örneklerine de göz atabilirsiniz. Şunu unutmayın ki bu örneklerde birkaç harf hatası bulunuyor ve bu hatalar burada düzeltiliyor.
Hadi gelin değişikliklere bir göz atalım.
Daha önceden de bahsettiğim gibi abonelik detaylarını ve satın alma akışını sorgulamak için artık ProductDetails kullanabilirsiniz. Ayrıca her bir ProductDetails içinde birkaç teklif bulunabileceğinden dolayı faturalandırma akışı parametrelerine bir offerToken sağlamalısınız. Teklif detayları dizisinin (productDetails.subscriptionOfferDetails) her zaman temel plan detaylarını içerdiğini (herhangi bir temel plan varsa) unutmayın; bu sebeple aboneliğiniz yalnızca teklifleri olmayan bir temel plan içeriyor olsa bile satın alma için hala offerToken sahibi olacaklardır.
Yeni satın alma akışının önceki sürümde olduğu gibi SkuDetails yerine birden fazla ProductDetails kabul ettiğini siz de fark edebilirsiniz. Ancak birden fazla ProductDetails sağlarsanız akış hata verebilir. Resmi entegrasyon rehberi setProductDetails ve setOfferToken yöntemlerini, BillingFlowParams. Builder sınıfı üzerinde kullanırken yanlış bir örnek verir fakat bu amaçlar için mevcut yöntem yalnızca setProductDetailsParamsList’dir. Görünüşe göre Google, Faturalandırmanın aynı anda birden fazla farklı abonelik satın alımını destekleyeceği bir gelecek vizyonuyla son zamanlarda tek ürün ayrıntısından birden fazla ürün ayrıntısına geçmeye karar vermiş.
Geri kalan akış — yani satın alma işlemi — Google Play Faturalandırma Kitaplığı 4.0’daki ile aynı kalır.
Aboneliklerin Geriye Dönük Uyumluluğu
Şimdilik her şey yolunda görünüyor fakat eğer ya şimdi geçiş yapmak istemiyorsanız? Google bunu da düşündü.
Google Play Konsolu zaten yalnızca yeni abonelik modeliyle çalışıyor olsa da tüm eski abonelikler otomatik olarak yeni aboneliklere dönüştürülecek ve geriye dönük uyumlulukları da kaydediliyor. Yani, aboneliklerinizi Google Konsolunda yeni formatta gördüğünüz ancak uygulamada daha önce yaptığınız gibi yine de onlarla çalışabileceksiniz.
Ayrıca, tüm eski aboneliklerin geçişten sonra salt okunur hale getirildiğini de göreceksiniz. Google, düzenlemenin söz konusu olduğu abonelikler için InAppProducts API desteğini devre dışı bırakacağı konusunda sizi uyarmakta.
Bazı ürün detaylarını görmek için bu API’yı arka planda kullanıyor olabilirsiniz, bu nedenle dikkatli olun — aboneliği düzenlenebilir hale getirdikten sonra, dönüştürülmüş abonelik bilgilerini almaya çalışırsanız bu API’dan hata (aşağıda gösterildiği gibi) alacaksınız. Aynı durum 11 Mayıs’tan sonra oluşturulan tüm yeni abonelikler için de geçerli olacaktır.
HTTP code - 422 Non-existent in-app product: com.qonversion.sample\/ProductId{productId=article_test_trial}Copy
Bu nedenle, InAppProducts API kullanıyorsanız yeni abonelik oluşturmadan veya eski abonelikleri düzenlemeden önce yükseltmeyi düşünün.
Google Play Console’daki yeni abonelikler arayüzünde gezinirken temel planların ve abonelik tekliflerinin yanında “Geriye dönük uyumlu” gibi etiketler bulacaksınız. Yani, bu abonelikleri kullanımdan kaldırılmış SkuDetails ile satın alırsanız (Tıpkı Google Play Faturalandırma Kitaplığı 4.0’da olduğu gibi) kelimenin tam anlamıyla bu uyumlu temel planları/teklifleri satın alacaksınız. Eğer hiçbir uyumluluk teklifine sahip olmayan bir uyumlu temel plan varsa o halde o temel plan satın alınacaktır. Hem uyumlu temel plan hem de teklif mevcutsa, teklif mevcut kullanıcı için uygunsa, satın alınacaktır, aksi takdirde — temel plan satın alınacaktır. İsterseniz geriye dönük uyumlu olarak başka bir temel plan/teklif seçebilirsiniz.
Not — bu Geriye dönük uyumluluk Google Play Faturalandırma Kitaplığı ile alakalıdır ve ayrıca InAppProducts API ile ilgili değildir. Önceden de belirtildiği üzere örneğin bir abonelik için birden fazla temel plan veya teklif gibi yeni özellikler kullanmaya başlarsanız ya da yalnızca salt okunurdan düzenlenebilir hale dönüştürürseniz, bu abonelik yine de uygulama için Geriye dönük olarak uyumlu olabilir, ancak API için uyumlu olmayabilir.
Diğer Güncellemeler
Google Play Faturalandırma Kitaplığı 5.0’da özet olarak bahsetmeye değer birkaç küçük güncelleme bulunuyor.
Google Play Faturlandırma Kitaplığı 4.0’da kullanımdan kaldırılan
queryPurchasesyöntemi de kaldırıldıArtık senkronize istekler yok, sadece
queryPurchasesAsync.launchPriceChangeFlowkullanımdan kaldırıldı — yeni tavsiye edilen fiyat değişimi akışı müşterinin Google Play abonelikleri sayfası aracılığıyla onayını gerektiriyor ve bu yüzden de BillingClient yöntemini kullanmak yerine gezinti için Derin Link (Deep Link) kullanmanız gerekiyor.Tüketici Hakları Yönetmeliği uyarınca AB kullanıcıları için kişiselleştirilmiş bir fiyat sunmak adına
setIsOfferPersonalizedyöntemi eklendi. Bu seçenek, Google Faturalandırma satın alma ekranının altına bir satır ekleyerek fiyatın kişiselleştirildiğini belirtir.
Yeni Abonelik Modeli ve Qonversion
Google Play Faturalandırma Kitaplığı 5.0 desteği üzerinde çalışırken, uygulama içi satın alımlarınızda Qonversion SDK’yı kullanabilirsiniz. Artık Google Play Faturalandırma Kitaplığı 4.0’ı kullanıyoruz, bu da yalnızca geriye dönük uyumlu temel planlar ve tekliflerle abonelikleri yönetebileceğimiz anlamına geliyor. Önceki abonelik modelinde bulunan bir fiyat, ödemesiz dönem, deneme süresi vb. özellikleri hala düzenleyebilir ve yeni abonelikler oluşturabilirsiniz. Endişelenmeyin, geriye dönük uyumlu en az bir temel planınız ve gerekirse geriye dönük uyumlu bir teklifiniz olacak. Ve yine de, temel plan veya teklif tanımlayıcıları değil, Ürün Merkezimizdeki ürünleri yapılandırmak için tam bir abonelik tanımlayıcısına ihtiyacımız bulunuyor.
Eğer herhangi bir sorunuz varsa, lütfen bize bildirin. Size yardımcı olmaktan mutluluk duyarız.
Yıllık I/O konferansı sırasında Google, Google Play Faturalandırma Kitaplığı’nın yeni ana sürümünü tanıttı. Buna ek olarak klasik yöntemler ve silme işlemlerinin yanı sıra uygulama içi satın alma işlemlerini oluşturma, yönetme ve satma yönteminizi basitleştirmeyi amaçlayan yeni abonelik mimarisi hakkında da geniş bilgiler verdi. Bu yazıda, Google Play Faturalandırma Kitaplığı 5.0’a ait güncellemeleri inceleyecek ve en ilginç olanlarını derinlemesine inceleyeceğim.
Yeni Abonelik Modeli
Yeni Abonelik Satın Alma
Kodla ilgili bir diğer konu, Google Play Faturlandırma Kitaplığı 5.0’da SkuDetails sınıfı ve Sku içeren diğer tüm varlıklar veya yöntemler kullanımdan kaldırılmıştır. Bu yüzden artık bu amaç için ProductDetails kullanmayı düşünebilirsiniz. Ürün detayları, temel planlar ve teklifler de dahil olmak üzere abonelikle ilgili birçok bilgiyi içerir.
Önceden aşağıdaki gibi abonelik detayları isteği yapıyordunuz:
val params = SkuDetailsParams.newBuilder() .setType(BillingClient.SkuType.SUBS) .setSkusList(listOf("premium")) .build() billingClient.querySkuDetailsAsync(params) { billingResult, skuDetailsList -> // Process the result } Copy
Artık şu şekilde yapmalısınız:
val productList = listOf( QueryProductDetailsParams.Product.newBuilder() .setProductType(BillingClient.SkuType.SUBS) .setProductId("premium") .build() ) val params = QueryProductDetailsParams.newBuilder() .setProductList(productList) .build() billingClient.queryProductDetailsAsync(params) { billingResult, productDetailsList -> // Process the result }Copy
Ve satın alma akışını başlatmak için aşağıdaki yapıları kullanıyordunuz:
val billingFlowParams = BillingFlowParams.newBuilder() .setSkuDetails(skuDetails) .build() val billingResult = billingClient.launchBillingFlow(activity, billingFlowParams)Copy
Ama artık aşağıdaki gibi görünecek:
// Note that `subscriptionOfferDetails` can be null if it is an in-app product, not a subscription. val offerToken = productDetails.subscriptionOfferDetails?.get(selectedOfferIndex)?.offerToken ?: return val productDetailsParamsList = listOf( BillingFlowParams.ProductDetailsParams.newBuilder() .setProductDetails(productDetails) .setOfferToken(offerToken) .build() ) val billingFlowParams = BillingFlowParams.newBuilder() .setProductDetailsParamsList(productDetailsParamsList) val billingResult = billingClient.launchBillingFlow(activity, billingFlowParams) Copy
Ayrıca Google Migration adımlarındaki geçiş örneklerine de göz atabilirsiniz. Şunu unutmayın ki bu örneklerde birkaç harf hatası bulunuyor ve bu hatalar burada düzeltiliyor.
Hadi gelin değişikliklere bir göz atalım.
Daha önceden de bahsettiğim gibi abonelik detaylarını ve satın alma akışını sorgulamak için artık ProductDetails kullanabilirsiniz. Ayrıca her bir ProductDetails içinde birkaç teklif bulunabileceğinden dolayı faturalandırma akışı parametrelerine bir offerToken sağlamalısınız. Teklif detayları dizisinin (productDetails.subscriptionOfferDetails) her zaman temel plan detaylarını içerdiğini (herhangi bir temel plan varsa) unutmayın; bu sebeple aboneliğiniz yalnızca teklifleri olmayan bir temel plan içeriyor olsa bile satın alma için hala offerToken sahibi olacaklardır.
Yeni satın alma akışının önceki sürümde olduğu gibi SkuDetails yerine birden fazla ProductDetails kabul ettiğini siz de fark edebilirsiniz. Ancak birden fazla ProductDetails sağlarsanız akış hata verebilir. Resmi entegrasyon rehberi setProductDetails ve setOfferToken yöntemlerini, BillingFlowParams. Builder sınıfı üzerinde kullanırken yanlış bir örnek verir fakat bu amaçlar için mevcut yöntem yalnızca setProductDetailsParamsList’dir. Görünüşe göre Google, Faturalandırmanın aynı anda birden fazla farklı abonelik satın alımını destekleyeceği bir gelecek vizyonuyla son zamanlarda tek ürün ayrıntısından birden fazla ürün ayrıntısına geçmeye karar vermiş.
Geri kalan akış — yani satın alma işlemi — Google Play Faturalandırma Kitaplığı 4.0’daki ile aynı kalır.
Aboneliklerin Geriye Dönük Uyumluluğu
Şimdilik her şey yolunda görünüyor fakat eğer ya şimdi geçiş yapmak istemiyorsanız? Google bunu da düşündü.
Google Play Konsolu zaten yalnızca yeni abonelik modeliyle çalışıyor olsa da tüm eski abonelikler otomatik olarak yeni aboneliklere dönüştürülecek ve geriye dönük uyumlulukları da kaydediliyor. Yani, aboneliklerinizi Google Konsolunda yeni formatta gördüğünüz ancak uygulamada daha önce yaptığınız gibi yine de onlarla çalışabileceksiniz.
Ayrıca, tüm eski aboneliklerin geçişten sonra salt okunur hale getirildiğini de göreceksiniz. Google, düzenlemenin söz konusu olduğu abonelikler için InAppProducts API desteğini devre dışı bırakacağı konusunda sizi uyarmakta.
Bazı ürün detaylarını görmek için bu API’yı arka planda kullanıyor olabilirsiniz, bu nedenle dikkatli olun — aboneliği düzenlenebilir hale getirdikten sonra, dönüştürülmüş abonelik bilgilerini almaya çalışırsanız bu API’dan hata (aşağıda gösterildiği gibi) alacaksınız. Aynı durum 11 Mayıs’tan sonra oluşturulan tüm yeni abonelikler için de geçerli olacaktır.
HTTP code - 422 Non-existent in-app product: com.qonversion.sample\/ProductId{productId=article_test_trial}Copy
Bu nedenle, InAppProducts API kullanıyorsanız yeni abonelik oluşturmadan veya eski abonelikleri düzenlemeden önce yükseltmeyi düşünün.
Google Play Console’daki yeni abonelikler arayüzünde gezinirken temel planların ve abonelik tekliflerinin yanında “Geriye dönük uyumlu” gibi etiketler bulacaksınız. Yani, bu abonelikleri kullanımdan kaldırılmış SkuDetails ile satın alırsanız (Tıpkı Google Play Faturalandırma Kitaplığı 4.0’da olduğu gibi) kelimenin tam anlamıyla bu uyumlu temel planları/teklifleri satın alacaksınız. Eğer hiçbir uyumluluk teklifine sahip olmayan bir uyumlu temel plan varsa o halde o temel plan satın alınacaktır. Hem uyumlu temel plan hem de teklif mevcutsa, teklif mevcut kullanıcı için uygunsa, satın alınacaktır, aksi takdirde — temel plan satın alınacaktır. İsterseniz geriye dönük uyumlu olarak başka bir temel plan/teklif seçebilirsiniz.
Not — bu Geriye dönük uyumluluk Google Play Faturalandırma Kitaplığı ile alakalıdır ve ayrıca InAppProducts API ile ilgili değildir. Önceden de belirtildiği üzere örneğin bir abonelik için birden fazla temel plan veya teklif gibi yeni özellikler kullanmaya başlarsanız ya da yalnızca salt okunurdan düzenlenebilir hale dönüştürürseniz, bu abonelik yine de uygulama için Geriye dönük olarak uyumlu olabilir, ancak API için uyumlu olmayabilir.
Diğer Güncellemeler
Google Play Faturalandırma Kitaplığı 5.0’da özet olarak bahsetmeye değer birkaç küçük güncelleme bulunuyor.
Google Play Faturlandırma Kitaplığı 4.0’da kullanımdan kaldırılan
queryPurchasesyöntemi de kaldırıldıArtık senkronize istekler yok, sadece
queryPurchasesAsync.launchPriceChangeFlowkullanımdan kaldırıldı — yeni tavsiye edilen fiyat değişimi akışı müşterinin Google Play abonelikleri sayfası aracılığıyla onayını gerektiriyor ve bu yüzden de BillingClient yöntemini kullanmak yerine gezinti için Derin Link (Deep Link) kullanmanız gerekiyor.Tüketici Hakları Yönetmeliği uyarınca AB kullanıcıları için kişiselleştirilmiş bir fiyat sunmak adına
setIsOfferPersonalizedyöntemi eklendi. Bu seçenek, Google Faturalandırma satın alma ekranının altına bir satır ekleyerek fiyatın kişiselleştirildiğini belirtir.
Yeni Abonelik Modeli ve Qonversion
Google Play Faturalandırma Kitaplığı 5.0 desteği üzerinde çalışırken, uygulama içi satın alımlarınızda Qonversion SDK’yı kullanabilirsiniz. Artık Google Play Faturalandırma Kitaplığı 4.0’ı kullanıyoruz, bu da yalnızca geriye dönük uyumlu temel planlar ve tekliflerle abonelikleri yönetebileceğimiz anlamına geliyor. Önceki abonelik modelinde bulunan bir fiyat, ödemesiz dönem, deneme süresi vb. özellikleri hala düzenleyebilir ve yeni abonelikler oluşturabilirsiniz. Endişelenmeyin, geriye dönük uyumlu en az bir temel planınız ve gerekirse geriye dönük uyumlu bir teklifiniz olacak. Ve yine de, temel plan veya teklif tanımlayıcıları değil, Ürün Merkezimizdeki ürünleri yapılandırmak için tam bir abonelik tanımlayıcısına ihtiyacımız bulunuyor.
Eğer herhangi bir sorunuz varsa, lütfen bize bildirin. Size yardımcı olmaktan mutluluk duyarız.
Start Now for Free
Or book a demo with our team to learn more about Qonversion
Start Now for Free
Or book a demo with our team to learn more about Qonversion
Start Now for Free
Or book a demo with our team to learn more about Qonversion
Read more
Read more
Trash Panda Maximizes App Revenue after Setting the Best Subscription Price with A/B Tests
Jul 8, 2024
Jul 8, 2024
How StyleDNA Saved 20% Development Time and Unlocked New Features
Jun 19, 2024
Jun 19, 2024
WWDC24 Updates for App Developers | What's new in Storekit 2 and App Store Server API?
Jun 17, 2024
Jun 17, 2024
How A/B Testing with Qonversion Helped Iben Sandahl’s Parenting App Double Their Sales
Jun 13, 2024
Jun 13, 2024
Trash Panda Maximizes App Revenue after Setting the Best Subscription Price with A/B Tests
Jul 8, 2024
Jul 8, 2024
How StyleDNA Saved 20% Development Time and Unlocked New Features
Jun 19, 2024
Jun 19, 2024
WWDC24 Updates for App Developers | What's new in Storekit 2 and App Store Server API?
Jun 17, 2024
Jun 17, 2024
