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

 

 

Meus primeiros meses trabalhando como desenvolvedora na Jera

Texto por Larissa Marães

Quando iniciei a minha graduação em Engenharia de Computação, eu não tinha muitas expectativas profissionais e muito menos conhecia as empresas de tecnologia da capital. Até que me ingressei em um curso técnico que me trouxe uma visão do mercado de TI. Neste curso, tive a oportunidade de visitar algumas empresas, e uma delas foi a Jera. Foi amor à primeira vista. Desde então, a Jera se tornou uma das empresas em que sempre sonhei em trabalhar.

Te quiero! <3

E então, em um momento perfeito da minha vida pessoal e acadêmica, encontro uma divulgação de vaga de estágio em desenvolvimento na Jera, na qual logo me inscrevi. Foram 4 etapas de processo seletivo, onde em cada uma eu me identificava cada vez mais com a empresa. Em uma das etapas, me enviaram um link onde continha o Culture Code da Jera e nele são apresentados os valores da empresa. Amor ao trabalho, foco no cliente, diálogo aberto, melhoria contínua e valorizar realizações… Ler essas palavras bonitas me pareceu encantador, mas no fundo, eu não tinha idéia de como isso funcionava.

Eu não sei o que é, mas eu tô dentro!

No dia 16 de junho de 2018, iniciou-se a minha jornada na taberna. E com a mentalidade de qualquer noob, eu achava que seria moleza desenvolver software (Sabe de nada, inocente!). Logo no primeiro dia apareceram os desafios. No meio de toda apresentação aos processos da empresa, foi necessário estudar bastante e tomar muitos cafezinhos para entender a fundo como o processo de desenvolvimento de software funciona lá dentro.

Diante dos times de desenvolvimento Web, Android e iOS, eu tinha quase certeza que iria atuar em desenvolvimento Web, pois já tive experiências nessa área, além do curso técnico que fiz. Mas para a minha surpresa, fui alocada no time Android!! O sentimento de desespero tomou conta ao perceber que estava fora da minha zona de conforto. E por conta disso, me empenhei o máximo e estudei sem parar para conseguir realizar minhas entregas. E quando eu achava que já tinha aprendido o suficiente, novos desafios surgiram e eu voltava a me empenhar e estudar. Em poucas semanas aprendi coisas que eu demoraria anos para aprender na faculdade. Em tão pouco tempo me senti estimulada a entender mais essa nova área e me tornar uma desenvolvedora tão boa quantos os desenvolvedores de lá. É melhoria contínua o nome disso, né?

Como me sinto estudando e percebendo que estou melhor do que ontem.

Mas nada como o primeiro app… Primeiro projeto dentro da Jera. Ainda estava aprendendo e me adaptando à todos os processos. “Não tenham medo de errar”, eles disseram. E foi o que eu fiz. Errei MUITO! Como era nova na equipe, pensei que seria tratada como uma mera novata. E por conta disso, eu tinha vergonha (até mesmo medo) de expressar as minhas dificuldades e pedir ajuda. Com isso, aprendi da forma mais dura a importância do diálogo aberto, pois sem ele tive uma semana difícil e falhei na entrega de algumas tarefas, além de prejudicar a minha equipe. Depois disso, passei a explorar mais o diálogo aberto no meu dia-a-dia, buscando entender e expressar ideias. E com isso, criar debates construtivos para solucionar problemas.

Euzinha falhando com a equipe 🙁

Diferente de qualquer trabalho de faculdade, eu não estava fazendo aquilo por uma nota ou aprovação em uma disciplina. Afinal, o que eu estava desenvolvendo fazia parte de algo maior, um produto que tinha investimento de uma pessoa que acreditava na sua ideia. Demorou um tempo para eu perceber isso. E quando percebi, comecei a desenvolver aquilo como se fosse meu produto também. E o resultado disso é incrível! Pois você se sente engajado com o projeto e o time, realiza entregas de qualidade, e melhor ainda, a satisfação do cliente. #FocoNoCliente

Meu app, my precious!!

Na Jera trabalhamos duro, mas quando comemoramos, é pra valer também! Além das reuniões diárias com o time, temos toda sexta uma retrospectiva (chamada carinhosamente de retrô) onde nos reunimos para discutir os pontos a serem melhorados e as coisas boas que aconteceram na semana. Aah… Como eu amo as retrôs! É o momento que temos para juntos fazermos barulho e comemorarmos as pequenas conquistas da semana. E então eu entendi como é bom valorizar realizações. não apenas as suas, mas as dos outros colegas de trabalho também.

E as retrôs são tipo isso…

E diante de todos os valores citados, o amor ao trabalho é o meu favorito. Pois quando eu acho que finalmente entendo o que é amar o trabalho, cada dia que passa eu me surpreendo e amo cada dia mais o que faço. E não só isso, é amar o que faz e amar fazer. E na Jera, com esse ambiente de trabalho maravilhoso, fica cada dia maior o amor que sinto pelo desenvolvimento de software e por essa empresa linda que mal conheço e já considero pakas! <3

 

 

Aumente as chances de sucesso do seu negócio com o método de MVP Sprint

Muitos de nós já tivemos ideias fantásticas e que iriam revolucionar o mundo. Quando temos estas ideias, ficamos muito empolgados. Imaginamos as pessoas utilizando e queremos botar em prática o quanto antes.

Porém, quando sentamos na nossa cadeira para pensar em como iremos começar, milhões de perguntas surgem. Ficamos inseguros, a apreensão bate e nos questionamos: será que minha ideia vai dar certo?

Ou pior, alguns até conseguem tirar do papel e depois de gastar muito tempo e dinheiro, veem seu projeto não dar certo e se frustram com o esforço que foi em vão.

Alguns dos nossos clientes tiveram estes problemas e não era legal vê-los nesta situação. Como solução, começamos a utilizar a metodologia Direto ao Ponto de Paulo Caroli, que ajudou-nos a estruturar melhor os projetos deles, o que trouxe produtos mais enxutos e que entregam mais valor. Depois de perceber o resultado positivo, criamos o processo de MVP Sprint.

Nunca ouviu falar sobre MVP, aconselho ler estes artigos do nosso blog que explicam o que é:

Você conhece o Lean Startup? Veja como essa metodologia pode ajudar sua empresa

Como lançar um aplicativo de sucesso no mercado

O que é a MVP Sprint

O processo de MVP Sprint é um trabalho colaborativo que dura em torno de duas semanas e envolvem as partes interessadas do negócio (clientes) e a nossa equipe.

Durante estes dias, exploramos e entendemos o problema, debatemos o negócio, propomos soluções, definimos a estratégia e o que será feito e, por fim, construímos o MVP (Produto Mínimo Viável) alinhado aos objetivos do negócio propostos.

Quer saber mais sobre a MVP Sprint? Clique na imagem acima e baixe a apresentação que fizemos na Feira do Empreendedor MS, que detalha todas as etapas realizadas durante o processo.

Dividimos o processo em duas fases: descoberta e wireframe.

Descoberta

Nesta fase reunimos todos os envolvidos com o projeto em uma sala fechada. É interessante que tenha pessoas de áreas diferentes. Isso porque o debate torna-se mais amplo e a gama de conhecimento maior.

Em cinco dias realizamos várias dinâmicas para esmiuçar tudo sobre a ideia. Ao final da sprint de descoberta, definimos a visão do produto, o perfil dos usuários do negócio e as funcionalidades que entrarão no MVP e também alinhamos a estratégia de lançamento do produto, na qual, estipulamos os resultados esperados e as métricas de sucesso.

Wireframe

Nesta fase construímos o protótipo do produto conforme o MVP  já definido na descoberta. Os objetivos desta etapa são: materializar o que estava na mente de todos e ter algo palpável para validar a ideia.

Chamamos esta fase de wireframe, porque é um modelo de protótipo utilizado em design de interface que busca estruturar a navegação e a disposição do conteúdo, esquivando-se de qualquer apego visual.

Exemplo de wireframe

Para fazer o wireframe do protótipo, utilizamos o Sketch App para desenhar as telas e o Invision para fazer a navegação do sistema.

Validação

É fundamental realizar a validação do protótipo construído na MVP Sprint. Com isso você terá respostas que irão ajudar na evolução do negócio, mudar de direção ou abandonar a ideia.

Descobrir que sua ideia fracassou é triste, mas não é ruim. Pense que será gasto menos tempo e dinheiro do que se fosse feito um projeto gigantesco e sem uma estratégia traçada.

Conclusão

A MVP Sprint auxilia na organização das ideias. Também ajuda a estimar com mais precisão os custos e o cronograma do projeto.

Outro ponto positivo é a idealização de produtos mais enxutos. E que também entreguem valor e direcionem para onde se quer chegar.

Além do viés estratégico, os envolvidos com a ideia compreendem melhor os objetivos do negócio. E acabam se engajando ainda mais para fazer acontecer o projeto.

Texto e Imagem: Vinicius Rocha

Afinal, O que é Hackathon? Veja agora cinco motivos para participar de um

O termo hackathon anda ganhando muita popularidade ultimamente, principalmente na área de tecnologia. Você provavelmente já deve ter ouvido ele pelo menos uma vez, certo?

Mas afinal, o que é esse tal Hackathon? É um ritmo baiano? É uma nova linguagem de programação?

Nem um, nem outro. O Hackathon, na verdade, é um evento que objetiva colocar em produção uma ideia/negócio/produto que solucione um problema social. Durante o Hackathon, profissionais de diferentes áreas (negócios, tecnologia, comunicação, etc) se reúnem e trabalham juntos para criar uma solução para o problema apresentado. Legal né?

Os participantes do Hackathon são divididos em times, escolhidos aleatoriamente. E os grupos devem colocar em produção uma ideia inovadora em 48h. No final do evento, uma equipe de avaliadores técnicos irão julgar os projetos. O time que colocou a melhor ideia em produção ganha o prêmio.

Agora já sabendo disso, vamos falar um poucos sobre quais são os motivos para você participar de um Hackathon:

Ajudar a resolver um problema social

Todos nós, uma vez ou outra, reclamamos dos problemas que nos cercam, mas que infelizmente pouco podemos fazer para mudá-los. Seja um problema ambiental, social ou econômico. No evento, você poderá fazer a sua contribuição para a nossa sociedade e criar uma forma de melhorar a vida das pessoas. E depois, se você quiser, pode até dar continuidade com a ideia.

Network

Diversas pessoas, de diferentes cidades e áreas, estarão participando do evento junto com você e farão parte do seu time. Então, é uma ótima oportunidade para ampliar a sua rede de contatos ao redor do Brasil e divulgar o seu trabalho.

Aprimorar soft skills

Não é só de hard skills que se vive um profissional, né?! No Hackathon você será levado ao seu máximo durante horas de trabalho, então você com certeza desenvolverá habilidades novas ou irá aprimorar as que você já tem. Por exemplo, você irá precisar ser resiliente, trabalhar em equipe, ser orientado para solução, analítico, comunicador, inovador, entre outras coisas.

Imersão

Você ficará um final de semana inteiro estruturando e desenvolvendo o seu produto. Então serão horas de trabalho focado e imerso no mundo da tecnologia, empreendedorismo e inovação.

Ambiente desafiador

Participar de um Hackathon é uma experiência que irá te tirar completamente da sua zona de conforto. Afinal, você precisará criar e desenvolver a melhor solução para o problema apresentado em apenas 48h e com pessoas que você nunca trabalhou antes. Então, se você gosta de desafios e aprendizado rápido, o evento foi feito para você.

Ficou interessado? Então faça a sua inscrição em um agora mesmo! O Google Developers Group de Campo Grande – MS (GDG CG), com o apoio da Jera, está organizando o seu primeiro Hackathon. Para fazer a sua inscrição é só acessar o link: https://bit.ly/2LtwXFT

Corre lá porque o evento já irá acontecer semana que vem!

Se você for meu cliente, espero que falhe logo

Texto por Ney Ricardo

É isso mesmo! Espero que você falhe o mais rápido possível, mas não é nada pessoal. Empreender é como um investimento de alto risco: grandes chances de fracasso.

Ao longo desses quase 2 anos trabalhando como Product Owner na Jera, vi vários produtos revolucionários e com grande potencial de ganho morrerem no momento em que foram parar no mercado.

É duro admitir, mas eu contribuí diretamente para alguns desses fracassos, já que atuo aconselhando o clientae. Apesar de toda minha experiência com startups, não é possível oferecer garantias de que lá no final o produto vai dar certo.

Entretanto, existem algumas sacadas que podem ajudar a economizar o seu tempo e dinheiro.

Gimli filho de Glóin, filósofo anão
Gimli filho de Glóin, filósofo anão

Descoberta

Por incrível que pareça, muita gente ainda nos procura sem conhecer muito bem o próprio produto. E não falo sobre saber como você quer que funcione.

Empreendimento é que nem filho: tão bonito e perfeito… não admito que digam o contrário.

Entenda que você está criando algo novo para o seu cliente, e não para si mesmo. Logo, se o seu cliente não enxerga valor na solução, não comprará a ideia.

A coisa mais importante no início de uma nova empreitada é identificar o problema que você está resolvendo. Depois identificar quem são os clientes ideais. O que eles fazem, onde vivem… Clichê, mas é real.

E em seguida vem a mágica: entrevistar a pessoa de quem você quer tirar dinheiro com seu produto, pra ter certeza de que ela também tem o mesmo problema e pagaria pra tê-lo resolvido. Aproveite e tente vender, mesmo sem ter o produto ainda. Intenção de compra é uma coisa, venda é outra.

Definir ou refinar

Deu certo? Viu que tem mais gente com a mesma dor interessada em ter o problema sanado? Hora de criar hipóteses.

Tudo nesta fase é parcialmente conhecido, por isso trabalhamos com a crença de que a solução imaginada vai mesmo ajudar as pessoas.

Mapear cada passo da jornada da pessoa que vamos atender e imaginar como poderíamos ajudá-la da melhor maneira possível. É aqui que começam a nascer as possíveis soluções. Mas, veja, tudo se baseia em hipóteses, não é a solução final, nunca será o final.

Desenvolver

Hora de criar um protótipo que seja testável pelas mesmas pessoas que entrevistamos na fase anterior, com base no que aprendemos até agora.

Nesse ponto o design ajuda demais, já que toma menos tempo e gasta menos recursos do que partir direto para a implementação de uma solução.

Ainda estamos trabalhando com hipóteses, lembra? Então o ideal é pegar esses protótipos com todas as soluções que imaginamos para o problema e colocar nas mãos das pessoas que conversamos lá no começo.

Entregar

Aqui são feitos os testes e a validação do protótipo. Com um profissional bem treinado para observar a utilização do protótipo, será possível identificar os pontos de confusão e estresse ao longo das interações.

Anotados todos os pontos de melhoria, hora de documentar o aprendizado, analisá-lo, refinar o nosso protótipo e, dependendo do que for descoberto, podemos voltar à fase de descoberta ou, se tudo der certo, iniciar o desenvolvimento de fato.

Conclusão

Processo do Diamante Duplo
Processo do Diamante Duplo

Se você não concluiu que o projeto é um fracasso em nenhuma dessas fases, isso é um sinal de que o seu investimento terá muitas chances de realmente dar certo quando for para o mercado.

E se fracassou no meio dessa jornada, qual é o problema? Pense na economia de tempo e dinheiro. Pense também no aprendizado adquirido.

O segredo do sucesso é falhar logo. Depois pegar o que aprendeu e agir em cima disso.

Fail fast and cheap. Fail often. Fail in a way that doesn't kill you. — Seth Godin
Fail fast and cheap. Fail often. Fail in a way that doesn’t kill you. — Seth Godin

E depois, quando as pessoas já estiverem pagando pela sua solução? Isso já é assunto pra outra conversa: fazer o negócio crescer.