-bash: adb: command not found

E ai pessoal, tudo bem?

Manja quando você quer usar o ADB, 9patch, etc... na melhor das intenções pelo shell, vc faz aquele export do platform-tools/tools/sdk do android ai no dia seguinte vc vai tentar acessar o adb novamente e ele fala:

-bash: adb: command not found                                              

Pois é, ao adicionar algo no $PATH usando export direto no shell ele realmente vai atualizar o seu $PATH, o problema é que sempre que você reiniciar ou iniciar uma sessão o shell vai resetar o seu $PATH de acordo com o que está nos arquivos de profile (mais sobre profile) do seu sistema operacional.

E como eu faço para deixar meu $PATH atualizado para sempre!?

Simples! Se você, assim como eu, está usando o bash, adicione os caminhos que você precisa no arquivo .profile! No meu caso é o .bash_profile. Para fazer isso, utilize seu editor de texto preferido e abra o .bash_profile, ele está localizado na raiz do seu sistema operacional, só fazer assim ó:

vim ~/.bash_profile

Após abrir o arquivo adicione estas linhas a ele (Varia de acordo com os caminhos do seu SDK, Platform tools e tools, por padrão no mac está sendo esse caminho usando o Android Studio):



Salve o arquivo :x

Calma! Ainda não da pra usar o adb, 9patch,etc... Antes disso vc precisa dar um refresco no seu shell. Use o comando:

source ~/.bash_profile

Ai já era, ele irá dar o refresh e tudo estará funcionando nos conformes.

Por hoje é só :)

Tenham uma ótima semana.

Read More

iPhone - Gerando o Brigding Header sem o auxílio do XCode

E ai pessoal, tudo bem?

O Bridging Header é um header *.h que "linka" *.m com o seu projeto swift, é bom porque da pra reutilizar código feito em Objective-C no Swift, tive de utilizar o Bridging Header pois eu estava integrando meu projeto com o FacebookSDK e com o Parse.

O Bridging Header não é gerado automaticamente ao criar um arquivo *.m como é descrito AQUI? 

Gera sim, mas eu fiz besteira e o XCode não estava gerando o *.h pra mim!

E o que aconteceu?

Terminando de integrar o Parse ao meu projeto, notei que havia deixado o arquivo Bridging Header jogado no meio das classes de código referente ao aplicativo. A primeira coisa que pensei foi “A, vou organizar :D”. Achei que ia ser algo automático assim como eclipse, intelij, etc… E no fim das contas eu acabei fodendo com meu projeto mais uma vez huahuahuahu.

Bem, o que aconteceu, quando troquei meu Bridging header de pasta ele ficou com a referência antiga configurada no meu Build Settings, da mesma forma como achei que tirando e colocando uma framework a IDE magicamente ia organizar minhas referências eu fiz o mesmo com o Bridging Header, apaguei e já era.

No fim das contas a IDE apagou a referência do Bridging Header (eu nem sabia aonde a referência ficava na verdade, presumi isso porque o erro de Bridging header not found parou de aparecer). Continuando nesse raciocínio eu pensei “Agora é a hora de gerar novamente o Bridging Header usando a facilidade do XCode", gerei um arquivo *.m do Objective C  e fiquei esperando aparecer essa janelinha batuta:

A janelinha batuta não apareceu...

No fim das contas eu criei um MEU_PROJETO-Bridging-Header.h coloquei minhas importações e tive que enfiar a referência manualmente la no target dentro do Build Settings.

Por fim, feito isso o XCode localiza seu Bridging Header e qualquer importação feita de frameworks desenvolvidas em Objective C vai funcionar.

Boa semana!!

Read More

iPhone - Warning directory not found

E ai pessoal, tudo bem!?

Estava iniciando um novo projeto para iOS usando Swift no XCode, fiz o import errado do Parse, joguei ela de uma pasta fora do meu projeto e falei para associar o caminho, depois eu me toquei disso e preferi colocar essa framework direto na pasta do meu projeto. 

Enfim, joguei 3x a mesma framework no meu projeto de locais diferentes do meu computador. A referência da primeira e da segunda importações não saiu do meu Build Settings quando eu deletei os arquivos.

Consequentemente eu consegui importar com sucesso, mas o meu XCode ficou com um warning bem chatinho dizendo que a pasta não foi achada: 

Enfim, limpei o projeto, abri e fechei, fiz o diabo e esse maldito warning não saiu. A única forma de tirar essa referência foi fuçar no Build Settings do projeto e procurar pelas referências perdidas. 

Fiz essas alterações pelo vim para ter certeza que não tinha sobrado nada. Bastou deletar as linhas que continham as referências erradas do arquivo ~/meu_projeto.xcodeproj/project.pbxproj

Da para fazer pelo próprio Build Settings do XCode procurando pelos caminhos errados.

É isso ai, deletei, funfou, e bola pra frente :)

Abraços e até o próximo post!

Read More

Android, Rodando o ProGuard

E ai pessoal, tudo bem!?

Está chegando perto do dia do lançamento do seu aplicativo!? Você não quer pessoas bisbilhotando seu código fonte? Você também quer dar uma otimizada no tamanho do seu app? Para resolver estes problemas podemos utilizar o ProGuard! Ele serve para fazer obfuscation no seu código e além disso diminui um pouco o tamanho do seu app. Ele gera alguns arquivos dump, mapping, seeds e usage, eles servem para "desofuscar" o código e ver informações do projeto, depois falo um pouco mais a respeito.

Na prática, logo que você cria um projeto android, seja ele Eclipse ou Android studio, na raiz do seu projeto vai ser gerado os arquivos proguard-android e proguard-project caso não estejam ai basta pegar no caminho: {sdk.dir}/tools/proguard, nesta pasta existe um proguard bonitinho default que funciona numa boa sem precisar setar muitas coisas caso você não tenha muitas bibliotecas importadas.

Habilitando no Eclipse

Para iniciar com o proguard no eclipse a primeira coisa que você precisa fazer para habilita-lo é ir até o arquivo project.properties na raiz do seu projeto e apagar o comentário na linha de código que contém o proguard, provavelmente haverá algo do gênero escrito:

proguard.config=${sdk.dir}/tools/proguard/proguard-android.txt:proguard-project.txt

obs.: Neste caso você troca o {sdk.dir} pela raiz do seu projeto, caso o arquivo que você deseja usar tenha de ser customizado.

Habilitando no Android Studio

Já no Android Studio é necessário setar algumas informações no build.gradle, dentro do nó android no seu build.gradle adicione:

Isto vai fazer com que o gradle identifique seu *.txt como um arquivo do proguard.

Configurando o proguard

Eu utilizo o proguard-project para colocar as regras relativas ao meu projeto, pra ficar mais “customizado” eu troquei a palavra project pelo nome do meu projeto.

A princípio ele vem com algumas coisas pré definidas para que determinados elementos não sejam ofuscados, um dos pequenos problemas que eu tive foi com a sdk do facebook. Ele da uma embaralhada em alguns métodos e assinaturas que prejudicam em tempo de execução.

Para corrigir isso eu adicionei:

E além disso também coloquei um keep para o Parse pois utilizo ele para ajudar no oAuth.

Bem, se você usa testes, é realmente necessário que você adicione exceções para os warnings das bibliotecas que você utiliza, alguns exemplos são:

Caso você tenha alguma outra biblioteca que está dando problema usando o proguard, de uma olhadinha no google, varios desenvolvedores já deixam os pre-sets do proguard especifico para as bibliotecas direto no site do produto. Alguns exemplos:

Google playservices + Proguard

Crashlytics + proguard

Parse + proguard

Facebook + proguard (No fim do get started tem todas as informações a respeito)

Não gostou do proguard? Veja estas outras alternativas, escreva sua avaliação e manda pros brothers!

http://www.preemptive.com/products/dasho/overview

http://dexprotector.com/

http://www.allatori.com/features/android-obfuscation.html

https://www.saikoa.com/dexguard

Por enquanto é isso, até mais pessoal, boa semana!

Read More

Vi Cheat Sheet

E ai pessoal, tudo bem!?

Mais um daqueles posts bem rápidos com informações que eu acho legal guardar.

O editor de texto que uso no shell é o Vi (principalmente para editar meus commits do git), fiz uma cola para relembrar os comandos que eu utilizo mais:

:wq / :x = Salvar e sair

:q = Sair com segurança, caso tenha alguma alteração ele te avisa

:q! = Sair e ignorar mudanças

i = Começar a alterar o texto

Movendo o cursor

e = move o cursor para o fim da palavra

b = move o cursor para o começo da palavra

$ = Move o cursor para o fim da linha 

0 = Move o cursor para o inicio da linha

L = Move o cursor para a ultima linha do arquivo

H = Move a primeira linha do arquivo

Buscando

/palavra_para_procurar = procura uma palavra

n = vai para o próximo resultado

N = vai para o resultado anterior

Por enquanto é isso ai, tenham uma ótima semana!

Tenho preparado alguns posts sobre git, ruby e integração do gamecenter no iOS, logo logo eu solto eles pra vocês!

Read More

Status bar height

Pessoal, tudo bem!?

Para os designers que estão sondando por informações de tela, etc...

Estava procurando hoje tamanhos de status bar e achei algo um tanto que relevante para Android (peguei do Emirweb) :

Iphone: independente da versão: 20 px, peguei do iDev101

Windows phone: 32px portrait, 72px landscape Microsoft

Falou pessoal e até o próximo post!

Read More

Testes automatizados com TestDroid, AppThwack,TestObject e Xamarin TestCloud

Pessoal, tudo bem?

Hoje eu estava em um dilema sobre plataformas que podemos utilizar para fazer testes automatizados em aparelhos reais. Atualmente temos um problema muito grande com o porting de aplicativos Android por conta da fragmentação da plataforma, atualmente temos cerca de 18 mil (18.000) aparelhos únicos de fabricantes diferentes espalhados pelo mercado. 

Voltando as plataformas de teste, testei 3 delas:  TestDroid , AppThwack e TestObject. Estou esperando a resposta de uma quarta Xamarin-TestCloud

Alguns dados que anotei durante os testes:

TestDroid: 

• +280 devices;
• Ferramentas de teste adicional: Monkey Teste/TestDroid Recorder/Robotium;
• Stress test customizável: pode utilizar nome do usuário e senha para login;
• Customização dos devices: Nenhuma;
• Integração contínua com Jenkins;
• Pode testar em um aparelho físico; 
• Plano mensal mínimo: $599,00;

AppThwack: 

• +300 devices
• Ferramentas de teste adicional: Monkey Teste/Calabash/JUnit/MonkeyTalk/UiAutomator
• Stress test customizável: pode utilizar nome do usuário e senha para login;
• Integração contínua com Jenkins;
• Não pode testar em aparelho fisico;
• Plano diario: $75,00 ou $20 200 minutos de teste (Cada aparelho dura em média 4 minutos o teste);

TestObject: 

• 40 devices;
• Ferramentas de teste adicional: Robotium;
• Stress test padrão;
• Integração contínua com Jenkins;
• Pode testar em um aparelho físico;
• Plano de minutos $20 100 minutos de teste (Cada aparelho em média 3 minutos);

Xamarim TestCloud:

• Aguardando contato de um consultor para disponibilizar mais informações, uma demo e testar;
• 800 devices;
• Ferramentas de teste adicional: Calabash;
• Integração contínua com Jenkins, Team City e TFS;
• Teste em aparelho físico:?;
• Planos:?;

Optei pelo AppThwack por enquanto, com ele é possível re-utilizar a suite de testes Calabash (a que eu estou usando atualmente), dessa forma posso reutilizar os códigos de teste.

Os códigos feitos em calabash podem ser utilizados também nos celulares que tenho na empresa, com o celular plugado no USB, o re-aproveitamento será maior e o re-trabalho desenvolvendo testes em outras suites será menor. 

O AppThwack também pode ser integrado com o Jenkins de forma bem simples, deixando as práticas ainda melhores.

Por enquanto é isso!!

Bom fim de semana pessoal!

Read More

Android - gerando HASH's para o facebook

E ai pessoal, tudo bom!?

Hoje vou tratar de um assunto bem simples! Como gerar aquela hash marota para testar e fazer o release do seu app Android com o facebook integrado. Para integrar o facebook em minhas aplicações eu utilizo o Parse um serviço comprado pelo próprio facebook a algum tempo atras.

Bem, vamos la:

HASH de Debug 

Para testarmos o aplicativo no facebook, precisamos colocar no developer.facebook.com uma Hash gerada a partir da debug.keystore. Ela sempre é usada quando você gera aquela build apertando debug/run no seu AndroidStudio, Eclipse,etc...

Esta key fica por padrão na pasta .android da raiz do seu sistema operacional. Para pegar a hash que será utilizada no developer.facebook.com, basta você ir no terminal e digitar:

keytool -exportcert -alias androiddebugkey -keystore ~/.android/debug.keystore | openssl sha1 -binary | openssl base64

Obs.: Se pedir senha o padrão é android

Mais informações: Facebook Dev

HASH de Release

Após fazer os testes do app e lapida-lo, está na hora de lançar na PlayStore, você vai precisar adicionar uma hash gerada pela sua keystore de release. Para isso basta digitar no seu terminal:

keytool -exportcert -keystore NOME_DA_KEYSTORE -alias NOME_DA_ALIAS | openssl sha1 -binary | openssl base64

Obs.: Se pedir senha, é a senha da sua keyStore

Adicionando a hash no facebook.

Entre no developer.facebook.com, no canto superior esquerdo da tela, clique em Apps:

Selecione o aplicativo ou crie um novo, após criar ou selecionar um aplicativo já criado, selecione settings.

Vá até o final clique em add platform, adicione o Android como uma nova plataforma, em package name adicione o identificador do seu projeto com.meu.projeto a classe que servirá de callback e o Hash com um simbolo de "=" no final.

E pronto! Está tudo certo.

Não esqueça de colocar o appId e o appSecret no serviço que você utilizar para integrar o facebook ou na própria SDK do facebook.

Abraços e até o próximo post!!

Read More

Android - UNEXPECTED TOP LEVEL EXCEPTION na migração

E ai pessoal, tudo bom!?

O primeiro post que pretendo fazer é a respeito da migração de um projeto Android feito inteiramente em Eclipse ADT para o Android Studio, em relação ao problema que eu tive, fiquei bem puto durante a migração pois não manjava nada de Gradle nem de Maven, acabei investindo algum tempo estudando os 2 para entender o que estava acontecendo. Meu projeto vivia dando: UNEXPECTED TOP LEVEL EXCEPTION e problemas de importação cíclica com a Android Support V4.

Meu projeto atual tem relativamente poucas bibliotecas de apoio, uso estas 5: app.compat.V7, Support Lib V4,facebookSDK,ViewPagerIndicator e MixPanel.

Bem, comecei seguindo o tutorial de migração disponível no site do próprio AndroidDev Site , ele fala para no próprio eclipse utilizar a ferramenta de migração e selecionar o projeto desejado, nessa hora eu selecionei todos os meus projeto principal e todas as bibliotecas que estavam atreladas ao projeto.

Pelo que entendi, isto fez com que eu tivesse um problema de dependências cíclicas pois meu projeto utilizava a android support v4, o projeto do MixPannel, o do Facebook e o app.Compat.V7 também utilizavam, no eclipse este mesmo problema é conhecido como jar mismatch, tive frequentemente este erro UNEXPECTED TOP LEVEL EXCEPTION após corrigir os problemas de importação.

Para corrigir o UNEXPECTED TOP LEVEL EXCEPTION, eu apaguei todas as referências que tinha da biblioteca support v4 do android. Em seguida pelo android SDK manager fiz o download da ultima versão da support library v4 e do support repositor.

Terminados os downloads eu cliquei com o botão direito sobre o projeto  fui na opção open module;

Selecionei o projeto que depende da lib support v4

Cliquei em Dependencies

E lá no rodapé apertei no "+" para adicionar uma biblioteca de dependencia do próprio SDK

No fim selecionei a biblioteca support v4

E prontinho!

Para finalizar e acabar com o UNEXPECTED TOP LEVEL EXCEPTION eu adicionei no build.gradle da raiz do projeto:

configurations {

    all*.exclude group: 'com.android.support', module: 'support-v4'

}

**** FORA DO BUILDSCRIPT

Isto faz com que a support library v4 pare de ser exportada por outras dependências do projeto que não seja as bibliotecas importadas e seu projeto principal. Um workaround que achei no Stackoverflow.

Por enquanto é isso ai :)

Abraços!

Read More

Inauguração

E ai pessoal! Beleza?

Meu nome é Bruno, sou desenvolvedor mobile desde o início da minha carreira profissional, comecei por volta de 2008.

Hoje trabalho em uma startup chamada EmpregoLigado, nosso objetivo é ajudar pessoas com cargos operacionais acharem empregos próximos as suas casas, usamos bastante geolocalização :).

Usarei este blog como um cookbook, todas as coisas que eu for fazendo ou achar interessante a respeito de desenvolvimento mobile vou colocar neste blog.

E é isto :)

Abraços e boa semana!

Read More