Práticas recomendadas para atualizar dados do usuário ao atualizar versões de software

As datas são úteis quando você precisa de informações extras sobre quando algo está acontecendo. Não há nenhum dano em adicioná-los a um arquivo que já contém um número de versão.

No entanto, você não pode usar um registro de data e hora como o único indicador de qual versão está sendo executada, portanto, decidir o que precisa ser atualizado. Só porque você liberou 2 atualizações no ano passado não significa que alguém com uma data de instalação dentro desse intervalo esteja usando uma dessas duas versões. Se o usuário obtiver uma cópia do instalador, ele poderá segurá-lo para futuras instalações limpas e esperar que o software se atualize em vez de obter a versão mais recente.

Como você observou, não há vantagem real de uma data sobre o número da versão. E você precisa manter conversões antigas para dar suporte a pessoas que pulam atualizações (minha esposa é ruim nisso).

Uma coisa em que você pode pensar é algum tipo de inventário do número de pessoas em cada versão, para que você saiba quando pode descartar atualizações antigas. A Apple deve ser capaz de lhe fornecer essas estatísticas (mas eu não tenho idéia se elas são). Ou você poderia adicionar uma função ping que lhe enviaria o número da versão e um código único toda vez que o aplicativo fosse executado pela primeira vez após uma instalação ou atualização.

O benefício imediato de um timestamps que eu vejo é que você tem uma sequência. Eu recomendaria o timestamp ser inserido em um arquivo de constantes, no momento da compilação. Isso torna o registro de data e hora indicativo da versão de construção (não o tempo de instalação / atualização).

Além disso, eu diria que depende de você. Você pode facilmente escrever uma classe para ajudar no sequenciamento de versões, dependendo do método de nomeação da sua versão (1.x, 1.2.x, etc.).

Em termos de iOS / objective-c, uma das práticas recomendadas é usar valor-chave dos dados, juntamente com NSCoder . Isso permite que você atualize os dados mais antigos de maneira direta.

Outra opção é simplificar as coisas para um NSDictionary e salvar os dados no formato JSON (ou similar). Isso tem a vantagem de uso comum significativamente mais simples, o reordenamento de elementos de dados entre versões é mais fácil de manipular (normalmente você não precisa fazer nada), mas as desvantagens de colocar limitações nos tipos de dados que podem ser usados e verifique se há valores ausentes como um processo separado.

Se o formato do valor de uma chave mudar, você pode, em alguns casos, obter uma conversão automática durante o carregamento (ex: [dataValue intValue] - > [dataValue stringValue] se dataValue for alterado de um inteiro para uma string) . Se necessário, você pode verificar o tipo manualmente (isKindOfClass / isMemberOfClass) e encobrir conforme necessário.

Quanto a usar ou não um carimbo de data, além de uma versão nos dados, isso depende do que você está tentando realizar. Se você está apenas querendo rastrear a compatibilidade de dados entre os lançamentos do aplicativo, então um carimbo de data não tem mais significado do que um número de versão (e talvez menos, já que é mais difícil relacionar o aplicativo).

Pessoalmente, eu uso o método NSDictionary / JSON onde eu posso e só uso a configuração NSCoder quando eu tenho dados complexos. Se você tem grandes estruturas que você acha que precisam ser atualizadas várias vezes ao longo do tempo de vida do seu aplicativo, sugiro usar a configuração do NSCoder, pois ela fornece o método mais limpo de atualizar os dados dinamicamente com menos sobrecarga. / p>

Por último, para C direto, uso uma configuração para estruturas que fornece verificação simples de versão e verificação de dados. Cada struct que eu (talvez) precise ser capaz de atualizar é algo como:

version
element1
.
.
elementX
id_tag

O número da versão é legível em um editor hexadecimal (ex: 0x00010000 == 1.0) e o tag é um ResType de 4 bytes (ex: 'pDat', 'TXT2', etc). Eu coloquei o id_tag no final depois de correr em instâncias de outros programadores atualizando minhas estruturas e não atualizando a versão #. Isso faria com que qualquer código que tentasse usar novos dados falhasse, pois a verificação para validar os dados com base na versão antiga # não localizaria o id_tag no local correto. Não é uma prova completa (mudar um int de 4 bytes para um flutuador de 4 bytes passaria despercebido, por exemplo), mas é decente, barato e útil ao visualizar um arquivo de dados com um monte dessas estruturas em um editor hexadecimal.

Espero que ajude.