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

5

No meu código eu verifico a versão atual do software na inicialização e comparo com a versão armazenada no (s) arquivo (s) de dados do usuário. Se a versão for mais recente, chamo métodos diferentes para atualizar os dados antigos para a versão de dados mais nova, se necessário.

Normalmente, preciso criar um novo método para converter os dados em cada atualização que altere os dados do usuário de alguma forma e não possa remover os antigos, caso haja alguém que tenha perdido uma atualização. Assim, o aplicativo deve ser capaz de passar por cada chamada de método e atualizar seus dados até que eles obtenham seus dados atuais. Com conjuntos de dados maiores, isso pode ser um problema.

Além disso, recentemente tive uma breve discussão com outro usuário do StackOverflow e ele indicou que sempre acrescentava um carimbo de data ao nome do arquivo para gerenciar as versões de dados, embora raciocinasse por que isso era melhor do que armazenar os dados da versão no arquivo em si não estava claro.

Como raramente vi o gerenciamento de versões de dados do usuário em livros que já li, estou curioso sobre quais são as práticas recomendadas para nomear arquivos de dados do usuário e procedimentos para atualizar dados mais antigos para versões mais recentes.

Editar: O 'carimbo de data' resultou de uma discussão aqui:

link

Como a pergunta é muito aberta, devo dizer que estou procurando os procedimentos recomendados para atualizar os dados do usuário entre as versões.

Se possível, seria bom ver as práticas do iOS / objective-c, mas isso não é obrigatório.

    
por TigerCoding 27.11.2011 / 17:24
fonte

4 respostas

1

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.

    
por 27.11.2011 / 18:04
fonte
1

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.

    
por 02.04.2012 / 16:52
fonte
0

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.).

    
por 27.11.2011 / 18:24
fonte
0

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.

    
por 30.04.2012 / 10:10
fonte