-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