Meu primeiro aplicativo Android

Com este artigo pretendo ensinar alguns dos conceitos iniciais do desenvolvimento para dispositivos Android.
São eles:

AndroidManifest.xml, Activity, Layout XML, a classe R e Strings.xml.

No final da leitura o leitor conseguirá iniciar o desenvolvimento nesta plataforma que vem crescendo no mercado de dispositivos móveis no mundo inteiro.

Configurando o ambiente

File → New → Android Application Project esses são os primeiros passos para se criar um aplicativo na ferramenta Eclipse.

Caso você ainda não tenha um ambiente configurado. Vou lhe sugerir duas opções de ferramentas para você começar a criar as suas aplicações.

A primeira opção é o Android Studio. http://developer.android.com/sdk/installing/studio.html
Essa é a ferramenta desenvolvida pela equipe da Google que visa ser uma IDE exclusiva para o Android.
Creio que em pouco tempo essa ferramenta irá se tornar a favorita dos desenvolvedores Android. Porém, hoje em dia (Agosto de 2013) ela esta em fase de testes, e bugs podem ser encontrados.

A segunda opção é o ADT Bundle. http://developer.android.com/sdk/index.html
O ADT Bundle nada mais é do que um pacote que vem com os seguintes itens:

• Eclipse + ADT Plug-in
• Android SDK Tools
• Android Plataform Tools

Hoje em dia é a opção mais utilizada/ indicada.
Até que o Android Studio se firme no mercado.

Nota: Para desenvolver este artigo utilizei o Eclipse.

Conhecendo a estrutura de projeto

Quando criamos um projeto Android, teremos uma estrutura de projeto idêntica a que esta destacada abaixo.

Estrutura de arquivo

Estrutura de arquivo

Em uma rápida analise, podemos ver as seguintes pastas:

src: Este é o diretório onde o desenvolvedor irá colocar todo o código Java do aplicativo.

gen: Este diretório é gerenciado pelo ADT (Android Developer Tool). O desenvolvedor não deve tocar nos arquivos criados aqui dentro. Mas é importante saber que a classe R fica armazenada nesta pasta. (Falaremos desta classe mais a frente)

libs: Na pasta libs você encontrará todos JAR’s e bibliotecas que o aplicativo utilizou. A programação orientada a objetos oferece um bom recurso de modularização. Na internet conseguiremos achar vários tipos de bibliotecas para nos ajudarem a construir qualquer tipo de funcionalidade.
Exemplo: Leitores de JSON, frameworks de persistência, dentre outras coisas. No geral, é muito difícil um aplicativo Android não fazer uso de nenhuma biblioteca externa.

res: É neste diretório que o desenvolvedor encontrará, todos os arquivos de recurso que o aplicativo irá utilizar.
Ou seja, imagens, músicas, vídeos, layouts, strings, dentre outras coisas serão encontradas nos subdiretórios do diretório res.

Informação interessante: Analisando a estrutura podemos identificar 5 pastas com pré-fixo drawable. São nestas pastas que encontraremos todas as imagens utilizadas pelo aplicativo.
Mas por que 5 pastas?
Porque hoje em dia existe dezenas de milhares de dispositivos Android no mundo.
Apesar da variedade imensa de dispositivos todos eles podem ser categorizados em 5 tamanhos/definições de telas distintos, ldpi, mdpi, hdpi, xhdpi e xxhdpi.

Sabendo disso podemos deduzir que uma imagem com um determinado tamanho que ficaria boa em uma tela, não ficaria tão legal em outra.
Então o Android preparou esta arquitetura para que os desenvolvedores conseguissem encaixar a melhor imagem de acordo com o tamanho e a definição da tela.

Exemplificando:

O ícone do aplicativo ficará nessas pastas, vamos chamar esse arquivo de icon.png.

Na pasta drawable-ldpi – Teríamos o icon.png nos tamanhos 36×36.
Na pasta drawable-mdpi – Teríamos o icon.png nos tamanhos 48×48.
Na pasta drawable-hdpi – Teríamos o icon.png nos tamanhos 64×64.
Na pasta drawable-xdpi – Teríamos o icon.png nos tamanhos 72×72.
Na pasta drawable-xxdpi – Teríamos o icon.png nos tamanhos 144×144.

O AndroidManifest.xml
http://developer.android.com/guide/topics/manifest/manifest-intro.html

Ainda analisando a estrutura de projetos podemos ver um arquivo XML, que se destaca pois esta justamente solto na raiz do projeto.
O seu nome é AndroidManifest.xml, e tem a função de ser o principal arquivo de configuração do seu aplicativo.

É nele que definimos:

– O ícone e o nome que serão expostos para o usuário no grid de aplicações do celular.
– Todas as Activitys, Services e BroadcastReceivers que o aplicativo vai usar.
– Definições de segurança.
– Definições de controle de versão.
– Dentre outras coisas.

Logo abaixo podemos analisar um exemplo de AndroidManifest.xml.
Fique atento nos comentários que acrescentei neste arquivo.

<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    package="com.example.meuprimeiroapp"
    android:versionCode="1"
    android:versionName="1.0" >
    
    <!-- 
        package: Define o namespace principal do projeto.
         Esta informação também será utilzada para a construção da URL deste aplicativo no Google Play.
         
         version code: Imaginando um aplicativo que esta no Google Play. E este aplicativo  passa por uma correção de bug.
         É Através deste código, que o Google Play consegue fazer um controle de vesão. 
         Caso o desenvolvedor não altere  essa tag para subir a versão modificada do APP no Google Play
         o Google Play rejeitará o APK.
         
         version name: É a versão que estara disponível para o usuário.Caso o desenvolvedor.
         É aconselhavel alterar o valor da version name, sempre que ocorrer, algo realmente marcante para o usuário.
         Como o acréscimo de uma nova funcionalidae.
    
     -->
   
    <uses-sdk
        android:minSdkVersion="8"
        android:targetSdkVersion="17" />
    
    <!--
      O Android esta em constante evolução.
      Os dispostivos de hoje, possuem muito mais recursos que os primeiros devices criados com o sistema da Google.
      Para gerenciar, qual API o seu sistema irá utilizar e qual versão minima do Android seu aplicativo deve contemplar.
      Foi criado  a tag uses-sdk.
      Cada Numero de API se equivale a uma versão do Android.
      No caso o 8 equivale a versão 2.2 Froyo
      e o 17 equivale a versão Jelly Bean.
      Ou seja, com esta configuração estamos dizendo que este aplicativo, será compatível com celuares que tiverem
      o Android Froyo, porém terá como alvo a versão Jelly Bean.
    --> 
    
    
     <uses-permission android:name="android.permission.INTERNET" />
    
      <!-- 
        Declarando permissões.
        Logo acima estamos definindo que este aplicativo fará uso de acesso a internet.
        Essas permissões são necessárias para que o usuário, saiba exatamente quais recursos o aplicativo que ele esta
        instalando fará uso.
        O Android obriga o desenvolvedor informar esta tag, quando o mesmo for utilizar recursos de Hardware.
        Ou quando for utilizar alguma API que pode representar qualquer perigo ao usuário.
      -->

    <application
        android:allowBackup="true"
        android:icon="@drawable/ic_launcher"
        android:label="@string/app_name"
        android:theme="@style/AppTheme" >
        
        <!-- 
        android:icon:  Diz respeito ao ícone da aplicação. Quando seu app for instalado e estiver disponível para ser acessado
        no container de aplicações do Android. Este ícone que será exibido para representa-lo.
        
        android:label: O nome do aplicativo. Também será exibido no container de aplicações do telefone.
        
        android:theme: Define a aparência de seu aplicativo. O Android já possui alguns por default, mas também existe a
        possibilidade de customização.
         -->
        
        
        <activity
            android:name="com.example.meuprimeiroapp.CadastroPessoa"
            android:label="@string/app_name" >
            <intent-filter>
                <action android:name="android.intent.action.MAIN" />

                <category android:name="android.intent.category.LAUNCHER" />
            </intent-filter>
        </activity>
    </application>
    
    <!--
      Logo acima informamaos uma Activity que o aplicativo possui.
      Todos as Activitys que serão expostas para o usuário, devem ser informadas no AndroidManifest.xml.
      Caso contrário, quando elas forem chamadas, uma excessão ActivityNotFound será disparada.
      
      As tags abaixo, presente na declaração da Activity. Definem que esta Activity será a primeira a ser exibida.
      Assim que o usuário acionar este aplicativo.
        <intent-filter>
                <action android:name="android.intent.action.MAIN" />
                <category android:name="android.intent.category.LAUNCHER" />
            </intent-filter>
     -->
     
     
     <!-- Assim como as Activitys, Services, BroadcastReceivers. Também devem ser declarados aqui no AndroidManifest.xml. -->

</manifest> 

Nota: O link que acompanha o titulo logo acima. Lhe dará todas as informações referentes a este arquivo.

Layout.xml
http://developer.android.com/guide/topics/ui/declaring-layout.html

A arquitetura de interface gráfica do Android é baseada no padrão de projetos MVC (Model – View – Controller).
Onde a camada Model, é responsável pelas regras de negócio da aplicação. A Camada de View, é responsável pela interface gráfica. E a camada de Controller gerencia os eventos de uma determinada tela.

A grande vantagem proporcionada por este padrão é a modularidade. Ou seja, conseguimos alterar todo um layout de uma determinada tela sem mexer no código que diz respeito ao comportamento da mesma.
Imaginando uma tela de login, a cor da tela, o tamanho e a fonte dos botões, tudo que diz respeito a interface gráfica é definido na camada View.
Já o que irá acontecer quando os botões forem clicados será ministrado pela camada de Controller.

Regras de ouro

No Android, os layouts XML assumem o papel de View.
As Activitys assumem o papel de Controller.
E a classe R, faz a ligação entre as duas camadas, permitindo o acesso de recursos encontrados na pasta Res nas Activitys do projeto.

Nota: Você pode criar componentes gráficos diretamente na Activity, sem a necessidade da criação de um layout.xml. No entanto a modularidade citada acima seria perdida.

Para um melhor entendimento vamos a um exemplo prático.
Clique com o botão direito na pasta layout, situada no diretório res.
Após o clique, selecione a opção New → Android XML File.
De o nome deste arquivo de exemplo_layout.xml.

Segue uma imagem para ajudar na identificação do diretório:

DOIS_criando_layout

Um layout.xml é um arquivo que conterá um ou mais componentes gráficos que ficaram expostos para o usuário quando ele entrar no aplicativo.
Quando falo componentes gráficos, estou me referindo a botões, caixa de entrada de texto, rótulos, combo box, dentre outras coisas.

Vejamos alguns componentes:

Os componentes para entrada de texto no Android se chamam EditText.

Os componentes para visualização de texto.(O Label do Swing do Java SE) Se chama TextView.

Os componentes que representam uma ação disponível para o usuário se chama Button.

Nota: Apesar de citarmos apenas três componentes. Existem inúmeros elementos visuais na plataforma Android.
E este numero não para de crescer a medida que a tecnologia evolui.
Inclusive em uma rápida pesquisa na Web você conseguirá encontrar diversos componentes criados pela comunidade Android.

Todos esses componentes herdam da classe View.

Então podemos definir que um layout.xml no Android, é um arquivo onde se encontram um ou mais Views.

Logo abaixo segue um exemplo da declaração de uma View, em um layout.xml.

	
<TextView
        android:layout_width="match_parent"
        android:layout_height="wrap_content"
        android:text="Ola Mundo" />

Veja que se trata do componente TextView. Que irá exibir a mensagem “Ola Mundo”.

Para declarar qualquer View em arquivo XML, o padrão é esse apresentado acima.
Sinal de menor “<” O nome do componente e as suas características, e fecha a estrutura com o sinal de maior com uma barra “/>” . Exemplo:

No nosso exemplo real acima o nome do componente é o TextView e as características que definimos foram:

android:layout_width: Define a largura do componente. Como usamos a constante match_parent. Estamos definindo que esta View irá utilizar o máximo de espaço lateral que puder no layout no qual ele esta inserido.

android:layout_height: Define a altura do componente. Como usamos a constante wrap_content. Estamos definindo que esta View utilizará o mínimo de espaço necessário em relação a altura, para a sua existência.

android:text: Define o texto que será apresentado por este componente.
Existem diversas outras características que poderiam ser utilizadas. Como android:textColor e o android:textSize, responsáveis por definir respectivamente a cor e o tamanho do texto deste componente.

Cada View possui suas próprias características, e alguns atributos são comuns a todas. Afinal todos herdam da super classe View.
Um exemplo de características comuns entre todos os elementos View, são as tags: layout_height e layout_width.

Mas como poderemos organizar, as views em uma tela? Quero dizer, o que vai definir que aquele Button fique no canto esquerdo da tela, ou aquele EditText vai ser o primeiro componente do layout?

Vejamos a resposta desta pergunta.

ViewGroup
http://developer.android.com/reference/android/view/ViewGroup.html

Uma outra classe que herda funcionalidades da classe View é a ViewGroup.

A função do ViewGroup é agrupar um conjunto de Views, e disponibilizar as mesmas no layout com base nas suas próprias características.

Existem vários tipos de ViewGroup, ou seja varias classes que herdam da classe mãe ViewGroup.

As mais populares são:

LinearLayout: Este ViewGroup é um dos mais populares. Irá organizar os componentes com base na sua característica orientation.
A tag orientation pode receber vertical ou horizontal.
Caso o orientation estiver configurado como vertical, os componentes serão exibidos um em cima do outro.
Caso esteja horizontal, os componentes serão exibidos um ao lado do outro.

TableLayout: Esse layout organiza os componentes no formato de tabelas. Colunas e linhas.

RelativeLayout: Esse layout organiza os componentes de um modo mais livre. A definição de onde o componente vai ficar, será definida no própria View.

Vejamos um exemplo de como utilizar o LinearLayout.
No arquivo XML que criamos logo acima, acrescente o seguinte código:

<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
    xmlns:tools="http://schemas.android.com/tools"
    android:layout_width="match_parent"
    android:layout_height="match_parent"
    android:background="@android:color/white"
    android:orientation="vertical"
    >

    <TextView
        android:layout_width="match_parent"
        android:layout_height="wrap_content"
        android:text="Ola Mundo!" />
    
      <TextView
        android:layout_width="match_parent"
        android:layout_height="wrap_content"
        android:text="Olha eu ai logo embaixo!" />

</LinearLayout>

O código listado acima irá gerar a seguinte tela:

tres_reduzido

Analisando o código, percebemos que criamos um LinearLayout no topo do arquivo, este LinearLayout envolve duas TextView antes que seja fechado pela tag

</LinearLayout>

.

Analisando as características do LinearLayout

As primeiras tags envolvidas pelo LinearLayout são:

xmlns:android="http://schemas.android.com/apk/res/android"
xmlns:tools="http://schemas.android.com/tools"

São apenas tags de configuração, com informações úteis para o plug-in do Android.
Estão sempre presentes no topo do layout.xml.

    android:layout_width="match_parent"
    android:layout_height="match_parent"
    android:background="@android:color/white"
    android:orientation="vertical"

Já o trecho de código acima define respectivamente de cima pra baixo a largura e altura, a cor de fundo e a sua orientação.
A orientação por sinal, nesse caso ficou definida como “vertical”.

Por isso os TextView’s ficam alinhados um em cima do outro.

Outro ponto que deve ficar claro:

Um Layout.xml pode ter um ou mais ViewGroups.
Na verdade, é até comum que seja encontrado mais de um ViewGroup em um mesmo Layout.xml.

Vejamos um exemplo abaixo:

<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
    xmlns:tools="http://schemas.android.com/tools"
    android:layout_width="match_parent"
    android:layout_height="match_parent"
    android:background="@android:color/white"
    android:orientation="vertical" >

    <TextView
        android:layout_width="match_parent"
        android:layout_height="wrap_content"
        android:text="Linear Layout UM!" />

    <TextView
        android:layout_width="match_parent"
        android:layout_height="wrap_content"
        android:text="Olha eu ai logo embaixo!" />

    <LinearLayout
        android:layout_width="match_parent"
        android:layout_height="wrap_content"
        android:background="@android:color/black"
        android:orientation="vertical" >

        <EditText
            android:id="@+id/text_view_descricao"
            android:layout_width="match_parent"
            android:layout_height="wrap_content"
            android:text="Linear Layout DOIS!"
            android:textColor="@android:color/white" />

        <Button
            android:id="@+id/button_um"
            android:layout_width="wrap_content"
            android:layout_height="wrap_content"
            android:text="Teste" />
    </LinearLayout>
</LinearLayout> 

O código acima gera o seguinte layout:

QUATRO_modificado

Para destacar a presença dos dois LinearLayout no mesmo Layout.xml, colocamos um com a cor de fundo branca e outro com o plano de fundo preto.
Enquanto o primeiro LinearLayout conta com dois TextView.
O segundo conta com um EditText e um Button.

Agora que criamos os Layouts, temos que saber como interagir com eles. Como faremos que um evento aconteça quando o Button for clicado?

Activity
http://developer.android.com/reference/android/app/Activity.html

Pois bem, como foi falado no início deste artigo. A parte comportamental, como ações de um botão ficam a cargo do Controller no caso do Android representado pela classe Activity.

Quando criamos um projeto Android no Eclipse o wizard de configuração sugere que o projeto se inicie já com uma Activity. Resolvemos aceitar essa opção e colocamos o nome dela de ExemploActivity.

Sobrescrevemos o método onCreate da Activity, é nele que vincularemos o layout xml que criamos anteriormente.

Veja o código logo abaixo:

public class ExemploActivity extends Activity {

	@Override
	protected void onCreate(Bundle savedInstanceState) {
		super.onCreate(savedInstanceState);
		setContentView(R.layout.exemplo_layout);
	}
	
}

Duas coisas devem ser explicadas nesse pequeno trecho de código.

A primeira é o método setContentView, é ele que faz o vínculo da Activity com um layout XML. Este método pode receber como parâmetro um int ou um View.
O int indica que o desenvolvedor passou uma referencia a um layout XML criado na pasta res → layout.
Esta referencia do layout fica mantida pela Classe R gerenciada pelo plug-in do Eclipse.

Automaticamente quando criamos um arquivo exemplo_layout na nossa pasta res → layout.
Um atributo estático com o nome do nosso layout foi criado na Classe R.

É assim que os desenvolvedores conseguem acessar os arquivos colocados na pasta res em suas Activitys ou em qualquer outra classe Java.
Quando uma imagem é colocada na pasta drawable, conseguimos acessa-la via R.drawable.nome_da_imagem.
Quando criamos um layout XML na pasta layout, conseguimos acessa-lo via R.layout.nome_layout.

Outra coisa que devemos entender é a razão do setContentView(int view) ser acionado dentro do onCreate(Bundle instanceSaved).
Isto acontece por causa do ciclo de vida da Activity.

O ciclo de vida da Activity
http://developer.android.com/training/basics/activity-lifecycle/index.html

Toda Activity é criada, fica em contato com o usuário, em algum momento pode ser interrompida (como em um telefonema), em seguida pode ser restaurada ou destruída.

Este é o ciclo de vida de uma Activity, e cada etapa descrita acima é marcada por um método.

Assim que uma Activity é criada, o método onCreate(Bunde instanceSaved) é acionado. É neste momento que o desenvolvedor deve criar a interface gráfica que irá ficar em contato com o usuário.
Daí a necessidade de chamar o método setContentView neste ponto, pois é ele que faz o vinculo do Layout.xml com a Activity.

Quando uma Activity é totalmente destruída o método onDestroy() é acionado. Este é o momento ideal para a liberação dos recursos que estavam sendo consumidos pela Activity.
Por exemplo: Caso esta Activity esteja exibindo um vídeo via streaming por exemplo, este é o momento de cancelar a conexão e liberar o consumo de memória realizada pelo visualizador de vídeo.

A imagem abaixo demonstra o ciclo de vida de uma Activity :

Activity Ciclo de Vida

Tudo começa quando o onCreate() é chamado. A Activity passa a ficar no estado Criado.
Este método é chamado apenas uma vez em todo o ciclo. Aqui o desenvolvedor deve realizar ações como definir uma View principal que será gerenciada pela Activity.

Quando o onStart() é chamado.
A Activity passa a ficar visível para o usuário.

Quando o onResume() é chamado.
A Activity ainda esta visível. Este método existe para interagir com o próximo estado do ciclo apresentado logo abaixo.

Quando o onPause() é chamado.
A Activity esta parcialmente visível, ela foi substituída por um Dialog, mas o usuário ainda poderá vê-la no fundo.
No entanto não estará em contato com a mesma pois estará atuando no Dialog. Quando o Dialog desaparecer, a Activity voltara a ficar a inteira disposição do usuário.
Forçando a Activity a passar novamente pelo método onResume();
Este comportamento da a oportunidade ao desenvolvedor de aproveitar o método onPause() para executar ações como parar animações que estejam ocorrendo na Activity.
E utilizar o onResume() para reiniciar estas animações.

Quando o onStop() é chamado.
Sua Activity não esta mais visível para o usuário. Provavelmente ele apertou o botão Home, ou foi atender a um telefonema, ou até mesmo iniciou uma nova Activity dentro do seu próprio aplicativo.
Agora sua Activity esta no estado parado, mas poderá voltar a ficar em contato com o usuário antes de ser destruída.

Quando o onRestart() é chamado.
Este método só pode ser chamado após o estado parado. Ou seja, sua Activity não estava mais visível e vai voltar a ficar. Aqui o desenvolvedor pode colocar um código de restauração particular para este tipo de situação. Após esse método ser executado, os métodos onStart() e onResume() serão novamente acionados.

Quando onDestroy() for acionado.
Sua Activity foi eliminada completamente. Quando o usuário for aciona-la novamente. O ciclo se reiniciará, passando pelo onCreate();
Para destruir uma Activity basta utilizar o método finish() da própria Activity.

Razões para estudar ciclo de vida:

– Evitar que o seu aplicativo gere um erro e finalize inesperadamente apenas porque o usuário recebeu um telefonema.

– Evitar que usuário perca os dados, ou o progresso que fez em seu sistema por uma saída temporária.

– Evitar consumo desnecessário de recursos.

Convido a você a fazer um teste. Na sua Activity, sobrescreva todos os métodos do ciclo de vida apresentados logo acima. Com a ajuda da classe Log, registre o momento em que cada método for acionado.

Abra sua aplicação, saia da mesma, depois retorne novamente.
O LogCat (console) exibirá quando cada método for executado.

Nota: Se você já programou em java, com certeza já utilizou o método System.out.println(“”) para exibir alguma informação no console.
A classe Log, disponibilizada pelo Android tem a mesma intenção, com a diferença que o valor vai ser exposto no LogCat.
Exemplo de utilização: Log.i(“TAG”, “VALOR”);

Sua Activity ficará assim, para executar este teste:

public class ExemploActivity extends Activity {

	@Override
	protected void onCreate(Bundle savedInstanceState) {
		super.onCreate(savedInstanceState);
		setContentView(R.layout.exemplo_layout);
		Log.i("CICLO", "ON CREATE");
	}

	@Override
	protected void onStart() {
		super.onStart();
		Log.i("CICLO", "ON START");
	}

	@Override
	protected void onRestart() {
		super.onRestart();
		Log.i("CICLO", "ON RESTART");
	}

	@Override
	protected void onResume() {
		super.onResume();
		Log.i("CICLO", "ON RESUME");
	}

	@Override
	protected void onPause() {
		super.onPause();
		Log.i("CICLO", "ON PAUSE");
	}

	@Override
	protected void onStop() {
		super.onStop();
		Log.i("CICLO", "ON STOP");
	}

	protected void onDestroy() {
		super.onDestroy();
		Log.i("CICLO", "ON DESTROY");
	}

}

Agora que sabemos bastante sobre o ciclo de vida da Activity, vamos voltar ao nosso exemplo.
No layout que construímos existe um Button e um componente EditText.

A ideia é que quando o Button for pressionado, uma mensagem com o valor digitado dentro do EditText seja exibida.
Assim conseguiremos saber um pouquinho mais sobre essas duas Views.

Já vimos que o nosso layout esta vinculado a Activity graças ao método setContentView e a referencia do Layout armazenada na classe R.
Agora precisamos pegar a referencia dos componentes que colocamos no layout, para conseguirmos manipula-los na nossa Activity.

Vamos analisar novamente os dois componentes:

                 <EditText
            android:id="@+id/edit_text_descricao"
            android:layout_width="match_parent"
            android:layout_height="wrap_content"
            android:textColor="@android:color/white" />

        <Button
            android:id="@+id/button_um"
            android:layout_width="wrap_content"
            android:layout_height="wrap_content"
            android:text="Teste" />

Analisando com calma, podemos ver um atributo novo que não tínhamos discutido antes neste artigo.
O id.

android:id="@+id/button_um"

Quando o desenvolvedor informa um id para uma View. Automaticamente o plug-in do Android cria um registro deste ID na classe R.
Desse modo conseguiremos acessar essa View, nas nossas Activitys do mesmo jeito no qual conseguimos acessar os layouts, imagens, ou qualquer outro tipo de recurso.

Na prática, a Activity possui um método que se chama findViewById. Este método recebe como parâmetro um int e irá retornar uma View.
O int esperado no parâmetro, é o código armazenado na classe R. E a View de retorno é o componente no qual foi definido o id.

Vejamos um exemplo:

EditText editText = (EditText) findViewById(R.id.edit_text_descricao);
<EditText
       android:id="@+id/edit_text_descricao"

Note que o valor da tag id informada no layout XML no componente referente ao EditText, é o mesmo nome da variável encontrada na classe R.
Após o uso do findViewById teremos uma referencia do EditText em nossa Activity.
Outro ponto a ser esclarecido é que o findViewById retorna um objeto do tipo View, o que nos força a fazer um cast para o tipo que nos desejamos no caso o EditText.
Agora poderemos dar prosseguimento em nossa tarefa e recuperar o valor que o usuário digitou nele através do método getText() do próprio EditText.

String valor = editText.getText().toString();	

Agora nos resta exibir este valor digitado em um dialog para o usuário, assim que o mesmo clicar sobre o botão.

O primeiro passo é recuperar a referencia do botão, fazemos isso da mesma forma que recuperamos o EditText.

Button button = (Button) findViewById(R.id.button_um);

Com a referencia do Button em mãos basta acrescentarmos uma ação ao mesmo.
O Android faz uso do padrão de projeto Observer para tratar eventos de uma View.
Isso implica que devemos passar para o Componente Button a implementação de uma interface. Esta interface define um método que será acionado toda vez que o botão for clicado.

A interface na qual estou me referindo é a

 View.OnClickListener 

e o método que deve ser implementado é o

 public void onClick(View v); 

ou seja sempre que o botão for clicado o método acima será acionado.

O componente Button tem um método no qual vinculamos o Observer nele o setOnClickListener que recebe como parâmetro justamente o Observer que vai ser acionado após o click.

Na prática, o que precisamos para tratar um evento de um botão é o código abaixo.

button.setOnClickListener(new View.OnClickListener() {
			
			@Override
			public void onClick(View v) {
				String valor = editText.getText().toString();
				Toast.makeText(ExemploActivity.this, valor, Toast.LENGTH_SHORT).show();
			}
		});

Basicamente pegamos o valor digitado no EditText e exibimos o mesmo para o usuário usando o Toast.
O Toast nada mais é que um dialog temporário, que irá aparecer para o usuário e irá sumir automaticamente sem que seja necessário qualquer iteração.

Segue abaixo o código completo da Activity:

public class ExemploActivity extends Activity {
	
	private EditText editText;
	private Button button;

	@Override
	protected void onCreate(Bundle savedInstanceState) {
		super.onCreate(savedInstanceState);
		setContentView(R.layout.exemplo_layout);
		Log.i("CICLO", "ON CREATE");
		
		editText = (EditText) findViewById(R.id.edit_text_descricao);
		button = (Button) findViewById(R.id.button_um);
		button.setOnClickListener(new View.OnClickListener() {
			
			@Override
			public void onClick(View v) {
				String valor = editText.getText().toString();
				Toast.makeText(ExemploActivity.this, valor, Toast.LENGTH_SHORT).show();
			}
		});
	}

	@Override
	protected void onStart() {
		super.onStart();
		Log.i("CICLO", "ON START");
	}

	@Override
	protected void onRestart() {
		super.onRestart();
		Log.i("CICLO", "ON RESTART");
	}

	@Override
	protected void onResume() {
		super.onResume();
		Log.i("CICLO", "ON RESUME");
	}

	@Override
	protected void onPause() {
		super.onPause();
		Log.i("CICLO", "ON PAUSE");
	}

	@Override
	protected void onStop() {
		super.onStop();
		Log.i("CICLO", "ON STOP");
	}

	protected void onDestroy() {
		super.onDestroy();
		Log.i("CICLO", "ON DESTROY");
	}

}

Assim terminamos nossa funcionalidade principal de exemplo.

Mas ainda algo que dever ser falado.

Strings.xml
http://developer.android.com/guide/topics/resources/string-resource.html

E se fosse requisito da sua aplicação que este aplicativo funcionasse em diversos idiomas diferentes? Como você faria para preencher os TextView’s com textos diferentes de acordo com a configuração de idiomas do dispositivo?

O Android possui uma estrutura para tratar este tipo de situação. É o arquivo Strings.xml, situado na pasta res → values.

Logo abaixo segue um exemplo deste arquivo:

<?xml version="1.0" encoding="utf-8"?>
<resources>

    <string name="app_name">MeuPrimeiroAPP</string>
    <string name="action_settings">Settings</string>
    <string name="hello_world">Ola Mundo!</string>

</resources>

Ele funciona no formato chave valor. Ou seja, a chave “hello_world” representa o valor “Hellor World!”. Para ter acesso a essa String na Activity novamente devemos fazer uso da classe R. Sempre que criarmos um registro no Strings.xml, um atributo estático é automaticamente criado na Classe R.
Em um exemplo prático, para acessar o registro hello_world situado no Strings.xml, basta utilizarmos R.string.hello_world na nossa Activity.
Esta constante retornada pela classe R será passada como parâmetro do método getString(int res) que existe na própria Activity. Este método lhe retornará uma String que será justamente o “Hello World!” ou seja, o valor que esta definido pela chave hello_world.

Ok! Mas como isso vai me ajudar?

Esta estrutura provê duas vantagens para o desenvolvedor.

Primeira vantagem – Facilidade na manutenção.

Suponha que o sistema possua uma mensagem de sucesso, tipo “Registro salvo com sucesso!”, imagine que esta mensagem apareça em diversos momentos da aplicação.
Caso o seu cliente deseje alterar esta mensagem, o desenvolvedor teria que mudar em apenas um ponto do sistema, e não em todas as telas da aplicação que a mesma iria aparecer.

Segunda vantagem – Internacionalização.

Supondo que queremos colocar este aplicativo para suportar o idioma inglês, basta criarmos uma nova pasta values dentro do diretório res, esta pasta conterá o sufixo da linguagem desejada. No nosso caso ficaria assim: values-en.
Dentro do values-en coloque um novo strings.xml, copie o conteúdo do primeiro arquivo para este novo. Feito isso mude os textos para o idioma inglês.

Exemplo do strings.xml na pasta values-en:

<?xml version="1.0" encoding="utf-8"?>
<resources>

    <string name="app_name">My First APP </string>
    <string name="action_settings">Settings</string>
    <string name="hello_world">Hello world!</string>

</resources>

Acrescente o seguinte código dentro do onCreate de sua Activity:

String helloWorld = getString(R.string.hello_world);
Toast.makeText(ExemploActivity.this, helloWorld, Toast.LENGTH_SHORT).show();

Com esse código, assim que o aplicativo iniciar, uma mensagem com o texto “Hello World” aparecerá na tela do dispositivo como um dialog do tipo Toast.

Mas com um detalhe, quando o dispositivo estiver configurado no idioma português irá aparecer “Ola Mundo” porém quando o mesmo estiver configurado para inglês irá aparecer “Hello World”.

Mude as configurações de idioma do seu telefone e realize o teste.

Outra observação, os idiomas podem se diferenciar de acordo com a a nação.
Por exemplo, o português de Portugal é diferente do português do Brasil.
No Android também podemos tratar este tipo de situação. Ao invés de criar apenas uma nova pasta values-pt crie values-pt-rBR, desse modo estamos definindo não só a língua, mas também o país.

Faça uso do Strings.xml no seu aplicativo!

Agora sim todos os pilares iniciais do Android foram tratados neste artigo.
Até o próximo.

Artigos Relacionados:

https://androiddevbr.wordpress.com/2012/08/10/layout-xml-iniciando-o-desenvolvimento-para-o-android-3/

https://androiddevbr.wordpress.com/2012/08/24/activity-criando-interfaces-graficas-no-android/

Anúncios

  1. #1 by Vanessa on Fevereiro 17, 2016 - 6:57 pm

    Bom mas poderia ser melhor.

  2. #2 by Gabriel Santiago on Junho 18, 2015 - 8:09 pm

    Você poderia fazer um vídeo e postar no youtube ! ^^ Está ajudando muito! Obrigado.

  3. #3 by Ruan on Dezembro 4, 2014 - 4:58 pm

    Show de Bola! …

  4. #4 by João Augusto on Novembro 29, 2014 - 7:28 pm

    Parabéns muito ótimo o seu site me ajudou muito 🙂

  5. #5 by tone on Outubro 13, 2014 - 12:40 am

    Está me ajudando muito!!

  6. #6 by Yury Vidal on Setembro 13, 2014 - 11:13 pm

    Muito obrigado pelo post, me ajudou muito.

  7. #7 by android application on Agosto 7, 2014 - 3:10 pm

    Amazing! Its in fact remarkable paragraph, I have got much clear
    idea regarding from this post.

  8. #8 by joshim on Novembro 26, 2013 - 5:35 pm

    awesome guy, great article

  1. Entendendo Fragment | Android On Board

Deixe uma Resposta

Preencha os seus detalhes abaixo ou clique num ícone para iniciar sessão:

Logótipo da WordPress.com

Está a comentar usando a sua conta WordPress.com Terminar Sessão / Alterar )

Imagem do Twitter

Está a comentar usando a sua conta Twitter Terminar Sessão / Alterar )

Facebook photo

Está a comentar usando a sua conta Facebook Terminar Sessão / Alterar )

Google+ photo

Está a comentar usando a sua conta Google+ Terminar Sessão / Alterar )

Connecting to %s

%d bloggers like this: