Prueba para las masas con un solo teléfono y emulador

Question

Tengo una nueva aplicación para Android que puse en el mercado hace unos días. Hice bastantes pruebas en mi moto droide antes de publicarlo e intenté ser muy minucioso. Bueno, recibí algunos comentarios negativos sobre cómo no funcionó bien en EVO 2.2 o X10 de alguien (ni siquiera sabía qué era eso al principio). Bueno, funciona perfectamente en mi teléfono.

¿Algún consejo sobre cómo se supone que debo arreglar o soportar una aplicación que se ejecuta como 100 teléfonos diferentes?

¿Cómo se están acercando a esto otros desarrolladores? (sin comprar realmente todos los teléfonos que hay) Gracias.

Answer 1

No creo que haya una solución mágica para evitar este tipo de problemas. Un par de pautas/sugerencias:

Prevención de problemas:

• utilizar las API única documentados públicamente. Si depende de los detalles de implementación , es probable que las cosas fallen en diferentes teléfonos.
• Siga las instrucciones para supporting multiple screens, y asegúrese de probar cada una de las combinaciones de tamaños de pantalla y densidades en el emulador.
• Si está utilizando un montón de OpenGL, investigue qué extensiones son compatibles con qué teléfonos. Aquí es donde suele haber un mayor número de problemas.
• Recluta a tus amigos para ser beta testers. Puede enviarles una aplicación para cargar antes de publicarla en el mercado.

Diagnóstico de problemas:

• A partir de Android 2.2, usted será capaz de obtener los informes de errores de vuelta de los usuarios, lo que debería ayudar en el diagnóstico de problemas de forma rápida: Android Application Error Reports
• También puede implementar algo parecido remote stack trace para obtener mensajes de error mientras tanto.

Answer 2

Creo que un buen enfoque es asegurarse de que su logging todos sus errores y recibirlos de los usuarios de forma remota. Esta publicación tiene una buena solución: How do I obtain crash-data from my Android application?

Answer 3

Una opción que considero es algún tipo de versión beta pública. Proporcione una versión gratuita en el mercado, claramente marcada como una versión beta, con instrucciones para enviar por correo electrónico los detalles del dispositivo utilizado y los problemas encontrados. Si tiene intención de cobrar por la versión final, querrá que la versión beta tenga un límite de tiempo o esté restringida de alguna otra manera. Puede eliminar la versión beta del mercado, y con ella cualquier comentario negativo, cuando lance la versión completa.

Una alternativa para hacer esto en el mercado oficial es subir al pre-release area of AndAppStore.

En cuanto a la X10, en mi experiencia limitada, este teléfono parece surgir con bastante frecuencia cuando se trata de quejas de aplicaciones que no funcionan, particularmente si se trata de sonido. Sony-Ericsson ha lanzado an X10 add-on for the Android SDK, para que pueda hacer que su emulador se vea como un X10, aunque no estoy seguro de la gran diferencia que tiene su comportamiento.

Answer 4

O use una comunidad de prueba para que las personas con diferentes dispositivos puedan probar su aplicación y brinden sus comentarios.

Answer 5

Registrar toda la actividad del usuario es una buena manera de evaluar cómo funciona la aplicación en diferentes apis/devices.

Google Firebase es la forma más reciente (2016) de Google para proporcionarle datos de fallas/errores en su teléfono. incluirlo en su archivo build.gradle:

compile 'com.google.firebase:firebase-crash:9.0.0' 

Los accidentes fatales que se registran de forma automática sin necesidad de intervención del usuario y también se puede registrar los accidentes no fatales u otros eventos, así:

try 
{ 

} 
catch(Exception ex) 
{ 
    FirebaseCrash.report(new Exception(ex.toString())); 
}