Anotación
En este artículo, me gustaría compartir mis impresiones generales sobre el uso de BaaS, una solución llamada Parse para desarrollar el back-end de una aplicación de Android y hablar sobre todos los "escollos" que tuve que enfrentar durante el período de desarrollo. Por primera vez, mis colegas de trabajo aconsejaron esta plataforma cuando era un joven, y solo había un proyecto comercial detrás de mí. La motivación para escribir este artículo fueron los nervios y el tiempo que pasé buscando versiones compatibles de bibliotecas y reflexionando sobre las extrañas decisiones de los desarrolladores de la plataforma,
bueno, o simplemente porque todavía no he encontrado artículos sobre este tema . Además, no diré nada sobre qué es Parse y cómo conectarlo y configurarlo, pero por si acaso, dejaré todos los enlaces necesarios donde pueda leer sobre él.
Problema n. ° 1: uso de Parse Server junto con PostgreSQl
El uso de esta configuración se debió al hecho de que el servidor se implementó en el alojamiento VDS, y el uso de la base de datos remota de MLab no era práctico, porque en el momento del desarrollo, Roskomnadzor estaba tratando de bloquear Telegram en Rusia, y había problemas con la conexión sin una VPN. No hubo tiempo para configurar VPN en la consola Linux, y el proyecto estaba encendido, así que decidí usar una base de datos local en el servidor. Elegí PostgreSQL porque tenía buena experiencia con él.
Life hack número 1: para que la base de datos funcione sin errores en los tipos de datos, al instalar postgres, debe instalar postgis. Después de eso, debe crear una base de datos e inmediatamente después de crear crear conectar todas las extensiones postgis. Puede leer sobre cómo conectar extensiones postgis a la base de datos
aquí . Después de conectar todas las extensiones, puede conectar la base de datos al servidor, abrir el panel de control y ver que las tablas se crean sin errores.
Lifehack No. 2: use la versión del servidor Parse> = 2.7.2. Cuando descargué el proyecto de prueba de gita, había una versión del servidor 2.2.5, y todo parecía funcionar, pero luego se solucionó un error: al mantener las coordenadas de geolocalización, lat y lng cambiaron de lugar. Y hubo 2 casos: si las coordenadas eran <90 en valor absoluto, entonces el marcador en el mapa estaba en otro lugar, de lo contrario la aplicación se bloquearía, y el registro de que el Lat no debería tener más de 90 en valor absoluto cayó en la consola. Luego comencé un tonto de 2 días en busca de soluciones. Lo que simplemente no encontré en varios foros y en cuestiones de github: voltear coordenadas en la función Cloud (¡no funciona!); voltear las coordenadas en PostgresStorageAdapter (después de los cambios hubo un montón de errores, no quería profundizar en el final de la jornada laboral, apagué la computadora y me fui). Al día siguiente, miré las versiones y vi que en la versión 2.7.2 se solucionó un error en PostgresStorageAdapter. Rápidamente arreglé la versión en package.json, y he aquí que funcionó como debería. En este punto, ya había la versión 3.x.x, y traté de usarla, pero los desarrolladores hicieron muchos cambios relacionados con las funciones de la nube, y aparecieron otros errores al inicio. No hubo tiempo para arreglar el código de trabajo, por lo que la versión 2.7.2 fue adecuada para mí. Si acaba de comenzar su proyecto, por supuesto, es mejor usar la última versión.
Problema # 2: LiveQuery no se da de baja
Pasé un poco más de un día para resolver este problema. Y ella era malditamente extraña y no obvia.
Inicialmente, la arquitectura era algo como esto:
public class Subclass extends ParseObject {
Y cuando sale de la pantalla, se llamó al método, pero la solicitud no se anuló. Como sabe, LiveQuery se suscribe a pedido, y cualquier cambio en los datos correspondientes a la solicitud se puede rastrear en la devolución de llamada. La cancelación de la suscripción también se realiza a pedido. El objeto Suscriptor se devuelve en el método de suscripción, pero este objeto es absolutamente inútil, ya que no contiene el método "cancelar suscripción", y LiveQueryClient en sí no contiene el método "cancelar suscripción" con el parámetro Suscriptor. Al activar la depuración, comencé a seguir paso a paso el mismo método de "cancelar suscripción". El cliente mismo almacena la lista de suscripción de forma privada. En el método, los desarrolladores realizan un ciclo a través de esta hoja y comparan la solicitud del parámetro con una solicitud privada, que se almacena en el objeto de suscripción por la función indefinida igual, que corresponde al usual ==, y que compara direcciones de objetos complejos. Y esto lo explicó todo, porque en mi proyecto había una clase con funciones que creaban la consulta correcta para mí. Y dado que el objeto de solicitud siempre se creó de nuevo, por lo tanto, las direcciones de las solicitudes fueron diferentes, igual no funcionó y no se produjo la cancelación de la suscripción. Resolví este problema de la siguiente manera: hice singleton, y funcionó.
Se parecía a esto:
public class Subclass extends ParseObject {
Después de un tiempo, surgió la idea de escribir a mi propio gerente que supervisará las suscripciones, pero nunca me di cuenta de eso.
Conclusión
Espero que este artículo sea útil. Si encuentra alguna imprecisión o error, escríbame. Como prometí, dejaré enlaces a varias buenas fuentes que me ayudaron:
¡Buena suerte a todos!