Como criar um aplicativo Android com câmera (Android 6+)

google-camera-interface-nexus-6p-android-n-840x473

Atualizado em 19/07/17 com suporte a Android 6+

No post de hoje vou ensinar como criar um app Android onde você pode “invocar” o recurso de câmera do smartphone e depois ter acesso à foto retirada para fazer o que quiser com ela. Tenho certeza que lhe pode ser útil para algum projeto que esteja fazendo ou que vá fazer um dia.

Se você nunca fez um app antes, sugiro dar uma olhada primeiro neste tutorial que cobre todo o básico!

Há alguns anos atrás eu desenvolvi um app para uma campanha publicitária da LG, para o lançamento de um novo modelo de smartphone, acho que era o L2 ou algo assim. Esse app se chamava “Bem na Foto” e foi solicitado pela LG para ser usado nos pontos de venda visando mostrar como a câmera desse aparelho novo era boa. Ele era bem simples: o usuário abria o app, tirava uma foto, escolhia uma moldura para colocar a foto dentro e publicava nas redes sociais. Mesmo simples, me rendeu bastante dinheiro para um projeto que levei poucos dias para deixar 100%.

Vamos ver nesse post:

A tela inicial

Na tela inicial não teremos nada de especial, exceto um botão para tirar uma nova foto, sendo assim, quando você for criar seu projeto, escolha o template Basic Activity (o mesmo que usamos neste tutorial de CRUD) que já vem com um FloatingActionButton e apenas adicione uma ImageView que exibirá a foto tirada, dentro do content_main.xml:

Note que eu não escrevi todos esses código aí em cima, apenas arrastei o ImageView pro layout e usei o recurso Infer Constraints do ContraintLayout. Já no activity_main.xml, apenas mude o ícone do FloatingActionButton para ser uma câmera ao invés do envelope tradicional, como fiz no código abaixo:

O seu layout deve se parecer com esse (a ImageView está transparente pois não tiramos foto ainda):

Layout do app
Layout do app

Na classe Java que vai responder por esta tela, chamada de MainActivity, existe um código pronto para o clique do FloatingActionButton, que por padrão apenas exibe uma SnackBar, mude-o para que chame o método correto, conforme abaixo:

Note que neste código chamamos um método getPermissions(); que ainda não existe e que teremos de criar no próximo passo.

Configurando permissões

Neste tutorial usaremos os recursos de câmera e de armazenamento do smartphone, logo, precisamos que o Android nos forneça tais permissões. Além disso, precisamos exigir que este app somente possa ser instalado em dispositivos com câmera. O trecho de código abaixo deve ser colocado no arquivo AndroidManifest.xml, logo acima da tag application:

Até a versão 5 do Android isso é o suficiente para garantir que teremos as permissões necessárias. No entanto, a partir da versão 6 o controle de permissões mudou e agora devemos também solicitar via código, no momento em que vamos usar o recurso em questão.

Para tanto, vamos criar o método getPermissions() como abaixo (bem parecido com o que usamos no tutorial de app com GPS) e o método onRequestPermissionsResult() que será disparado automaticamente quando o usuário tiver interagido com o dialog de sistema que pedirá a permissão para ele:

Após o usuário fornecer ou não permissão ao aplicativo, ele irá disparar o evento onRequestPermissionsResult, também exibido no código anterior, que dispara o método dispatchTakePictureIntent() se tiver as permissões de uso da câmera e do SD ou um alerta, caso contrário. Da mesma forma, em usos futuros do app, já com a permissão concedida, esse passo não acontece mais, como mostrado no else do método getPermissions().

Note que este método dispatchTakePictureIntent() não existe ainda, criaremos no próximo passo.

Chamando a câmera

Para invocar a câmera do dispositivo nós temos que criar um método com a intenção de usar a câmera que, quando a foto for tirada, irá retornar à activity de origem, salvar a foto e exibir a mesma.

Ufa, é um trabalho e tanto!

Temos dois métodos no exemplo de código acima, o dispatchTakePictureIntent que inicializa a câmera, e salva a foto tirada no cartão SD e o evento onActivityResult que é disparado automaticamente quando a foto termina de ser tirada para exibi-la no ImageView.

Quando for mandar rodar no simulador, lembre-se de se certificar se ele possui hardware de câmera na tela de configurações dele (caso não possua, edite-o). Na imagem abaixo você confere a foto tirada, usando o modo “emulated” de câmera no simulador do Android.

Foto tirada
Foto tirada

Na sequência você pode colocar botões nessa tela para editar a imagem, por exemplo, ou para exclui-la. Com alguns códigos Java você pode publicá-la em redes sociais ou mesmo envia-la por email.

Mas isso fica para a sua criatividade ou para posts futuros, não é mesmo?! 😉

* OBS: curtiu o post? Então dá uma olhada no meu livro de Android clicando no banner abaixo pra aprender a criar outros tantos apps incríveis!

Criando apps para empresas com Android

Tutorial: CRUD em Android com SQLite e RecyclerView (Parte 2)

Seguimos agora com a tão aguardada segunda parte do Tutorial: CRUD em Android com SQLite e RecyclerView. Se chegou agora e ainda não fez a primeira parte do tutorial, faça, pois é bem difícil de conseguir acompanhar sem ter concluído todos os preparativos iniciais.

O que é uma RecyclerView? A RecyclerView é a substituta mais moderna ao ListView, que até então era o componente recomendado para criar listagens. No entanto, o ListView está atrelado à versão do SDK que você está rodando, é pesado e tem pouca flexibilidade. A RecyclerView é um pouco mais complicada de lidar mas vale a pena considerando os benefícios que se tem com ela, como veremos nesta segunda parte do tutorial.

Veremos neste tutorial:

  1. Criando e explorando o projeto Basic (parte 1)
  2. Criando a tela de cadastro/edição (parte 1)
  3. Preparando a persistência de dados (parte 1)
  4. Cadastrando Clientes (parte 1)
  5. Listando Clientes
  6. Atualizando Clientes
  7. Removendo Clientes

Mãos à obra!

Parte 5: Listando clientes

Primeiro, vamos criar na nossa classe ClienteDAO o método que vai retornar todos os clientes do banco de dados, como segue:

Aqui usamos o método rawQuery do objeto SQLiteDatabase para executar uma consulta SELECT em cima de todos clientes da base o que nos retorna um cursor. Com um laço em cima do curso conseguimos retornar cada uma das colunas em cada uma das linhas da tabela, populando uma coleção de Clientes com essas informações.

Atenção: para pegar o índice da coluna a partir do seu nome, o mesmo deve ser informado tal qual foi criado no CREATE TABLE original. Caso não queira pegar por nome, você pode pegar por índice, desde que saiba a ordem que as colunas serão retornadas do banco (se especificar as colunas ao invés de usar SELECT *, fica mais fácil).

Agora vamos voltar a nossa atenção ao arquivo de layout content_main.xml, que vamos editar para incluir uma lista de elementos nele, que mais tarde será populada com os clientes do banco de dados. Já que estamos usando de boas práticas em vários cantos, não usaremos aqui ListView, mas sim a versão mais moderna para listagem de elementos que é a RecyclerView, um componente gráfico independente de versão do SDK que é atualizado constantemente, tem muito mais desempenho, mas opções visuais e de animação, etc.

Para poder usar a RecyclerView, primeiro você deve adicionar algumas dependências no seu arquivo build.gradle dentro da pasta app, dentro da seção dependencies do mesmo:

Atenção: Certifique-se de que a versão das bibliotecas ‘-v7’ seja a mesma entre todos eles, no meu caso, 25.3.1, a mais recente na data que escrevo este post. É possível também que a dependência da biblioteca support:design já esteja adicionada nesse arquivo, nesse caso não precisa adicionar de novo.

Para podermos criar belas listas usando RecyclerView, devemos adotar uma técnica semelhante ao que fizemos no post sobre ListViews personalizadas: temos de ter um layout XML que represente um único item da lista, para o mesmo ser replicado.

Sendo assim, adicione um novo layout XML na pasta de layouts chamado item_lista.xml com o layout ConstraintLayout na raiz e crie uma interface semelhante à esta:

Item da Lista
Item da Lista

O código XML para fazer esta interface está abaixo. Você não precisa fazer igual, mas atente aos ids dos componentes que é o mais importante no momento:

Agora sim, vamos para a content_main.xml, apagamos aquele Hello World que estava lá e vamos adicionar uma RecyclerView, que fica na categoria AppCompat da Palette do Layout Editor do Android Studio.

A RecyclerView possui uma propriedade listitem, onde devemos informar o layout XML que usaremos para os itens da mesma, no nosso caso, o item_lista.xml:

O preview da sua tela principal deve mudar também, logo após você adicionar a informação do layout da lista.

Para que os campos do item_lista.xml sejam mapeados corretamente quando carregarmos os elementos na lista, devemos criar uma classe Java extendendo ViewHolder, como a ClienteHolder.java abaixo:

Na sequência, vamos criar o ClienteAdapter.java que vai fazer a ligação entre os dados dos clientes e os campos do layout item_lista. Para a classe ser uma Adapter é necessário herdar RecyclerView.Adapter<ViewHolder> e implementar os métodos obrigatórios.

  • onCreateViewHolder(ViewGroup parent, int viewType): Método que deverá retornar layout criado pelo ViewHolder já inflado em uma view.
  • onBindViewHolder(ViewHolder holder, int position): Método que recebe o ViewHolder e a posição da lista. Aqui é recuperado o objeto da lista de Objetos pela posição e associado à ViewHolder. É onde a mágica acontece!
  • getItemCount(): Método que deverá retornar quantos itens há na lista. Aconselha-se verificar se a lista não está nula como no exemplo, pois ao tentar recuperar a quantidade da lista nula pode gerar um erro em tempo de execução (NullPointerException).

Vale ressaltar que os métodos onCreateViewHolder e onBindViewHolder não são chamados para todos os itens inicialmente, eles são chamados apenas para os itens visíveis para o usuário. Quando o usuário sobe e desce a lista, estes dois métodos são chamados novamente associando a view reciclada ao conteúdo daquela posição que agora será visível.

Agora é a hora de voltarmos ao nosso MainActivity.java e programar a integração da RecyclerView com os dados da ClienteDAO. Primeiro, crie um método configurarRecycler, como abaixo:

E depois, chame esse configurarRecycler() no final do onCreate da MainActivity.java, para que ele seja disparado e popule inicialmente a RecyclerView com a lista de clientes do banco.

Isso deve funcionar parcialmente. Quando abrimos o app pela primeira vez ele vai listar corretamente todos os clientes. Mas quando adicionamos um novo cliente, ele não se atualiza.

Até poderíamos resolver isso facilmente mandando chamar novamente o configurarRecycler() a cada nova inserção, mas essa não é a maneira correta de fazer. Ao invés disso, quando um cliente novo for inserido no banco, ele também deve ser inserido na coleção de clientes que o ClienteAdapter referencia, em memória. Para isso, vamos fazer alguns ajustes.

Primeiro, vamos criar um método no ClienteDAO.java para retornar o último Cliente inserido no banco de dados. Isso porque como o ID é automático e autoincremental, precisamos saber o ID que o cliente recebeu para adicionar o objeto completo na nossa lista (usaremos esse ID mais tarde na edição e exclusão). O código é bem parecido com o de retornarTodos, mais simples até, então dispensa explicações:

Agora vamos editar o nosso ClienteAdapter.java para ter um método que adicione novos clientes à lista:

Bem simples, apenas adiciona o cliente na coleção in-memory e notifica a RecyclerView que ela deve se atualizar.

Agora, no nosso click do botão de salvar, após salvar, vamos pegar o último elemento e adicionar ele no adapter usando o método que já está pronto nele, que inclusive atualiza o RecyclerView na sequência. Note que o trecho de código abaixo é o último bloco do onClick do btnSalvar e eu apenas coloquei duas linhas novas no início do if:

Com isso, as duas primeiras letras do CRUD estão prontas: o C de Create e o R de Read.

Lista funcionando
Lista funcionando

Agora é hora de fazer funcionar aqueles dois botões à direita dos nomes!

Parte 6: Atualizando Clientes

Agora vamos programar a atualização de clientes. A ideia é a seguinte: o usuário clica no botão de editar, daí abrimos a mesma tela de cadastro, mas com os dados do cliente que está sendo editado já preenchido. Daí quando o usuário clica em Salvar, ele faz um update no banco ao invés de um insert.

Para fazer isso, primeiro vamos editar o nosso ClienteDAO para incluir uma sobrecarga do método salvar que recebe um id por parâmetro, informando que é uma atualização ao invés de uma inserção. Não apenas isso, mas achei mais interessante jogar fora aquele método salvar antigo e no lugar adicionei as duas versões abaixo (com e sem id):

Muito menor e mais inteligente!

Agora precisamos editar nossa classe ClienteAdapter.java, que é quem possui a lógica dos botões para programar o click do btnEditar. Primeiro, vamos começar adicionando este método que permite obter uma Activity a partir de uma View qualquer, algo útil considerando que o ClienteAdapter não é uma Activity:

Agora, ainda no ClienteAdapter.java, mas dentro do método onBindViewHolder, adicione o seguinte bloco de código no final do método:

Isso vai fazer com que, ao clicar no botão de editar de alguma das linhas da RecyclerView, seja disparado um “refresh” na Activity atual, passando o cliente que deve ser editado feito Extra.

Aproveitando que estamos aqui no ClienteAdapter.java, vamos adicionar um último método pra ele permitir a atualização fácil e rápida de clientes na RecyclerView mais tarde, no final desta etapa:

Apenas adicione o método acima na ClienteAdapter.java, que tem mecânica semelhante com outros método que também adicionamos por lá, e vamos continuar!

Voltando à MainActivity.java, adicione o seguinte bloco de código na classe:

Basicamente aqui temos uma variável que usaremos pra guardar o cliente que será editado e um método utilitário para selecionarmos o item de um Spinner a partir de seu valor, que usaremos mais tarde.

Agora, ainda no MainActivity.java, mas dentro do método onCreate, adicione esta verificação logo após o setContentView:

Isso faz com que, se estiver vindo um Cliente no Intent que disparou esta Activity, vamos abrir o app na tela de edição ao invés de listagem, já carregando os campos com os valores atuais do cliente.

Para finalizar, temos que fazer com que o botão de salvar seja mais inteligente do que atualmente é. Hoje ele sempre manda salvar um novo cliente, mas agora queremos que ele veja se estamos editando um novo cliente (através da variável clienteEditado) ou se estamos salvando um novo cliente. No código abaixo, eu apenas alterei poucas linhas dentro do onClick do btnSalvar, colocando um if onde antes era apenas uma chamada a dao.salvar:

Isso é o suficiente para fazer com que a nossa edição funcione tão bem quanto as demais operações do nosso app de CRUD.

Editando cliente
Editando cliente

E com isso terminamos a letra U do nosso CRUD!

Parte 7: Removendo Clientes

Agora vamos programar a exclusão de clientes. A ideia é a seguinte: o usuário clica no botão de excluir, daí pedimos uma confirmação e, se ele confirmar, mandamos o ClienteDAO excluir o cliente e removemos o objeto do ClienteAdapter, notificando a lista para que seja atualizada.

Para fazer isso, primeiro vamos editar nossa classe ClienteDAO.java para que tenha um método de exclusão de Cliente:

Agora, vamos editar a classe ClienteAdapter.java para ter um método de exclusão lá também:

Aqui pegamos a posição do cliente que queremos excluir, removemos ele da lista e depois notificamos a RecyclerView.

Agora vamos juntar as pontas mexendo no onBindViewHolder do ClienteAdapter.java novamente, adicionando o listener ao click do btnExcluir presente nos itens da lista. Aqui temos de exibir um popup de confirmação para o usuário e, em caso afirmativo, realizar a exclusão de facto chamando os métodos que criamos anteriormente:

E o mais incrível, funciona!

Exclusão funcionando
Exclusão funcionando

E com isso terminamos a última letra do CRUD, a D de Delete!

Espero que tenham gostado deste mega tutorial. Deu uma trabalheira fazer mas tenho certeza de que ficou uma ótima referência pro pessoal que está querendo fazer um CRUD completo com boas práticas e componentes modernos.

Precisando de referências mais completas quanto ao uso do SQLiteDatabase, consulte a documentação oficial.

Tendo qualquer dúvida, chama aí nos comentários!

Gostou do tutorial e quer mais? Dá uma olhada no meu livro clicando no banner abaixo!

Criando apps para empresas com Android

Tutorial: CRUD em Android com SQLite e RecyclerView (Parte 1)

Fazia tempo que este post estava na minha pauta: como fazer um CRUD em Android com SQLite. Mas antes de começar, vamos a algumas definições:

O que é um CRUD? É um acrônimo para Create, Read, Update e Delete, as quatro operações elementares com bancos de dados relacionais.

O que é SQLite? É o banco de dados compacto mais utilizado no mundo e que já vem com suporte nativo na plataforma Android, como banco de dados local nos smartphones.

Se é a primeira vez que está criando um app para Android, sugiro ler primeiro este post aqui, bem mais introdutório: Android Studio Tutorial.

Certifique-se antes de começar de que você possui o Constraint Layout disponível no seu Android Studio, pois usaremos ele aqui como gerenciador de layout. Se você nunca lidou com ele antes, dê uma olhada neste tutorial primeiro.

Avisos feitos, vamos começar o tutorial!

Veremos neste tutorial:

  1. Criando e explorando o projeto Basic
  2. Criando a tela de cadastro/edição
  3. Preparando a persistência de dados
  4. Cadastrando Clientes
  5. Listando Clientes (em breve)
  6. Atualizando Clientes (em breve)
  7. Removendo Clientes (em breve)

Parte 1: Criando e explorando o projeto Basic

Crie um novo projeto no Android Studio com o nome de AndroidCRUD. Durante o assistente de criação do projeto, escolha como Activity inicial a Basic Activity, aquela que tem o botão de + no canto direito. O resto deixe tudo padrão e avance até o final.

A Basic Activity adiciona uma série de elementos prontos que podemos customizar conforme as nossas necessidades. Nossa estrutura de pastas já começa assim:

Estrutura Inicial
Estrutura Inicial

Se abrirmos a MainActivity veremos que ela já possui um evento onCreate com o seguinte código:

Aqui definimos o arquivo XML de layout que é o activity_main.xml, uma toolbar que ficará no topo da Activity e um botão flutuante (Floating Button) que quando clicado vai disparar uma mensagem genérica na Snackbar (uma barra inferior, tipo um Toast mais moderno).

Mais abaixo, temos o código de invocação do menu que fica no canto superior direito da toolbar azul, o que não vem ao caso olharmos agora.

Já na pasta layout temos o activity_main.xml, que foi referenciado no código Java anterior, e o content_main.xml. Isso porque se olharmos o código do activity_main.xml logo abaixo, poderemos notar que ele usa uma tag include para o outro XML, permitindo um reaproveitamento de elementos de layout, assim como fazemos em tecnologias web:

Este XML serve como uma página-mestra do app, garantindo uma uniformidade entre as telas definindo elementos básicos como a toolbar no topo e o floating button no canto inferior direito. Falando dele, por padrão ele veio com um ícone de email, mas podemos mudar isso facilmente, pois faremos um cadastro de clientes, então queremos um sinal de adição como ícone. Note como faço iso pelo próprio editor de XML do Android Studio na propriedade app:srcCompat do FloatingActionButton como abaixo:

Trocando o ícone
Trocando o ícone

Ainda no XML activity_main, na tag include, vamos colocar um id nela para que possamos alterar o XML que ela referencia através de nosso código Java mais tarde, deixe-o como abaixo (incluindo o visibility):

Já o XML content_main.xml contém o “miolo”, a área central a tela, aqui no caso apenas com um Hello World, que mais tarde iremos alterar:

Agora que já criamos e exploramos a estrutura básica do projeto, vamos em frente!

Parte 2: Criando a tela de Cadastro/Edição

Agora que entendemos que a activity_main.xml será o “esqueleto” de todas telas, e que devemos criar apenas os arquivos XML de “miolo”, podemos adicionar um novo arquivo de layout na pasta correspondente com o nome de content_cadastro e com o root tag ConstraintLayout. Configure a aparência desse layout para que represente um formulário de cadastro como abaixo (ou similar):

Layout de Cadastro
Layout de Cadastro

O código desta tela pode ser obtido abaixo:

Alguns pontos a se considerar aqui são o uso de um RadioGroup por fora dos RadioButtons, para garantir que apenas um deles seja selecionável. E o uso de um Spinner para guardar estados, estes por sua vez devem ser armazenados em um estados.xml dentro da pasta res/values:

Agora, voltando à tela activity_main.xml, vamos adicionar um novo include logo abaixo do anterior, referenciando a content_cadastro.xml, mas com uma visibility oculta:

A ideia é que apenas um dos includes seja visível por vez, iniciando com o id includemain e depois trocando para o includecadastro via código Java, quando o usuário clicar no FloatingActionButton. Para que essa transição ocorra, mude o código do clique do FloatingActionButton na MainActivity.java para o código abaixo, que apenas esconde o includemain (e o botão) e exibe o includecadastro:

Para concluir esta etapa de navegação, a tela de cadastro possui um botão de cancelar que não deve fazer nada especial exceto voltar para a tela anterior. Para programar essa transição, vamos incluir o trecho que manipula o onClick do btnCancelar dentro do onCreate da MainActivity.java:

E para já deixar nosso botão de Salvar parcialmente pronto, vamos criar o código abaixo que manipula o onClick do btnSalvar, também na onCreate da MainActivity.java:

Com isso encerramos a criação da tela de cadastro/edição. Ok, não fizemos nada ainda referente à edição, mas você vai entender mais pra frente.

Parte 3: Preparando a persistência de dados

Agora que temos as telas funcionando, com suas devidas posições e o onClick do botão de Salvar apenas esperando pelo código final, vamos programar algumas classes Java que vão cuidar da parte de persistência de dados no SQLite.

Primeiro, adicione no seu package principal do projeto uma classe DbHelper como abaixo, que cuidará do script de criação e atualização do banco de dados, extendendo as funcionalidades da SQLiteOpenHelper nativa do Android:

O método onCreate dessa classe será chamado automaticamente na primeira vez que for realizada uma conexão com o banco de dados, criando-o com uma única tabela ‘Clientes’ conforme SQL informado em uma String final. Os demais parâmetros posicionados como final no topo da classe são auto-explicativos. Esta é a única responsabilidade que daremos para a mesma.

Agora, crie uma segunda classe que vai representar o nosso cliente de banco de dados, que chamaremos DbGateway (conforme o Design Pattern Gateway), que fará as conexões nesta base que acabamos de codificar (por ora, apenas isso):

Nesse DbGateway eu também usei o Design Pattern Singleton para garantir que exista apenas um cliente de banco de dados único para todo o meu app, uma vez que o SQLite não trabalha muito bem com concorrência e porque múltiplas conexões poderiam consumir recursos demais.

Vamos criar também uma nova classe no nosso projeto, uma que espelhe a tabela Clientes do banco de dados, que chamaremos de Cliente.java, nosso data object:

Nada de demais aqui, apenas um bando de atributos e métodos para usar essa classe como uma estrutura de dados de cliente simples. Os métodos sobrescritos serão usados muito mais tarde neste tutorial.

Agora, para finalizar nossa preparação da persistência de dados, vamos criar uma última classe usando o Design Pattern Data Access Object, a ClienteDAO.java, que é a classe responsável por fazer a tradução dos objetos para o banco de dados e vice-versa, abstraindo acesso à dados para uso das telas mais tarde:

Vamos adicionar novos métodos nessa classe nas etapas seguintes deste tutorial, para de fato fazer as operações do nosso CRUD. Por ora, ela terá apenas um construtor que pega a instância única de DbGateway e deixa guardada em uma variável local para uso posterior.

Você notou que no ClienteDAO e no DbGateway precisamos de um objeto Context? Essa é uma necessidade do SQLite, saber qual o Context em que ele está sendo manipulado para questões como permissões entre outras da arquitetura do Android. Passaremos esse Context facilmente mais tarde.

Parte 4: Cadastrando clientes

Agora que temos tanto as telas quanto à persistência de dados nos esperando, vamos finalmente fazer a nossa tela de cadastro funcionar!

Dentro da classe ClienteDAO.java, crie o seguinte método, que usa a DbGateway.java para pegar a conexão atual com o banco de dados e executar um insert no SQLite com os parâmetros recebidos:

Aqui usei as boas práticas recomendadas na documentação oficial do Android, onde diz que para INSERTs devemos usar o método insert informando o nome da tabela e um map de content values com as colunas e valores que queremos inserir.

Agora, no click do botão de Salvar da content_cadastro, vamos chamar essa nossa classe ClienteDAO.java para executar o método salvar (abaixo eu substituo o bloco inteiro original):

Separei esse código em três grandes blocos: no primeiro, apenas referencio localmente os widgets da interface gráfica. No segundo bloco, carrego variáveis locais com os valores de cada widget. E no terceiro, envio para o ClienteDAO realizar o insert retornando se funcionou ou não, retornando à tela anterior.

Se tudo deu certo, você deve conseguir salvar os dados com sucesso, mas não conseguirá vê-los depois de salvo. No tutorial de testes com Android Studio e no de Engenharia Reversa eu ensino como você pode pegar o arquivo do banco de dados SQLite dentro do simulador Android. No entanto, isso não resolve o nosso problema que é o de não ter programado a listagem (SELECT) de clientes ainda, que é o que faremos na segunda parte deste tutorial ainda esta semana, juntamente com as demais letras do CRUD.

Atenção: caso tenha criado seu banco com algum problema ou já tenha enchido o mesmo com muito lixo e queira começar do zero, você pode ir nas configurações dos eu Android (tanto o simulador quanto um dispositivo físico) e limpar os dados do aplicativo. Se isso não resolver, desinstale o app  e mande rodar novamente pelo Android Studio que ele instalará “zerado”.

A segunda parte deste tutorial pode ser conferida neste link.

Já conhece o meu livro de Android? Clique no banner abaixo para conhecer.

Criando apps para empresas com Android