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

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

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