Anotação
Neste artigo, gostaria de compartilhar minhas impressões gerais sobre o uso do BaaS - uma solução chamada Parse para o desenvolvimento do back-end de um aplicativo Android, contar sobre todas as "armadilhas" que tive que enfrentar durante o período de desenvolvimento. Pela primeira vez, essa plataforma foi aconselhada pelos meus colegas de trabalho quando eu era júnior e havia apenas um projeto comercial atrás de mim. A motivação para escrever este artigo foram os nervos e o tempo que passei procurando versões compatíveis de bibliotecas e ponderando sobre as estranhas decisões dos desenvolvedores da plataforma,
bem, ou simplesmente porque ainda não encontrei artigos sobre esse assunto . Além disso, não vou contar nada sobre o que é o Parse e como conectá-lo e configurá-lo, mas, para garantir, deixarei todos os links necessários onde você pode ler sobre ele.
Problema # 1: Usando o Parse Server em conjunto com o PostgreSQl
O uso dessa configuração se deve ao fato de o servidor ter sido implantado na hospedagem VDS, e o uso do banco de dados MLab remoto não era prático, porque no momento do desenvolvimento, Roskomnadzor estava tentando bloquear o Telegram na Rússia e havia problemas com a conexão sem uma VPN. Não havia tempo para configurar a VPN no console Linux, e o projeto estava em andamento, então decidi usar um banco de dados local no servidor. Eu escolhi o PostgreSQL porque tinha uma boa experiência com ele.
Life hack número 1: para que o banco de dados funcione sem erros nos tipos de dados, ao instalar o postgres, é necessário instalar o postgis. Depois disso, você precisa criar um banco de dados e imediatamente após criar criar conectar todas as extensões postgis. Você pode ler sobre como conectar extensões postgis ao banco de dados
aqui . Depois que todas as extensões estiverem conectadas, você poderá conectar o banco de dados ao servidor, abrir o painel e ver se as tabelas são criadas sem erros.
Lifehack No. 2: use a versão do servidor Parse> = 2.7.2. Quando baixei o projeto de teste do gita, havia uma versão do servidor 2.2.5, e tudo parecia funcionar, mas mais tarde ocorreu um erro: enquanto mantinha as coordenadas de geolocalização, lat e lng mudavam de lugar. E havia dois casos: se as coordenadas tivessem valor <90 em valor absoluto, o marcador no mapa estava em outro lugar; caso contrário, o aplicativo falharia e o registro de que o Lat não deveria ter mais de 90 em valor absoluto caía no console. Então eu comecei um idiota de 2 dias em busca de soluções. O que eu simplesmente não encontrei em vários fóruns e em questões do github: inverter coordenadas na função Cloud (não funciona!); inversão de coordenadas no PostgresStorageAdapter (após as alterações, houve vários erros, eu não queria me aprofundar no final do dia útil, desliguei o computador e saí) No dia seguinte, observei os lançamentos e vi que na versão 2.7.2 um bug foi corrigido no PostgresStorageAdapter. Corrigida rapidamente a versão no package.json, e eis que funcionava como deveria. Nesse ponto, já havia a versão 3.x.x, e tentei usá-la, mas os desenvolvedores fizeram muitas alterações relacionadas às funções da nuvem e outro grupo de erros apareceu na inicialização. Como não havia tempo para corrigir o código em funcionamento, a versão 2.7.2 foi adequada para mim. Se você acabou de iniciar seu projeto, é claro que é melhor usar a versão mais recente.
Problema nº 2: o LiveQuery não cancela a inscrição
Passei um pouco mais de um dia para resolver esse problema. E ela era malditamente estranha e não óbvia.
Inicialmente, a arquitetura era algo assim:
public class Subclass extends ParseObject {
E quando você sai da tela, o método foi chamado, mas a solicitação não foi cancelada. Como você sabe, o LiveQuery assina mediante solicitação e qualquer alteração nos dados correspondentes à solicitação pode ser rastreada no retorno de chamada. O cancelamento da inscrição também ocorre mediante solicitação. O objeto Assinante é retornado no método de inscrição, mas esse objeto é absolutamente inútil, porque não contém o método "cancelar assinatura" e o próprio LiveQueryClient não contém o método "cancelar assinatura" com o parâmetro Subscriber. Ativando a depuração, comecei passo a passo a seguir o mesmo método de "cancelar inscrição". O próprio cliente armazena a lista de assinaturas em particular. No método, os desenvolvedores percorrem esta planilha e comparam a solicitação do parâmetro com a solicitação privada, que é armazenada no objeto de assinatura pela função indefinida igual a, que corresponde ao == usual e que compara os endereços de objetos complexos. E isso explicava tudo, porque no meu projeto havia uma classe com funções que criavam a consulta certa para mim. E como o objeto de solicitação sempre foi recriado, portanto, os endereços das solicitações eram diferentes, iguais não funcionaram e a remoção da assinatura não ocorreu. Resolvi esse problema da seguinte maneira: singleton e funcionou.
Parecia algo assim:
public class Subclass extends ParseObject {
Depois de algum tempo, surgiu a idéia de escrever meu próprio gerente, que monitorará as assinaturas, mas eu nunca percebi isso.
Conclusão
Espero que este artigo seja útil. Se você encontrar alguma imprecisão ou erro, escreva para mim. Como prometido, deixarei links para várias boas fontes que me ajudaram:
Boa sorte a todos!