¿Cómo puedo Simular SHUTDOWN de Parse.com para medir su imapacto?
Tengo 4 aplicaciones respaldadas por Parse.com en vivo en PlayStore con 5 + millones de usuarios. Cuando Parse.com decidió cerrar su soporte, hemos migrado nuestro back-end a Heroku con éxito y hemos implementado actualizaciones para aplicaciones (Más actualizaciones, más% de migración). Todavía hay un montón de usuarios que están utilizando la versión anterior de las aplicaciones (no actualizar su aplicación con Heroku integrado)
Ahora el cierre de Parse.com se aproxima (28 de enero de 2017) y queremos simular un desastre real que nos dará los casos de los usuarios que usan la aplicación después de parse.com se cierra.
- Android parse.com que guarda error de la instalación. Objeto no encontrado para la actualización
- ClassNotFoundException con Parse y Facebook
- Importe la biblioteca parse.com al estudio de Android 0.8.2
- Parse.com Parámetros de inicio de sesión no válidos
- Force Parse Push Notifications para usar PPNS en lugar de GCM
Cualquier sugerencia será apreciada, Gracias de antemano.
- Consulta en ParseObject
- Parse.com: con parseUser, ¿cómo puedo guardar datos en una columna que he creado en parse de la clase?
- Error al usar Parse SDK para tesiting PUSH Notificaciones-Varios archivos dex definen Lcom / parse / FacebookAuthenticationProvider $ 1
- Cómo enviar notificación push en dos segmentos en momentos diferentes en un día en analizar
- Problema de inicio de sesión de Android Facebook SDK con parse sdk
- Cómo cerrar sesión / cambiar la cuenta de Twitter con Parse
- No se puede guardar un ParseUser que no está autenticado
- Adición de Parse-1.8.0 a Android Studio 1.0.1 (O cualquier archivo .zip)
Esperemos que esto ayude, pero esto es lo que hemos hecho para simular un apagado:
- Configure un proxy local en nuestra red que correlacione el servidor antiguo
https://api.parse.com/1/
a una aplicación web en nuestra red local que siempre devuelve HTTP 500 y / o HTTP 4xx. Además, y lo que es más importante , también probamos los fallos de certificados SSL (usamos CloudFlare para esto). - Entonces ejecutaríamos los viejos clientes en nuestro wifi local, lo que haría que golpearan nuestro 'falso' servidor de cierre que respondería con 500, 4xx y fallos SSL dados nuestras configuraciones de prueba.
- Para los archivos alojados en Parse, obtendrá una respuesta HTTP 403 Acceso negado XML de Amazon S3, que es fácil de probar.
Si no puede configurar un proxy local pero está utilizando el nuevo Parse SDK, siempre puede cambiar la URL del servidor Parse que está utilizando en su código a una máquina disponible en la red o mediante un túnel ngrok que devuelva esos códigos de error.
Según Facebook, los usuarios de Android en promedio tardan unos ~ 80 días para actualizar a la última versión de su aplicación, iOS alrededor de ~ 40 días. Siempre es una buena idea implementar una función de 'actualización de la fuerza' en su aplicación en el caso de que necesite usarla, lo cual parece apropiado para un escenario de apagado de Parse.com.