|
Programación y Desarrollo para Android Subforo exclusivo para temas de programación de software para PDAs y desarrollo de aplicaciones, interfaces, etc bajo Android |
|
Herramientas |
#1
|
||||
|
||||
¿Por qué no hay biblioteca de In-App Billing oficial?
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.
__________________
El mejor Cuatro en Raya de Android (Hilo en HTCMania, Play Store) ¡Un millón de descargas!
|
|
#2
|
||||
|
||||
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! 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). Partidazo de ping pong que hay que montar 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?
__________________
Última edición por Dexafree Día 20/09/16 a las 23:42:48. |
#3
|
||||
|
||||
@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.
__________________
El mejor Cuatro en Raya de Android (Hilo en HTCMania, Play Store) ¡Un millón de descargas!
Última edición por mocelet Día 21/09/16 a las 00:06:10. |
Gracias de parte de: | ||
#4
|
||||
|
||||
Idem, es la solución que termino usando (por simplicidad, velocidad y eficiencia en datos)
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
__________________
|
Estás aquí | ||||||
|