Como modificar entidades já utilizadas no programa em versão antiga sem gerar erros na versão nova

[EuHigorBarbosa]

Pessoal...minha pergunta se refere à gestão de entidades de um programa em produção que vai receber uma atualização.
Se eu tenho uma aplicação em produção com uma entidade de 5 campos como essa:

class TurmaEntity {
  final String id;
  final String name;
  final String imageURL;
  final List<String> listaGrupoComandoEnviado;

  TurmaEntity({
    required this.id,
    required this.name,
    required this.imageURL,
    required this.listaGrupoComandoEnviado,
  });

Caso eu precise adicionar um campo extra (por exemplo DateTime createdAt...ao programa na versão posterior...e depois for atualizar a google play...vai gerar um erro por não ser compatível.

Então minha pergunta é: como eu faço para ter a liberdade de ir construindo novas features para o programa e podendo adicionar novos campos nas entidades de forma a não ter erros?
Existe alguma maneira profissional de se fazer isso?

[eduardoflorence]

Olá @EuHigorBarbosa, eu não entendi a parte de gerar erro somente depois que for para o Google Play. Se você criar uma propriedade (campo) nova na sua entidade e não o torna opcional, a sua própria IDE (por exemplo, VSCode) vai te apresentar erros nos pontos que essa entidade é usada. Então você pode:

1. Acrescentar a propriedade, mas torná-la opcional ( DateTime? createdAt e sem o required) ou;
2. Corrigir todos os pontos onde a entidade é usada para fornecer a nova propriedade.

[EuHigorBarbosa]

Olá Eduardo, minha pergunta não ficou clara. Vou refazer a pergunta para que você possa me ajudar.

Vamos imaginar: eu tenho um programa em produção já publicado na playStore e funcionando.
O cliente então me pede uma alteração. Esse programa tem a entidade TurmaEntity:

class TurmaEntity {
  final String id;
  final String name;
  final String imageURL;
  final List<String> listaGrupoComandoEnviado;

  TurmaEntity({
    required this.id,
    required this.name,
    required this.imageURL,
    required this.listaGrupoComandoEnviado,
  });

Para eu realizar essa alteração eu preciso introduzir um novo campo na entidade ...no caso vamos imaginar que eu precise inserir o campo DateTime createdAt. Daí a entidade reformulada ficaria assim:

class TurmaEntity {
  final String id;
  final String name;
  final String imageURL;
  final DateTime createdAt;
  final List<String> listaGrupoComandoEnviado;

  TurmaEntity({
    required this.id,
    required this.name,
    required this.imageURL,
    required this.createdAt,
    required this.listaGrupoComandoEnviado,
  });

Ao introduzir esse campo na entidade, o meu programa da versão antiga vai quebrar quando eu fizer o upload da nova versão.

E aí que vem a pergunta: como eu faço para ir modificando as entidades na medida que for necessário sem gerar erros de incompatibilidade de versão?

Existe alguma maneira profissional de fazer essa gestão?

[JoaoWitorFelipe]

Olá @EuHigorBarbosa, se as modificações são feitas apenas pelo aplicativo, eu dou a mesma resposta que @eduardoflorence deu, permitir que o campo seja nullable ou obrigatório e alterar nos lugares que a classe é chamada.

Não haverá incompatibilidade na hora de subir uma nova versão já que o aplicativo está sendo justamente atualizado e a versão antiga não será mais usada.

Agora, se o cenário é ter várias versões rodando do app em paralelo com um back-end integrado (que é o comum), teria que versionar o back-end também, se o app está na versão 1 o back-end também deve estar na versão 1, por exemplo. É bem comum utilizar o padrão nas rotas do back-end com o prefixo "/v1/resto-da-rota", "/v2/resto-da-rota" e por ai vai.

Mas se o caso é apenas atualizar o aplicativo, sem ter múltiplas versões em paralelo rodando, não vejo problema apenas alterar e subir a versão (e se tiver um back-end integrado, atualiza-lo junto também).

Se possível, dê um exemplo de erro para entendermos melhor o problema.

[EuHigorBarbosa]

O erro acontece quando o aplicativo de versão nova busca os dados locais que estão na versão antiga (sem o DateTime createdAt). Aí a falta do campo createdAt na versão antiga gera o erro. Daí achei que tivesse uma solução especial profissional pra isso.

Não tinha pensado em fazer os campos serem nullables.

Estou pra subir meu primeiro programa para a google play.
Eu vejo dar problema quando eu envio o apk mais recente para meus clientes e, se nessa nova versão existem entidades com campos adicionais...como foi o caso da adoção do createdAt em todas...aí o android pede para reinstalar tudo e não apenas fazer o update. Aí o que ocorre é a perda de todos os dados locais.

Essa dica de fazer as versões do banco de dados foi muito boa, vou aplicar ela já.
Eu utilizo só um banco de dados no firebase.

[JoaoWitorFelipe]

Entendi, o envio da APK manualmente seria o problema, bom o quanto antes estiver na PlayStore e poder fazer os testes direto por lá seria melhor, já que os clientes possam fazer a atualização e não re-instalação mas entendi a necessidade. Imagino que inicialmente tenha esse problema mas teoricamente depois não deve passar por isso de novo :).

[Anzell]

Você também pode rodar scripts de normalização do banco de dados antes de distribuir a versão nova nas lojas. Dessa forma ao atualizar os usuários já terão uma data createdAt ao atualizarem o app