Aprenda como utilizar o ContentProvider corretamente

Vocês já pararam para pensar qual é a primeira coisa que nós temos que fazer após importarmos uma lib? Inicializá-la com contexto em uma classe Application. Se você já precisou utilizar alguma lib do Firebase, você vai se perguntar: Opa, eu nunca tive que fazer isso.

Vamos para nosso estudo de caso.

Estudo de caso

Atualmente, estamos desenvolvendo um aplicativo que utiliza Koin, Stetho e PreferenceCache. Até algumas semanas tínhamos uma classe chamada AppTemplateApplication que era responsável por inicializar nossas libs e era dessa forma

class AppTemplateApplication : Application() {

    override fun onCreate() {
        super.onCreate()
        PreferencesCache.init(this)
        if(BuildConfig.DEBUG) Stetho.initializeWithDefaults(this)
        startKoin(this, appTemplateModules)
    }
}

E essa classe precisa ser declarada em nosso AndroidManifest.xml para ser executada:

<application
    android:name=".AppTemplateApplication"
   ...
>

Imagine se fossemos adicionando mais libs ao longo da execução do projeto… Teríamos que adicionar cada inicialização em nossa AppTemplateApplication. Ou seja, em nosso projeto teríamos que sobrescrever uma Application() somente para inicializar libs.


Uma bazooka para resolver um problema 🙂

Manifest-Merger

De acordo com a documentação do android:

Seu arquivo APK pode conter apenas um arquivo AndroidManifest.xml, mas o projeto do Android Studio pode conter vários - fornecidos pelo main source set, built variants e libs importadas. Portanto, ao criar seu aplicativo, a compilação do Gradle mescla todos os arquivos de manifesto em um único arquivo de manifesto que é empacotado no seu APK.
A ferramenta de merge combina todos os elementos XML de cada arquivo, seguindo algumas heurísticas de merge e obedecendo às preferências de merge que você definiu.

E o porque estamos falando de Manifest-Merger? Se dermos uma olhada em nosso AndroidManifest, iremos descobrir como algumas libs conseguem fazer sua inicialização sem a interferência do programador que irá utilizá-la…

Em nosso Estudo de caso iremos investigar como o Firebase faz essa magia. No final do nosso AndroidManifest após o processo de merge, podemos ver o import de um provider

<provider
  android:name="com.google.firebase.provider.FirebaseInitProvider"
  android:authorities="APPTEMPLATE.firebaseinitprovider"
  android:exported="false"
  android:initOrder="100" />

Se investigarmos a classe FirebaseInitProvider poderemos ver que esse provider tem acesso ao contexto da aplicação usando this.getContext()

public boolean onCreate() {
    if (FirebaseApp.initializeApp(this.getContext()) == null) {
        Log.i("FirebaseInitProvider", "FirebaseApp initialization unsuccessful");
    } else {
        Log.i("FirebaseInitProvider", "FirebaseApp initialization successful");
    }
    return false;
}

Mas se analisarmos essa classe poderemos ver que o fato dela extender a ContentProvider a obriga implementar os métodos insert, query, onCreate, update, delete, getType.

DefaultProvider

Como vimos, a necessidade de implementar todos os métodos citados acaba tornando nosso Provider longo… Para mitigarmos esse problema, utilizaremos um DefaultProvider, uma open class.

open class DefaultProvider : ContentProvider() {
    override fun insert(uri: Uri?, values: ContentValues?): Uri { TODO("not implemented") }

    override fun query(uri: Uri?, projection: Array<out String>?, selection: String?, selectionArgs: Array<out String>?, sortOrder: String?): Cursor { TODO("not implemented") }

    override fun onCreate(): Boolean { TODO("not implemented") }

    override fun update(uri: Uri?, values: ContentValues?, selection: String?, selectionArgs: Array<out String>?): Int {TODO("not implemented")}

    override fun delete(uri: Uri?, selection: String?, selectionArgs: Array<out String>?): Int { TODO("not implemented")}

    override fun getType(uri: Uri?): String { TODO("not implemented") }
}

A partir disso, iremos fazer com que nosso provider estenda-o.

KoinProvider, StethoProvider, CacheProvider

Diante do exposto, iremos construir nossos providers.

class KoinInitProvider : DefaultProvider() {
    override fun onCreate(): Boolean {
        context?.let { startKoin(it, appTemplateModules) }
        return true
    }
}
class PreferenceCacheInitProvider : DefaultProvider() {
    override fun onCreate(): Boolean {
        context?.let { PreferencesCache.init(it) }
        return true
    }
}
class StethoInitProvider : DefaultProvider() {
override fun onCreate(): Boolean {
        if (BuildConfig.DEBUG) context?.let {     Stetho.initializeWithDefaults(it) }
        return true
    }
}

e em nosso AndroidManifest.xml

<provider
 android:name=".provider.koin.KoinInitProvider"
 android:authorities=".provider.koin.KoinInitProvider" />

<provider
 android:name=".provider.cache.PreferenceCacheInitProvider"
 android:authorities=".provider.cache.PreferenceCacheInitProvider" />

<provider
 android:name=".provider.stetho.StethoInitProvider"
 android:authorities="com.facebook.stetho.StethoInitProvider" />

Conclusão

Bom, com a utilização do ContentProvider podemos eliminar a nossa classe AppTemplateApplication.class e utilizar um recurso do Android para inicializarmos as libs que o projeto utiliza.
Além da retirada da AppTemplateApplication, notamos que todos os providers utilizam o null safety do Kotlin para atribuir o contexto a inicialização das libs.

Esse artigo surgiu de um papo de dois devs paixão, valeu Matheus Kreuz Bristot pelo café e por essa abstração show.

Ps: Quer trocar uma ideia sobre o artigo ou sobre desenvolvimento mobile? Deixa um comentário show, que vai ser um prazer responde-lo.

Texto por: Caíque Minhare e Matheus Bristot

 

 

Dinâmica É, Não É, Faz, Não Faz

Recentemente fiz o workshop de Lean Inception do Paulo Caroli durante a semana ágil do Scrum Gathering Rio.
Durante o workshop nos são apresentadas várias ferramentas para facilitar o processo da lean inception.
Na Jera já fazemos o uso dessas ferramentas, uma delas é o: É, NÃO É, FAZ, NÃO FAZ, que foi criado pelo Rafael Sabbagh da K21. Nesse vídeo há uma explicação mais detalhada.

Nas vezes em que facilitei o uso dessa ferramenta, seja pra ajudar um time a identificar seu papel ou para definir um produto, percebi que algumas pessoas ficavam com dificuldade em diferenciar o que algo É e o que algo FAZ.
Pensando em ajudar no entendimento, percebi que o que É e NÃO É, poderia ser associado com o uso de substantivos. No caso de definição de um produto, poderíamos dizer por exemplo que ele É um: aplicativo, seguro, local, etc; Para o preenchimento do FAZ e NÃO FAZ, fiz a sugestão de preencher pensando em verbos, pois expressariam uma ação ao qual o produto irá realizar, por exemplo: cadastrar usuário, filtrar um resultado, buscar.
Essas analogias facilitaram o entendimento da dinâmica, pois as pessoas começaram a ver de fato uma diferenciação ao preencher o quadro.
Nesse dia do workshop, sugeri as pessoas que pensassem no preenchimento do quadro usando essas associações, e foi muito bom o resultado, pois facilitou a aplicação da dinâmica.
Encorajada pela Mayra, resolvi compartilhar via esse post como eu faço.

E aí? Como vocês rodam essa dinâmica?

5 dicas essenciais para quem quer investir em um aplicativo

Normalmente, o investimento necessário para desenvolver um aplicativo é alto. Portanto, essa é uma decisão que precisa ser muito bem pensada e analisada antes de ser feita. Pensando nisso, e para te ajudar a entender um pouco mais essa área, aqui estão 5 dicas  que você precisa saber antes de investir em um aplicativo.

1 – Comece pelo Design: Defina com detalhes todas as regras do seu negócio

Toda empresa necessita de regras de negócio bem definidas para sobreviver e conseguir realizar um trabalho eficiente, certo? Quando se trata de um aplicativo não é diferente. Um app é também uma nova empresa, um novo sistema. Para ele funcionar perfeitamente precisa que todas as restrições/premissas necessárias para fazer o produto oferecido acontecer estejam bem estabelecidas.

Está pensando em investir em um aplicativo? Conheça agora 5 dicas que você deve saber antes de investir em um aplicativo.

Saber exatamente como seu aplicativo deverá funcionar te ajudará a definir quais serão as funcionalidades necessárias do seu software e como será o fluxo. Isso bem detalhado irá prevenir que funções imprevistas surjam durante o desenvolvimento do seu projeto. E também te auxilia a obter um orçamento mais preciso do seu projeto, com uma margem de erro bem menor.

Assim como ter as regras de negócio do seu projeto bem definidas no começo é essencial para desenvolver um software com mais eficiência, o mesmo se aplica para o desenho das telas. Colocar as suas ideia no papel, ou no invision, ajudará tanto você quanto a sua equipe de desenvolvimento a entender com mais precisão todos os detalhes e funcionalidades do aplicativo.

E com o protótipo do seu aplicativo em mãos, você pode também validar a sua ideia e o fluxo com os seus usuários. E assim, verificar se a jornada que o seu cliente fará dentro do app está fazendo sentido para ele. Isso te ajuda a saber com mais precisão se o seu produto está fazendo sentido e será usado pelo seu consumidor. E se não, ainda existe a possibilidade de mudar antes de partir para o investimento maior: o desenvolvimento do código!

Está pensando em investir em um aplicativo? Conheça agora 5 dicas que você deve saber antes de investir em um aplicativo.

2 – Segmente o seu mercado: Defina uma persona para o seu público-alvo

Chegar no mercado achando que o seu produto irá solucionar o problema de todas as pessoas e será usado por todos é um erro que muitos cometem. Antes de iniciar qualquer negócio, você primeiro precisa entender quem é seu público-alvo e qual é a dor que eles têm. Fazendo assim com que o serviço que você está oferecendo se adapte às necessidades e realidade do seu mercado foco.

Afinal, sair dando tiros no escuro na direção de diversos públicos diferentes e esperar acertar o correto é uma chance em um milhão. Não tem como agradar a todos!

Por isso, é importante você focar em um segmento do mercado primeiro e validar a sua ideia, para depois expandir. Então, defina muito bem quem é a sua persona e qual é a jornada do seu usuário. Entenda a realidade do seu público-alvo e foque na melhor solução que você pode apresentar para o problema dele.

3 – Crie o Produto Mínimo Viável (MVP): Faça o lançamento por etapas.

Desenvolvimento de aplicativo custa tempo e dinheiro, duas das coisas mais importantes na vida de um empresário. Você pode estar pensando “Ah, mas o mercado de trabalho é bem competitivo e às vezes para concorrer com serviços que já estão há anos funcionando é necessário chegar com tudo”. Mas deixa eu te dizer uma coisa, nem sempre é assim!

Está pensando em investir em um aplicativo? Conheça agora 5 dicas que você deve saber antes de investir em um aplicativo.

Muitas vezes vale mais a pena lançar o seu produto em etapas e ir validando aos poucos com o seu público-alvo. Vamos lá, pense comigo: Você investe 200 mil reais em um aplicativo para lançá-lo o mais completo possível no mercado, sem saber como o seu público irá reagir a ele. E então, após o lançamento, você percebeu que metade das funcionalidades que você desenvolveu não é o que o seu cliente precisa ou usa. Mas que na verdade você estava na linha de pensamento errada o tempo todo. Bem lá se foram 100 mil reais!

Lançar em etapas evita que isso aconteça, pois você irá conseguir ir validando o seu produto, recebendo feedbacks e adaptando-o de acordo com a realidade do mercado. Investindo assim nas atualizações do seu app com maior possibilidade de sucesso.

4 – Invista primeiro em apenas uma plataforma. VALIDE SUA IDEIA!

Eu sei que lançar um aplicativo apenas em Android ou iOS ou Web parece uma perda muito grande de mercado. Mas não vamos encarar isso assim! 

Quando se trata de desenvolvimento de aplicativos, muitas coisas são imprevisíveis. Mesmo com todo o detalhamento e entendimento feitos na etapa de prototipagem e design do seu aplicativo não conseguem evitar que alguns erros ou imprevistos aconteçam na fase de desenvolvimento.

Está pensando em investir em um aplicativo? Conheça agora 5 dicas que você deve saber antes de investir em um aplicativo.

Investindo em apenas uma plataforma primeiro, você além de poupar dinheiro, também consegue evitar que os mesmos erros também se repitam em todas as outras. Afinal, as linguagens das plataformas de desenvolvimento são diferentes umas das outras. iOS, Android e Web serão três aplicativos desenvolvidos em três “códigos” completamente distintos.

Então, se você fizer em uma plataforma primeiro e algum erro acontecer no projeto, você e a sua equipe já terão experiência o suficiente para evitar que esse mesmo erro aconteça na próxima que você for desenvolver. Evitando assim errar três vezes e gastar três vezes mais para corrigir o erro. E também, lançar o aplicativo em uma plataforma primeiro te ajudará a validar a sua ideia e a lançar as próximas do seu app atualizadas de acordo com o feedback do seu público-alvo.

5 – Não use todo o seu investimento de uma vez apenas com o aplicativo

O ideal é que o preço do seu aplicativo não ultrapasse 30% (no máximo 50%) do total que você tem para investir. Mas por quê? Bem, o desenvolvimento do seu produto não será o único valor que você terá que pagar na hora de lançar um novo negócio. Tem também investimentos em marketing, custos jurídicos (Termos e Políticas de Privacidade), contas nas lojas (Google Play e App Store), hospedagem, provavelmente funcionários para o suporte do seu aplicativo e outros valores que podem surgir.

Está pensando em investir em um aplicativo? Conheça agora 5 dicas que você deve saber antes de investir em um aplicativo.

Então é sempre bom deixar bem detalhado quanto você irá gastar com cada serviço nas etapas de lançamento de um novo negócio. Lembre-se: O código não é a única parte importante quando se trata de lançar um novo negócio!

Bem, essas são algumas dicas, que parecem meio óbvias, mas grande parte das pessoas acaba não seguindo. Agora você já sabe, então mãos a massa e vamos lançar esse aplicativo no mercado.

Tem alguma dica que você acha que faltou? Ficou alguma dúvida? Comente ai e vamos bater um papo!

Texto por Larissa Ferreira
Imagem Vinicius Rocha

Quer financiar um aplicativo? Conheça o cartão BNDES e consiga seu crédito

Quer abrir um novo negócio e desenvolver um aplicativo, mas ainda não possui o investimento necessário para começar? Temos uma solução incrível para você!

O Banco Nacional do Desenvolvimento (BNDES) inaugurou uma forma de crédito para ajudar Micro, Pequenas e Médias empresas (MPMEs) a financiarem serviços de desenvolvimento de software sob encomenda. A novidade foi anunciada no dia 26 de Março, em São Paulo, e também pode ser usado para investir na criação de websites corporativos e lojas virtuais.

Com o cartão já era possível comprar softwares prontos e desenvolvidos no Brasil por profissionais que residem no país. Agora com a possibilidade de financiar serviços de desenvolvimento, o cartão reforça o apoio aos investimentos das MPMEs em tecnologias da informação e comunicação (TICs). Possibilitando assim uma maneira de que essas empresas consigam reduzir seus custos e aumentem seus ganhos em eficiência operacional e competitividade.

As Micro, Pequenas e Médias empresas poderão ser portadoras do cartão para adquirir itens necessários às suas atividades. Elas também poderão se credenciar como fornecedoras para oferecer a seus clientes o Cartão BNDES como forma de pagamento pelos serviços prestados.

Tem interesse? Para solicitar o cartão, basta acessar o site do BNDES (www.cartaobndes.gov.br) e fazer o seu cadastro.

Como usar o cartão?

As empresas poderão encomendar diversos sistemas e aplicativos com o cartão do BNDES. Isso inclui: aplicações industriais, internet das coisas (IoT), machine-to-machine (M2M) e soluções similares, softwares para plataformas móveis, entre outras coisas. O pagamento pode ser parcelado em até 48 meses com uma taxa de juros atrativa. 

Testes de software: como testar seu software corretamente

Existem diversos tipos de testes de software e eles são dividido em três principais categorias: Unitários, de integração e ponta a ponta.

Os testes, muitas vezes esquecidos ou até desprezados, fazem parte do desenvolvimento de todo software que se preze. Se uma falha acontecer na mão de um usuário, você não terá chance para se explicar. E assim, o negócio de alguém pode estar em risco por uma simples bobagem feita no código. Então, a melhor forma de garantir a qualidade do aplicativo que você está fazendo é testando ele.

Mas, afinal, de quem é a responsabilidade de testar a aplicação? É do desenvolvedor? Do analista de teste / tester (responsável por encontrar erros, falhas, bugs e outros tipos de problemas que não foram detectados durante o desenvolvimento de um software)? Do gerente de projeto / PO (profissional responsável por priorizar as atividades que maximizam o valor do produto e garantir o retorno do investimento)? A resposta é: todos. Sim, todos devem testar a aplicação, desde o início do desenvolvimento.

Para evitarmos futuras dores de cabeça e correções relâmpago, a equipe de desenvolvimento de software faz (ou pelo menos, deveria) testes em todas as aplicações produzidas. Testes de software são divididos primariamente em três categorias: unitários, de integração e ponta a ponta.

  • Testes unitários são feitos em partes isoladas do código, para cada componente. É como se testássemos cada “peça” de um aparelho antes de colocá-las. Vamos pensar que estamos montando um carro. Para garantir a segurança e evitar erros antes de unir todas as peças, é preciso testar cada uma delas separadamente. Por exemplo, para ter certeza que o veículo está funcionando normalmente antes de ir para o mercado, você tem que testar separadamente o freio, o volante, o câmbio, etc.
  • Testes de integração são testes unitários feitos em mais de uma parte do código. Eles juntam múltiplos componentes (normalmente 2) e verificam a comunicação e integração entre os mesmos. Este é o teste que garante que a ligação entre as peças está funcionando. Pense no caso do carro novamente: quando você utiliza o volante para dirigir-lo, a roda tem que responder ao pedido e mover o automóvel.
  • Testes de ponta a ponta são testes que validam todo tipo de comportamento possível dentro da aplicação, ou seja, simulam a atividade do usuário final. Se usarmos o exemplo do carro, esse tipo de teste seria dirigir o veículo após tudo estar finalizado, como se fosse o usuário normal. Garantindo assim que todas as peças do produto final e as comunicações entre elas estão funcionando corretamente.

Apenas os testes de ponta a ponta bastam?

Ora, mas se testes de ponta a ponta simulam um usuário real, então, em teoria, é a melhor escolha:

  1. O desenvolvedor fica feliz, afinal a responsabilidade de testar não é dele
  2. O analista de teste fica feliz, pois consegue testar simulando um usuário real, então seus testes de software são mais valiosos
  3. O gerente do projeto / PO fica feliz, pois isso vai garantir que o usuário final terá uma experiência melhor

MAS, infelizmente, não é bem assim que funciona. Se dependermos apenas de testes de ponta a ponta, o procedimento ficaria algo mais ou menos assim:

  1. O desenvolvedor faz uma feature/versão e passa para o tester do seu projeto
  2. Se o tester encontrar algum bug, ele cria um relatório do erro, e o desenvolvedor é notificado
  3. O desenvolvedor verifica o erro, checa o código, e corrige o bug
  4. Após toda a validação, uma versão de produção é lançada e enviada ao cliente

O que foi vantajoso nesse processo?

  • Erros que afetariam diretamente o usuário final foram detectados e corrigidos.

O que houve de errado nesse processo?

  • Os desenvolvedores tiveram que esperar o relatório de bugs para poder resolvê-los;
  • Bugs pequenos podem estar escondidos atrás de bugs maiores;
  • Encontrar a causa dos bugs pode levar um bom tempo.

Obtenha um procedimento mais efetivo

A melhor forma de conseguir sucesso durante o processo é utilizando testes unitários:

Testes unitários são testes de software feitos em partes isoladas do código, verificando métodos e funcionalidades específicas de um componente. Por estarem isolados, é muito mais fácil encontrar e corrigir erros. São testes rápidos e confiáveis.

O grande problema dos testes de software de ponta a ponta é a espera – você não sabe do erro até que ele ocorra na mão de um possível usuário, ou seja, quando já é tarde demais. Testes unitários conseguem ser precisos, ou seja, você sabe o que deu errado com mais precisão, sem esperar chegar ao usuário.

Apesar de todas essas vantagens, há uma coisa que o teste unitário não faz: simular um usuário real.

Evite possíveis bugs

A melhor maneira de nos prevenirmos contra bugs no desenvolvimento é utilizar cada teste corretamente e também usar o nosso tempo durante este processo de forma mais eficiente.

Por isso, utilizamos a pirâmide de testes de software proposta pela Google:

img_blog

 

A sugestão é que se faça uma divisão de 70/20/10, ou seja:

  • 70% de testes unitários;
  • 20% de testes de integração;
  • 10% de testes de ponta a ponta.

Isso serve para tentar sempre evitar uma pirâmide invertida (focada em testes de ponta a ponta), ou em formato de ampulheta (foco em testes unitários e ponta a ponta, mas nenhum em integração).

Texto: Leonardo Miyagi
Imagem: Rafaela Brum

*Este texto foi baseado em um artigo publicado pela própria Google, falando sobre testes de ponta a ponta (End-to-End Tests): https://testing.googleblog.com/2015/04/just-say-no-to-more-end-to-end-tests.html