14 Apr 2015
Eu nunca pensei que iria usar tantas coisas da Adobe, aquela empresa dona do cara rápido da DC, mas ultimamente com o brackets e o que estão fazendo com o PhoneGap, estou gostando dela mas ainda não sou um bitch da Adobe.
Vou apresentar um recurso indispensável para quem pretende tirar o máximo de proveito do PhoneGap o PhoneGap Developer App.
PhoneGap Developer App é um aplicativo para Android, iOS e Windows Phone capaz de rodar aplicações que estão sendo desenvolvidas através deste framework.
É possível rodar um servidor em rede local que poderá ser acessado pelo PGDA e com isso testar e utilizar o aplicativo em tempo real, direto no smartphone ou tablet. Isso tudo sem downloads e uploads do App. Todo o processo é feito via rede wireless.
O único requisito é o computador que esta sendo utilizado no desenvolvimento estar na mesma rede do dispositivo mobile. No site oficial do PGDA você encontrará toda a documentação necessária para utilizar o recurso. Não fique preocupado, tudo é muito simples.
É só entrar na pasta onde foi criado o projeto em PhoneGap e executar um comando: phonegap serve (serve mesmo, não server)
No terminal sera gerado um endereço de ip, onde sera colocado no aplicativo, muito simples, todas as alterações feitas no projeto são automaticamente alterada no app.
Para cancelar aperte control + c no terminal de comando
Viu? muito simples, melhor do que esperar um ano para o emulador do Android ser aberto. =)
@carlosgodri
17 Mar 2015
Meus poderes de montagens, são mais de 8 MILLLLL
Olá Pessoal, vou mostrar como é fácil gerar uma chave privada para, as suas aplicações feitas para Android, você vai precisar de apenas que ter o JAVA JDK, meu sistema operacional que estou usando é o Linux Mint, mas o processo é bem similar nos outros sistemas operacionais.
O sistema Android requer que todas as aplicações instaladas sejam assinadas digitalmente com um certificado cuja chave privada é mantida pelo desenvolvedor. O Android usa o certificado como um meio de identificar o autor da aplicação e estabelecer uma relação de confiança entre as aplicações.
O certificado não controla que aplicações o usuário pode instalar. Ele não precisa ser assinado por uma autoridade certificadora: é perfeitamente permitido, e tipico, aplicações Android usarem certificados auto-assinados.
Nesse tutorial vamos apenas gerar a chave privada, em outro tutorial vamos publicar um aplicativo desenvolvido com Phonegap (Mas isso é outro tema que vamos abordar mais para frente), então…
Atenção
Depois de gerada a chave siga as recomendações abaixo para manter a longevidade de sua aplicação, que estará publicada
- Esteja em sua posse
- Represente a entidade pessoal, corporativa ou organizacional que será identificada com sua aplicação
- Tenha um período de validade que exceda o tempo de vida esperado da aplicação. Um período de validade de 25 anos é recomendado. Se você planeja publicar sua aplicação no Google Play, observe que um período de validade que termine depois de 30/11/2034 é necessário; Você não poderá fazer upload de um apk se este estiver assinada com uma chave cuja validade expire antes dessa data.
- Guarde a senha que você gerou assim como o Alias da aplicação.
Caso tenha mais alguma dúvida, leia o artigo Securing Your Private Key
####Chega de blá, blá porque agora é mão na massa.
Para gerar a chave vamos usar o comando e ferramenta do JDK o Keytool.
Vamos abrir o terminal se preferir use o Ctrl+Alt+t:
keytool -genkey -v -keystore "nomeDaChave.keystore" -alias NomeChave -keyalg RSA -validity 10000
Precione Enter, digite a senha para a chave.
Logo em seguida aparecera informações que você deve preencher.
Depois pedira para confirmar com Sim ou Não seus dados e escolha a opção adequada…
Tudo ocorrendo com planejado, aparecerá um dialogo pedindo que você digite outra senha para a chave gerada, ou se quiser usar a mesma senha que colocou no começo apenas digite RETURN.
Como não escolhemos um diretorio, por padrão o keytool vai gerar a chave na pasta home
Simples assim
###Mas o que significa cada comando do Keytool?
keytool -genkey -v -keystore "nomeDaChave.keystore" -alias NomeChave -keyalg RSA -validity 10000
Vamos por partes
- Morgan, Dexter
Gera um par de chaves (pública e privada)
Ativa o modo verbose
Um nome para a keystore que conterá sua chave privada.
Um apelido para a chave. Apenas os 8 primeiros caracteres do apelido são usados.
Algoritmo de encriptação usado para geração da chave. Tanto o DSA quanto o RSA são suportados.
O periodo de validade da chave, em dias. Um valor de 10000 ou maior é recomendado.
Outros comando uteis, mas não necessários
O tamanho de cada chave gerada (bits). Se não fornecida, Jeytool usa um tamanha padrão de 1024 bits. Em geral, é recomendado uma chave de 2048 bits ou maior.
Um nome único que descreva quem criou a chave. O valor é usado nos campos issuer e subject nos certificados auto-assinados.
Observe que você não precisa especificar essa opção na linha de comando. Se não fornecida, o Jarsigned lhe pedirá para informar cada campo Nome Único (CN, OU, e assim em diante).
A senha para essa senha.Como precaução de segurança, não inclua essa opção na linha de comando. Se não fornecida, o Keytool pedirá que você informe a senha. Desta maneira, sua senha não será armazenada no histórico do shell.
Uma senha para a keystore.
Como precaução de segurança, não inclua essa opção na linha de comando. Se não fornecida, o Keytool pedirá que você informe a senha.
Isso é tudo pessoal!
28 Feb 2015
JSON é um acrônimo para “JavaScript Object Notation”, é um formato leve para intercâmbio de dados computacionais. JSON é um subconjunto da notação de objeto de JavaScript, mas seu uso não requer JavaScript exclusivamente.
a enciclopédia livre, Wikipédia
####Afinal, o que é JSON?
JSON é como diz a Wiki é basicamente um formato leve de troca de informações/dados entre sistemas. só podendo usar com JavaScript correto? Na verdade não e alguns ainda caem nesta armadilha.
O JSON além de ser um formato leve para troca de dados é também muito simples de ler. Mas quando dizemos que algo é simples, é interessante compará-lo com algo mais complexo para entendermos tal simplicidade não é? Neste caso podemos comparar o JSON com o formato XML.
###XML
###JSON
{"id":1,"nome":"Joao da Silva", "endereco":"R. Dos Bobos"}
Muitas das suposições sobre o quão lento, dispendioso e “gordo” o XML é se comparado à leveza do JSON, não foram sustentadas pelo teste feito por David Lee, engenheiro líder na Marklogic, após a execução de um experimento “crowd sourcing” com 33 documentos diferentes e aproximadamente 1200 testes, em uma grande quantidade de navegadores e sistemas operacionais mais utilizados. David afirma ter descoberto que o desempenho total da experiência de usuário ‒ transferência, análise (parsing) e consulta (querying) de um documento ‒ é quase idêntico em ambos os formatos: XML e JSON.
Para o seu experimento David criou e divulgou publicamente um ambiente de teste que imita um caso de uso em que documentos XML e JSON são entregues por um servidor web, para serem analisados e consultados em um navegador web.
O servidor abastece o cliente com uma fonte de dados, e coleta os resultados provenientes do cliente. O cliente é uma aplicação JavaScript executada no navegador, codificada especificamente para medir performance, exceto a parte que faz as medições de desempenho do jQuery.
Além de usar sete documentos diferentes com tamanhos entre 100Kb e 1Mb, e cada documento apresentar duas variantes JSON e três variantes XML, David também tentou cobrir uma gama de dispositivos, navegadores, sistemas operacionais e redes em seu teste. Ele fez isso através de “crowd sourcing”, ou seja, tornou pública a URL do ambiente de testes e divulgou em várias listas de e-mail e sites de mídia social. O resultado de aproximadamente 1200 testes distintos e bem sucedidos foram coletados até agora, abrangendo os navegadores e sistemas operacionais mais utilizados. Em seu artigo, David documentou todos os dados do teste, bem como os seus resultados.
Algumas das conclusões obtidas após a experiência de David são:
- A velocidade de análise (parsing) varia de acordo com a técnica usada. A análise com JavaScript puro é mais rápida para XML do que para o JSON, enquanto a consulta é normalmente mais rápida para o JSON. Ambos apresentando exceções, em que o contrário é verdadeiro.
- O uso da biblioteca JavaScript jQuery impõe uma penalidade exagerada para o JSON, e pior ainda para o XML.
- Documentos compactados em todos os formados, mesmo representações muito grandes em JSON ou XML apresentam tamanho idêntico após a compressão, o que indica que ambos possuem o mesmo conteúdo de informação.
- A transferência de documentos para uma grande variedade de dispositivos leva efetivamente o mesmo tempo em cada dispositivo, independentemente do formato adotado (XML ou JSON).
Baseando-se em seu experimento, David inclui algumas sugestões para arquitetos e desenvolvedores:
- Usar Compressão HTTP, na maioria das vezes, é o fator mais importante no desempenho total.
- Otimizar a marcação para transmissão e consulta.
- Não tentar otimizar, a menos que a transmissão de dados, a análise e a consulta sejam problemas significativos se comparados às outras questões.
