Annotation
Dans cet article, je voudrais partager mes impressions générales sur l'utilisation de BaaS - une solution appelée Parse pour développer le backend d'une application Android, racontant tous les «pièges» auxquels j'ai dû faire face pendant la période de développement. Pour la première fois, cette plateforme a été conseillée par mes collègues de travail quand j'étais junior, et il n'y avait qu'un seul projet commercial derrière moi. La motivation pour écrire cet article était les nerfs et le temps que j'ai passé à rechercher des versions compatibles des bibliothèques et à méditer sur les décisions étranges des développeurs de la plateforme,
enfin, ou simplement parce que je n'ai toujours pas trouvé d'articles sur ce sujet . De plus, je ne dirai rien sur ce qu'est Parse et comment le connecter et le configurer, mais juste au cas où, je laisserai tous les liens nécessaires où vous pourrez en savoir plus.
Problème n ° 1: utilisation de Parse Server en conjonction avec PostgreSQl
L'utilisation de cette configuration était due au fait que le serveur était déployé sur l'hébergement VDS, et l'utilisation de la base de données MLab distante était inappropriée, car au moment du développement, Roskomnadzor essayait de bloquer Telegram en Russie, et il y avait des problèmes avec la connexion sans VPN. Il n'y avait pas de temps pour configurer VPN sur la console Linux, et le projet était en marche, j'ai donc décidé d'utiliser une base de données locale sur le serveur. J'ai choisi PostgreSQL parce que j'avais une bonne expérience avec lui.
Life hack numéro 1: pour que la base de données fonctionne sans erreur dans les types de données, lors de l'installation de postgres, vous devez installer postgis. Après cela, vous devez créer une base de données et immédiatement après avoir créé create connect toutes les extensions postgis. Vous pouvez découvrir comment connecter les extensions postgis à la base de données
ici . Une fois toutes les extensions connectées, vous pouvez connecter la base de données au serveur, ouvrir le tableau de bord et voir que les tables sont créées sans erreur.
Lifehack n ° 2: utilisez la version du serveur Parse> = 2.7.2. Lorsque j'ai téléchargé le projet de test depuis gita, il y avait une version de serveur 2.2.5, et tout semblait fonctionner, mais plus tard un bug est sorti: tout en conservant les coordonnées de géolocalisation, lat et lng ont changé de place. Et il y avait 2 cas: si les coordonnées étaient <90 en valeur absolue, alors le marqueur sur la carte était juste à un autre endroit, sinon l'application planterait et le journal que le Lat ne devrait pas dépasser 90 en valeur absolue tombait dans la console. Puis j'ai commencé un idiot de 2 jours à la recherche de solutions. Ce que je n'ai tout simplement pas trouvé dans divers forums et dans les problèmes de github: inverser les coordonnées dans la fonction Cloud (ne fonctionne pas!); retournement des coordonnées dans PostgresStorageAdapter (après les modifications, il y a eu un tas d'erreurs, je ne voulais pas plonger dans la fin de la journée de travail, éteint l'ordinateur et quitté). Le lendemain, j'ai regardé les versions et j'ai vu que dans la version 2.7.2 un bogue était corrigé dans PostgresStorageAdapter. Correction rapide de la version dans package.json, et voilà, cela a fonctionné comme il se doit. À ce stade, il y avait déjà la version 3.x.x, et j'ai essayé de l'utiliser, mais les développeurs ont apporté de nombreuses modifications liées aux fonctions Cloud, et un autre tas d'erreurs est apparu au démarrage. Il n'y avait pas de temps pour corriger le code de travail, donc la version 2.7.2 me convenait. Si vous venez de démarrer votre projet, il est bien sûr préférable d'utiliser la dernière version.
Problème n ° 2: LiveQuery ne se désabonne pas
J'ai passé un peu plus d'une journée pour résoudre ce problème. Et elle était sacrément étrange et non évidente.
Au départ, l'architecture ressemblait à ceci:
public class Subclass extends ParseObject {
Et lorsque vous quittez l'écran, la méthode a été appelée, mais la demande n'a pas été désabonnée. Comme vous le savez, LiveQuery s'abonne sur demande, et tout changement dans les données correspondant à la demande peut être suivi dans le rappel. La désinscription a également lieu sur demande. L'objet Subscriber est retourné dans la méthode d'abonnement, mais cet objet est absolument inutile, car il ne contient pas la méthode "unsubscribe" et LiveQueryClient lui-même ne contient pas la méthode "unsubscribe" avec le paramètre Subscriber. En activant le débogage, j'ai commencé pas à pas à suivre la même méthode de "désabonnement". Le client lui-même stocke la liste d'abonnement en privé. Dans la méthode, les développeurs parcourent cette feuille et comparent la demande du paramètre avec une demande privée, qui est stockée dans l'objet d'abonnement par la fonction indéfinie égale, qui correspond à l'habituel ==, et qui compare les adresses des objets complexes. Et cela expliquait tout, car dans mon projet, il y avait une classe avec des fonctions qui créait la bonne requête pour moi. Et puisque l'objet de demande était toujours recréé, par conséquent, les adresses des demandes étaient différentes, les égales ne fonctionnaient pas et la désinscription ne s'était pas produite. J'ai résolu ce problème comme suit: a fait singleton, et cela a fonctionné.
Cela ressemblait à ceci:
public class Subclass extends ParseObject {
Après un certain temps, l'idée est venue d'écrire mon propre manager qui surveillera les abonnements, mais je ne m'en suis jamais rendu compte.
Conclusion
J'espère que cet article vous sera utile. Si vous trouvez des inexactitudes ou des erreurs, écrivez-moi. Comme promis, je laisserai des liens vers plusieurs bonnes sources qui m'ont aidé:
Bonne chance à tous!