¿Por qué no hay biblioteca de In-App Billing oficial?

[mocelet]

Es más un pensamiento en voz alta... ¿por qué el código de ayuda para las compras in-app (IabHelper y compañía) en vez de estar metido en una app de ejemplo (TrivialDrive https://github.com/googlesamples/android-play-billing) no lo convierten en una biblioteca que se actualice con gradle, como la de soporte mismamente?

Bien puede ser porque el código es mejorable, especialmente a la hora de hacer consultas asíncronas... si solicitas el precio de los artículos y el usuario da a comprar antes de que llegue el precio salta una excepción porque solo puede hacer una operación a la vez.

Poco profesional desde luego, darle al comprar debería ser algo totalmente prioritario, cancelar todo y efectuar el flujo de compra de Play Store. ¡Pero es que ni siquiera puedes cancelar una operación en curso manualmente! Si haces un dispose() fulminas el helper entero.

Me consta que hay proyectos que ofrecen un helper mejorado, pero a algo tan importante como ¡una venta! creo que Google debería darle más cariño.

[Dexafree]

La verdad es que si, es una parte de las aplicaciones que acabas copiando de una vez que te funcionó (si tienes suerte y es de la misma versión de InApp Billing...).

Hace nada he tenido que volver a utilizarlo, y aprovechando que utilizaba RxJava en el proyecto, he usado esta librería:
https://github.com/lukaspili/Reactive-Billing

Además, incluye los AIDL! xD

Ofrece una API algo más cómoda de utilizar, sobretodo si estás acostumbrado a Rx.

Fíjate si está mal explicado, que yo creía que obligatoriamente tenías que usar la clave enorme de desarrollador cada vez que haces una compra (y resulta que sirve "únicamente" para comprobar si la compra es correcta).

no lo convierten en una biblioteca que se actualice con gradle, como la de soporte mismamente?

Se actualiza aparte del SDK incluso, tienes que ir abriendo el SDK Manager.


Me consta que hay proyectos que ofrecen un helper mejorado, pero a algo tan importante como ¡una venta! creo que Google debería darle más cariño.

https://developer.android.com/images/in-app-billing/v3/iab_v3_purchase_flow.png

Partidazo de ping pong que hay que montar :aplausos:


PD: Aprovechando el tema. Si la compra no es consumible (es decir, se compra una única vez. ej: Desbloquear la versión sin publicidad), vosotros comprobáis SIEMPRE en las InApp si lo ha comprado, os guardáis algo en local, token en server privado.... Qué estrategia seguís?

[mocelet]

Dexafree uso un hash local. Llamar a las bibliotecas de in-app en cada onResume como sugieren para soportar los códigos promocionales me da pánico por los errores que puede provocar.

Y, total, si el usuario es root ya te quita la publicidad sin hacer nada, así que en ese caso que puedan falsificar la compra es lo de menos y no justifica mantener un servidor.

P.D. También que odio los DRM, no me gustaría nada que un día fallara por lo que sea la comprobación y a alguien que ha pagado le salga un anuncio.

[Dexafree]

uso un hash local

Idem, es la solución que termino usando (por simplicidad, velocidad y eficiencia en datos)


Llamar a las bibliotecas de in-app en cada onResume como sugieren para soportar los códigos promocionales me da pánico por los errores que puede provocar.


Y los consumos de datos para el usuario



P.D. También que odio los DRM, no me gustaría nada que un día fallara por lo que sea la comprobación y a alguien que ha pagado le salga un anuncio.

Exacto, mas que procurar que a alguien que no ha pagado le funcione como si si, hay que mirar mas porque a alguien que SI ha pagado le funcione como tal