Como implementar um software atualizavel

Programação Java
#21

[quote=ezaack][quote=drsmachado]A primeira coisa a fazer é distribuir teu software em várias partes. Isso fará com que você tenha partes distintas que podem ser atualizadas de forma independente.
A segunda é definir uma estratégia de atualização (lembrando que você deve considerar os riscos e permitir que um “downgrade” seja possível).[/quote]

Comecei a desenvolver um atualizador que segue mais ou menos esse principio, mas ainda estou bem no inicio. No caso optei com gerar um rash de todos os arquivos do sistema(jar, executaveis, bancos embarcados, etc), e armazar esse rash em um xml que mapeia a localização dos arquivos. Então, quando o usuário iniciar o programa ele starta o atualizador primeiro, semelhante um cliente de MMO por exemplo. Se houver internet ele vai baixar o xml de um ftp, e comprar os rashs. Os que estiverem diferentes ele faz o download do respectivo arquivo, verifica se esta ok(não corrompeu), substitui o antigo e atualiza o xml. Então o atualizador starta o sistema ja atualizado e fecha.

Uma vez iniciado o sistema verificará se existe atualização do atualizador, num processo parecido.

Se alguem tiver dicas para facilitar o desenvolvimento, ou achar que não é uma boa estratégia, por favor, contribua =D

Grato a todos,
Diego[/quote]

Somente se atente se o software foi iniciado com os jars atualizáveis no classpath. Se for, a atualização pode não surtir efeito porque as classes atualizadas já podem ter sido carregadas antes da atualização.

#22

[quote=Ataxexe][quote=ezaack][quote=drsmachado]A primeira coisa a fazer é distribuir teu software em várias partes. Isso fará com que você tenha partes distintas que podem ser atualizadas de forma independente.
A segunda é definir uma estratégia de atualização (lembrando que você deve considerar os riscos e permitir que um “downgrade” seja possível).[/quote]

Comecei a desenvolver um atualizador que segue mais ou menos esse principio, mas ainda estou bem no inicio. No caso optei com gerar um rash de todos os arquivos do sistema(jar, executaveis, bancos embarcados, etc), e armazar esse rash em um xml que mapeia a localização dos arquivos. Então, quando o usuário iniciar o programa ele starta o atualizador primeiro, semelhante um cliente de MMO por exemplo. Se houver internet ele vai baixar o xml de um ftp, e comprar os rashs. Os que estiverem diferentes ele faz o download do respectivo arquivo, verifica se esta ok(não corrompeu), substitui o antigo e atualiza o xml. Então o atualizador starta o sistema ja atualizado e fecha.

Uma vez iniciado o sistema verificará se existe atualização do atualizador, num processo parecido.

Se alguem tiver dicas para facilitar o desenvolvimento, ou achar que não é uma boa estratégia, por favor, contribua =D

Grato a todos,
Diego[/quote]

Somente se atente se o software foi iniciado com os jars atualizáveis no classpath. Se for, a atualização pode não surtir efeito porque as classes atualizadas já podem ter sido carregadas antes da atualização.[/quote]

Mas nesse caso o atualizador seria um sistema separado, inciado antes da aplicação. O sistema principal só seria estartado após a atualização. E quanto a reescrever o sistema para modulariza-lo é algo fora de questão, infelizmente.

#23

[quote=ezaack][quote=Ataxexe][quote=ezaack][quote=drsmachado]A primeira coisa a fazer é distribuir teu software em várias partes. Isso fará com que você tenha partes distintas que podem ser atualizadas de forma independente.
A segunda é definir uma estratégia de atualização (lembrando que você deve considerar os riscos e permitir que um “downgrade” seja possível).[/quote]

Comecei a desenvolver um atualizador que segue mais ou menos esse principio, mas ainda estou bem no inicio. No caso optei com gerar um rash de todos os arquivos do sistema(jar, executaveis, bancos embarcados, etc), e armazar esse rash em um xml que mapeia a localização dos arquivos. Então, quando o usuário iniciar o programa ele starta o atualizador primeiro, semelhante um cliente de MMO por exemplo. Se houver internet ele vai baixar o xml de um ftp, e comprar os rashs. Os que estiverem diferentes ele faz o download do respectivo arquivo, verifica se esta ok(não corrompeu), substitui o antigo e atualiza o xml. Então o atualizador starta o sistema ja atualizado e fecha.

Uma vez iniciado o sistema verificará se existe atualização do atualizador, num processo parecido.

Se alguem tiver dicas para facilitar o desenvolvimento, ou achar que não é uma boa estratégia, por favor, contribua =D

Grato a todos,
Diego[/quote]

Somente se atente se o software foi iniciado com os jars atualizáveis no classpath. Se for, a atualização pode não surtir efeito porque as classes atualizadas já podem ter sido carregadas antes da atualização.[/quote]

Mas nesse caso o atualizador seria um sistema separado, inciado antes da aplicação. O sistema principal só seria estartado após a atualização. E quanto a reescrever o sistema para modulariza-lo é algo fora de questão, infelizmente.[/quote]

Então não creio que terá problemas. É uma boa forma de se atualizar o software.

Você pode, também, fazer uma verificação de atualização não no início do sistema, mas no decorrer do seu uso e, caso seja necessário atualizar, grave essa informação em um arquivo que será lido na próxima vez que o usuário iniciar o sistema. Dessa forma você minimiza o tempo necessário para inicialização caso não haja atualizações. Um bônus seria poder notificar o usuário da atualização e até reiniciar o sistema para que ela seja feita (se o usuário escolher fazer isso, claro), dá um toque legal.

#24

[quote=Ataxexe][quote=ezaack][quote=Ataxexe][quote=ezaack][quote=drsmachado]A primeira coisa a fazer é distribuir teu software em várias partes. Isso fará com que você tenha partes distintas que podem ser atualizadas de forma independente.
A segunda é definir uma estratégia de atualização (lembrando que você deve considerar os riscos e permitir que um “downgrade” seja possível).[/quote]

Comecei a desenvolver um atualizador que segue mais ou menos esse principio, mas ainda estou bem no inicio. No caso optei com gerar um rash de todos os arquivos do sistema(jar, executaveis, bancos embarcados, etc), e armazar esse rash em um xml que mapeia a localização dos arquivos. Então, quando o usuário iniciar o programa ele starta o atualizador primeiro, semelhante um cliente de MMO por exemplo. Se houver internet ele vai baixar o xml de um ftp, e comprar os rashs. Os que estiverem diferentes ele faz o download do respectivo arquivo, verifica se esta ok(não corrompeu), substitui o antigo e atualiza o xml. Então o atualizador starta o sistema ja atualizado e fecha.

Uma vez iniciado o sistema verificará se existe atualização do atualizador, num processo parecido.

Se alguem tiver dicas para facilitar o desenvolvimento, ou achar que não é uma boa estratégia, por favor, contribua =D

Grato a todos,
Diego[/quote]

Somente se atente se o software foi iniciado com os jars atualizáveis no classpath. Se for, a atualização pode não surtir efeito porque as classes atualizadas já podem ter sido carregadas antes da atualização.[/quote]

Mas nesse caso o atualizador seria um sistema separado, inciado antes da aplicação. O sistema principal só seria estartado após a atualização. E quanto a reescrever o sistema para modulariza-lo é algo fora de questão, infelizmente.[/quote]

Então não creio que terá problemas. É uma boa forma de se atualizar o software.

Você pode, também, fazer uma verificação de atualização não no início do sistema, mas no decorrer do seu uso e, caso seja necessário atualizar, grave essa informação em um arquivo que será lido na próxima vez que o usuário iniciar o sistema. Dessa forma você minimiza o tempo necessário para inicialização caso não haja atualizações. Um bônus seria poder notificar o usuário da atualização e até reiniciar o sistema para que ela seja feita (se o usuário escolher fazer isso, claro), dá um toque legal.[/quote]

Muito boa a ideia, acho q vai ser interessante. O cliente deu a entender que a atualização deveria ser algo um pouco foçado, ja que esse sistema esta a integrado a outros, e todos devem estar em sintonia, mas vou levantar a questão com ele =)

#25

acho que a lógica é essa:

1- no servidor você lança a nova versão com todos os arquivos
2- usuário clica no jar que na verdade é um atualizador.
3- o atualizador faz uma requisição http para o servidor e verifica se versão do servidor > versão atual e se Atualizacao == Obrigatoria, se sim, atualizador solicita permissão para atualização
4- Se usuário clica em Sim -> faz uma cópia da aplicação atual e salva em um diretório chamado backup(versao), e salva o diretório original em uma variavel.
5- Se usuário clica em Não e Atualização == Obrigatória, informa mensagem para o usuário dizendo que só é possivel utilizar a aplicação após a atualização (usuário neste caso deveria manter conexão com internet, ou ele continuaria usando a versão antiga do programa.)
6- Servidor compara o Hash e verifica se existem arquivos novos, se sim calcula o total em Mb de todos os arquivos, coloca uma barra de progresso conforme o usuário vai baixando, calcula quantidade de Mbps e coloca um tempo de duração.
7- após toda cópia ele faz uma busca recursiva gerando hash de todos os arquivos que foram copiados, e compara os mesmos com o servidor.

8- durante todo o processo de atualização o sistema faz try-Catch e caso ocorra excessão em qualquer ponto salva em um arquivo (atualizacao).log, envia um post para o servidor contendo a exception/ou e-mail, e mais importe, exclui os arquivos da instalação FAIL e volta o diretório backup(versao) para o diretório original.

eu faria esse feijão com arros, outra forma de se fazer é Zipar a aplicação dividir com o winRar em partes minusculas, e salvar toda a nova versão em um diretório, depois você só renomeia a versão antiga e coloca a nova no lugar em seguida Descompacta os arquivos…dessa forma se o usuário cancelar/internet cair sei la, você apenas compara o hash do ultimo arquivo e se estiver OK você continua a cópia.

#26

O que normalmente eu utilizo nos meus projetos para resolver esse tipo de problema(poder atualizar partes críticas de um sistema) é criar uma arquitetura modular(de plugins) usando reflections do java. É possível implementar as partes totalmente desacopladas da aplicação.

Um exemplo é um software de cftv no qual o driver de cada câmera é um jar a parte como um plugin. Você coloca numa pasta e o sistema encontra o mais adequado para a reprodução de cada câmera.

#27