1- O Boonzi está em captive. Não dependemos do Air, e nenhum dos nossos
clientes vê sequer a palavra "Adobe"
2- Antigamente usávamos um install wizard qualquer (installshield? não
me recordo), mas tinha a desvantagem do user ter que descarregar 30Mb na
sua primeira interacção connosco. Too much.
3- Cagamos no wizard, e fizemos uma aplicação ranhosa em C que ocupa uns
500kb em cima do NSIS, que o que faz é:
3.1- Vai ao servidor ver qual é a versão mais recente (sacando o nosso
changelog)
3.2- Saca a versão mais recente (é um ZIP), descomprime para a pasta
correcta, e arranca o Boonzi
3.3- Em Air, temos um serviço que vai de vez em quanto ao servidor ver
se há uma versão mais recente. Se houver, saca-a em background, e depois
do utilizador autorizar 3.3.1 O Boonzi arranca o nullsoft installer
3.3.2 o Boonzi fecha-se 3.3.3 o Nullsoft installer detecta que há uma
versão nova em cache no disco e nem sequer vai ao servidor. Grava-a e
arranca o Boonzi
3.4- Em Mac usamos uma aplicação qualquer (paga) para fazer um wrapper
ao Air
Isto deu algum trabalho a montar, mas simplifica *muito* uma release:
1- No Idea, geramos a release.
2- Depois assinamos o .exe (para nos livrarmos dos avisos do Windows)
3- Apagamos uns ficheiros da release (webkit, p. ex) para que a
aplicação fique a ocupar uns 15Mb, e comprimimos num ZIP que tem o nº de
versão no nome.
4- Depois alteramos o changelog colocando o novo numero de versão e
enviamos tudo para o servidor. Pronto, release feita.
Uma release é basicamente colocar um zip no servidor, e alterar o nº de
versão no changelog.
Depois o que acontece, é que o Boonzi detecta a nova versão, e faz os
passos acima. Simples.
Em termos de espaço:
1- installer: boonzi-setup.exe: uns 600kb
2- pacote de update: uns 15Mb
A unica desvantagem é que alguns anti-virus (i.e. McAffee) não gostam
muito do NSIS, e volta e meia temos alguns clientes a queixarem-se que o
installer tem vírus. Depois lá tenho que enviar email à McAfee, que
resolve o problema por 15 dias... Face a todas as vantagens acima (para
o end-user, e para o development), compensa viver debaixo do fascismo da
McAfee. :o)
JS
On 23/02/2017 13:01, Hugo Ferreira wrote:
Isto veio tudo à baila porque passou a existir (em beta) o AIR de
Windos para 64 bits como já havia à anos para Mac mas só suportado em
captive runtime.
Existem vários casos de aplicações com uso intensivo que precisam de
consumir muito memória e não faz sentido o hardware de hoje em dia ter
essa disponibilidade mas o software limitar.
No dia 23 de fevereiro de 2017 às 12:55, Hugo Ferreira
<[email protected] <mailto:[email protected]>> escreveu:
João,
Isso na realidade já é suportado à algum tempo na generalidade das
Apps, ou seja, é um problema já resolvido na própria loja (pelo
menos para Android) e existem ANEs para ajudar nesse processo para
o caso de Apps em AIR mobile.
Ai o problema já se encontra resolvido e sinceramente acho que
para mobile não me importo que a App ocupe mais uns 20 MB e acho
que não vale o esforço (no entanto acho muito útil para jogos com
centenas de MB).
Aqui o que estamos a falar é do AIR para Windows (fora de uma
loja) que pode ter updates muito regulares e o ambiente desktop é
diferente do mobile.
Seja como for a solução há de ser semelhante, ou seja, partir em 2.
No dia 23 de fevereiro de 2017 às 12:49, João Fernandes
<[email protected]
<mailto:[email protected]>> escreveu:
O tamanho inicial, esse será sempre complicado diminuir no
entanto a PlayStore tem otimizado o processo de deploy de
updates e acho que já está em produção o sistema que na
realidade só obriga a descarregar os deltas entre as versões o
que diminui bastante o download dos upgrades.
2017-02-23 12:40 GMT+00:00 Hugo Ferreira
<[email protected] <mailto:[email protected]>>:
Exatamente como descreveste. Faço updates quase todas as
semanas desde à bastante tempo entre Windows e Macs.
Compilas em AIR e apenas atualizas o ficheiro AIR no
servidor e no ficheiro xml que está ao lado, atualizas o
número da versão (que serve para a framework comparar e
decidir se necessita ou não de atualizar) e não tens de
fazer mais nada.
Como é só o AIR (a tua App, o upload é muito rápido e o
download depois também).
É super prático, não envolve quase nenhum código e
funciona bem muito (até em Linux funciona).
A grande desvantagem é que a primeira instalação em
Windows por vezes pode dar raia se a máquina do cliente
tiver problemas nos registos, tal como acontece com
qualquer outro instalador mas uma vez instalado, nunca
mais tem problemas (os updates são internos da App, não
envolve o registry).
Uma desvantagem é que a framework de update demonstra bem
que é AIR na janela de update e assim dá um aspeto um
pouco menos profissional mas isso é só para nós. Os
utilizadores não fazem a mínima ideia e gostam que seja
tudo automatico, simples e rápido.
Esta lib que mencionei no e-mail anterior "pareçe" ser uma
cópia opensource da framework de updates do AIR SDK mas
redesenhado para captive runtime, permitindo no xml
indicares mais do que um ficheiro (exe, dmg, etc ...) e
segundo o autor copia por cima o exe (no caso do windows),
encerra e reabre (tenho de testar porque não deve ser bem
assim, pois o exe está em uso, devo usar um outro
processo). No caso de dmg (Mac), é o processo normal de
instalação de um dmg (mais chato do que usando AIR mas
também mais profissional).
Como a lib se aproxima ao AIR SDK, fiquei com a impressão
que a mudança deverá ser relativamente trivial para nós.
O chato é aumentar em muito o tamanho dos ficheiros e
demorar mais o downlaod para o cliente.
Quando tiver tempo poderei resolver isto mas vai envolver
algum código, ou seja, ter 2 packages (o primeiro com o
AIR + aplicação de update que eventualmente também poderá
ser atualizado e outro só com a App).
No dia 23 de fevereiro de 2017 às 12:28, Rui Cruz
<[email protected] <mailto:[email protected]>>
escreveu:
Acho que já uso esse (ou semelhante ou alterei) para
umas apps internas da empresa (mas sem
captive-runtime), e funciona bem.. no final de fazer o
download do instalador, executa o instalador e
fecha-se. depois ao abrir ja está actualizado..
No dia 22 de fevereiro de 2017 às 22:10, Hugo Ferreira
<[email protected]
<mailto:[email protected]>> escreveu:
Foi aqui que encontrei:
https://code.google.com/archive/p/nativeapplicationupdater/
<https://code.google.com/archive/p/nativeapplicationupdater/>
Isto parece que foi baseado no updater que vem com
o AIR.
No dia 22 de fevereiro de 2017 às 18:17, Hugo
Ferreira <[email protected]
<mailto:[email protected]>> escreveu:
Rui,
Já deparei com alguns casos (muito raros) de
utilizadores que não conseguem fazer a
primeria instalação da minha aplicação porque
fazem do Windows um autentico balde de lixo
com muitos anos sem nunca ter sido formatado.
Outros cenários (com pouca frequência mas
acontece) é não conseguirem instalar porque o
Windows 10 barra.
Apesar de captiva runtime aumentar o tamanho
da App, vou me livrar destes problemas e dar
uma experiência melhor, por isso agora a
adicionar os 64 bits, era a motivação que
precisava para fazer a mudança.
Acabei de ler um mecanismo de atualização que
parece que é feito da mesma forma que eu faço
hoje em dia mas com opções adicionais (que
desconhecia) que permitem encaminhar para um
ficheiro no servidor exe ou dmg em vez de air
e no caso do exe irá substituir por cima e
arrancar e no caso do dmg irá instalar por
cima (mais chato mas é mesmo assim).
Se funcionar partilho mas ainda tenho de validar.
Cumprimentos,
Hugo.
No dia 22 de fevereiro de 2017 às 18:11, Rui
Cruz <[email protected]
<mailto:[email protected]>> escreveu:
Boas Hugo,
Também gostaria de saber mais acerca desse
tópico.. de momento não tenho experiência
com runtime captive, se puderes
experimentar, vai reportando as tuas
considerações!
Sei que o Feathers SDK installer
https://github.com/BowlerHatLLC/feathers-sdk-manager
<https://github.com/BowlerHatLLC/feathers-sdk-manager>,
usa um instalador externo para win/mac.
Mas acredito que hajam soluções mais
amigáveis..
Cumprimentos :)
No dia 22 de fevereiro de 2017 às 17:58,
Hugo Ferreira <[email protected]
<mailto:[email protected]>> escreveu:
Boa tarde pessoal,
Atualmente utilizo shared runtime para
uma aplicação desktop minha.
As vantagens da opção captiva runtime são:
- 0 problemas de instalação;
- 0 conflitos entre versões do runtime
(apesar de isto ser improvável).
As vantagens da opção shared runtime são:
- Compilar no meu Mac e correr em todo
o lado (não tenho de ir a uma máquina
Windows e compilar novamente):
- Updates mais pequenos/rápidos (é
apenas a minha App e não o runtime
repetidamente);
- Funciona em Linux (se quiseres
suportar - menos importante mas possível);
- Posso usar a framework de updates do
Flex SDK que simplesmente funciona e
muito bem, com poucas linhas de código.
Caso alguém utiliza AIR captiva
runtime para desktop, como é que lidam
com os updates na vossa aplicação ?
Queria algo simples de implementar
(simples é melhor).
Porquê de agora considerar alterar ?
Porque acabou de saír a versão (em
beta) do AIR para Windows com suporte
a 64 bits e foi indicado que ficará só
suportado na versão captiva runtime.
Dá para perceber porque assim fintaram
já uma série de problemas de instalação.
Cumprimentos a todos,
Hugo.
--
Recebeu esta mensagem porque
subscreveu ao grupo "Mailing List da
Comunidade Portuguesa de Rich Internet
Applications - www.riapt.org
<http://www.riapt.org>" do Grupos do
Google.
Para anular a subscrição deste grupo e
parar de receber emails do mesmo,
envie um email para
[email protected]
<mailto:[email protected]>.
Para publicar uma mensagem neste
grupo, envie um email para
[email protected]
<mailto:[email protected]>.
Visite este grupo em
https://groups.google.com/group/riapt
<https://groups.google.com/group/riapt>.
Para mais opções, visite
https://groups.google.com/d/optout
<https://groups.google.com/d/optout>.
--
Recebeu esta mensagem porque subscreveu ao
grupo "Mailing List da Comunidade
Portuguesa de Rich Internet Applications -
www.riapt.org <http://www.riapt.org>" do
Grupos do Google.
Para anular a subscrição deste grupo e
parar de receber emails do mesmo, envie um
email para
[email protected]
<mailto:[email protected]>.
Para publicar uma mensagem neste grupo,
envie um email para [email protected]
<mailto:[email protected]>.
Visite este grupo em
https://groups.google.com/group/riapt
<https://groups.google.com/group/riapt>.
Para mais opções, visite
https://groups.google.com/d/optout
<https://groups.google.com/d/optout>.
--
Recebeu esta mensagem porque subscreveu ao grupo
"Mailing List da Comunidade Portuguesa de Rich
Internet Applications - www.riapt.org
<http://www.riapt.org>" do Grupos do Google.
Para anular a subscrição deste grupo e parar de
receber emails do mesmo, envie um email para
[email protected]
<mailto:[email protected]>.
Para publicar uma mensagem neste grupo, envie um
email para [email protected]
<mailto:[email protected]>.
Visite este grupo em
https://groups.google.com/group/riapt
<https://groups.google.com/group/riapt>.
Para mais opções, visite
https://groups.google.com/d/optout
<https://groups.google.com/d/optout>.
--
Recebeu esta mensagem porque subscreveu ao grupo
"Mailing List da Comunidade Portuguesa de Rich
Internet Applications - www.riapt.org
<http://www.riapt.org>" do Grupos do Google.
Para anular a subscrição deste grupo e parar de
receber emails do mesmo, envie um email para
[email protected]
<mailto:[email protected]>.
Para publicar uma mensagem neste grupo, envie um email
para [email protected]
<mailto:[email protected]>.
Visite este grupo em
https://groups.google.com/group/riapt
<https://groups.google.com/group/riapt>.
Para mais opções, visite
https://groups.google.com/d/optout
<https://groups.google.com/d/optout>.
--
Recebeu esta mensagem porque subscreveu ao grupo "Mailing
List da Comunidade Portuguesa de Rich Internet
Applications - www.riapt.org <http://www.riapt.org>" do
Grupos do Google.
Para anular a subscrição deste grupo e parar de receber
emails do mesmo, envie um email para
[email protected]
<mailto:[email protected]>.
Para publicar uma mensagem neste grupo, envie um email
para [email protected] <mailto:[email protected]>.
Visite este grupo em https://groups.google.com/group/riapt
<https://groups.google.com/group/riapt>.
Para mais opções, visite
https://groups.google.com/d/optout
<https://groups.google.com/d/optout>.
--
João Fernandes
--
Recebeu esta mensagem porque subscreveu ao grupo "Mailing List
da Comunidade Portuguesa de Rich Internet Applications -
www.riapt.org <http://www.riapt.org>" do Grupos do Google.
Para anular a subscrição deste grupo e parar de receber emails
do mesmo, envie um email para
[email protected]
<mailto:[email protected]>.
Para publicar uma mensagem neste grupo, envie um email para
[email protected] <mailto:[email protected]>.
Visite este grupo em https://groups.google.com/group/riapt
<https://groups.google.com/group/riapt>.
Para mais opções, visite https://groups.google.com/d/optout
<https://groups.google.com/d/optout>.
--
Recebeu esta mensagem porque subscreveu ao grupo "Mailing List da
Comunidade Portuguesa de Rich Internet Applications - www.riapt.org"
do Grupos do Google.
Para anular a subscrição deste grupo e parar de receber emails do
mesmo, envie um email para [email protected]
<mailto:[email protected]>.
Para publicar uma mensagem neste grupo, envie um email para
[email protected] <mailto:[email protected]>.
Visite este grupo em https://groups.google.com/group/riapt.
Para mais opções, visite https://groups.google.com/d/optout.
--
Recebeu esta mensagem porque está inscrito no grupo "Mailing List da Comunidade
Portuguesa de Rich Internet Applications - www.riapt.org" dos Grupos do Google.
Para anular a subscrição deste grupo e parar de receber emails do mesmo, envie
um email para [email protected].
Para publicar uma mensagem neste grupo, envie um e-mail para
[email protected].
Visite este grupo em https://groups.google.com/group/riapt.
Para mais opções, consulte https://groups.google.com/d/optout.
