Interface de usuário - Parte 2

No post passado falei um pouco sobre as interfaces e agora dou continuidade a esse assunto tão importante. Falei das Views e ViewGroup, da hierarquia das Views, dos Layouts e Widgets. Obviamente vou voltar a cada um deles com maior detalhe. Vou apenas terminar a introdução nesse post e retornar a cada um deles.

Eventos de Interface

Uma vez que você coloca os widgets dentro dos layouts nas interfaces que vai montar, provavelmente vai querer saber sobre a interação do usuário com eles, para que assim possa chamar ações. Para ser informado dos eventos de interface, você precisa fazer uma de duas coisas:

• Definir um event listener e registrá-lo com a View. Mais frequentemente do que podemos pensar, essa é a maneira como você vai interceptar os eventos. A classe View contém uma coleção de interfaces aninhadas chamadas On<AlgumaCoisa>Listener, cada um com o método callback chamado On<AlgumaCoisa>(). Por exemplo, View.OnClickListener (para que possa ser interceptados os clicks em uma View), View.OnTouchListener (para interceptar os eventos touch screen na View) e View.OnKeyListener (para interceptar teclas que sejam pressionadas no dispositivo). Se você quer que sua View seja notificada quando ouver um click (como um botão sendo pressionado), implemente o OnClickListener e defina o método callback OnClick e o registre para a View com setOnClickListener().
• Fazer um override de um método callback para a View. Isso é o que você pode fazer quando você implementou sua própria View class e quer escutar eventos específicos que ocorrem dentro dele. Eventos de exemplo que você pode interceptar é quando a tela é tocada (onTouchScreen()), quando o trackball é movido (onTrackballEvent()), ou quando uma tecla é pressionada (onKeyDown()). Isso permite que você defina o comportamento padrão de cada evento dentro da View customizada e determinar se o evendo deverá ser passado para alguma view filha. Veja bem, esses são callbacks da classe view e portanto você só poderá definí-las quando você cria um componente customizado.

Menus

Menus de aplicação são outra parte importante da interface da aplicação. Menus oferecem uma interface confiável que revela funções da aplicação e configurações. A mais comum aplicação de menu é revelada pressionando o botão MENU do dispositivo. Contudo, você pode criar menus de contexto, que podem ser revelados quando o usuário pressiona um botão no dispositivo.

Essa é, na minha opinião, uma das coisas mais interessantes quando se programa para o Android. Quando se programa para o iOS, da Apple, você tem de deixar todas as opções de acesso a menus e outras configurações sendo mostradas na tela, no formato de botões ou imagens. A razão disso é o formato minimalista dos gadgets da Apple, que têm apenas botão na parte posterior deles, o home button. Alguém poderá argumentar que é uma vantagem ter apenas um botão, principalmente para aqueles que entendem pouco de informática - como minha mãe, por exemplo, que usa um iPad tranquilamente mas não sabe para onde vai um PC.

Eu me sinto mais confortável tendo a possibilidade de usar menus de contexto, que retornam opções relativas à aplicação que está sendo executada no momento. É uma vantagem quando se pensa que o aplicativo criado para Android poderá ter uma interface ainda mais minimalista, já que não precisará de um botão dentro do app para acessar suas configurações, diferente dos apps para o iOS. A desvantagem, no entanto, é que alguns usuários poderão demorar a se adaptar a uma interface desta. Como tudo na vida, há as vantagens e desvantagens. Mesmo assim, continuo achando que os benefícios são maiores que os malefícios.

Menus são também estruturados usando a hierarquia da View, mas você não define essa hierarquia. Ao invés disso, você define os métodos de callback onCreateOptionsMenu() ou onCreateContextMenu() para a sua atividade e declara os itens que quer incluir em seu menu. No momento apropriado, o Android vai automaticamente criar a hierarquia de view necessária para que o menu e para que ele seja desenhado com seus itens posicionados.

Menus podem interceptar seus próprios eventos, então não há a necessidade de registrar listeners de eventos nos itens de seu menu. Quando um item de seu menu é selecioinado, os métodos onOptionsItemSelected() ou onContextItemSelected() serão chamados pelo framework.

E, como seu layout de aplicação, você tem a opção de declarar os itens de seus menus em um arquivo XML.

Então, é só isso?

Não, isso é apenas o pontapé inicial. Ainda temos os Adapters e os Estilos e Temas, que só abordaremos quando necessário.

Por hora, basta dizer que os adapters são conjunto de objetos que atuam como uma ponte entre os seus dados (que podem estar guardados em um arquivo XML ou outro tipo de media, como um banco de dados SQlite).

E os Estilos e temas são a maneira como você poderá customizar a aparência dos seus itens na tela. Não gosta do design de um botão? Modifique-o com os estilos e temas. Eles são recursos e, portanto, poderão ser reutilizados em qualquer parte da sua aplicação.

E agora? Quero mais, quero começar a criar minhas interfaces e começar a fazer meus projetos!

No próximo post, quero falar sobre algo chamado StoryBoard e de como podemos usar esse conceito para criar nossa aplicação e ter a exata noção de como tudo ficará ao final da programação.