Introdução

A interface do usuário no Android é baseada na manipulação direta, por meio de ações correspondentes ao mundo real, tais como deslizar, bater (de leve) e o movimento com os dedos similar ao de beliscar para manipular objetos na tela. A resposta destes movimentos é projetada para ser imediata e prover uma sensação de fluidez. Utiliza-se a resposta háptica para que o usuário seja informado da conclusão do comando.

São usados hardwares internos por alguns aplicativos (Ex.: acelerômetros, giroscópios e sensores de proximidade) para responder à ações adicionais dos usuários, como ajustar a tela em formato retrato ou paisagem dependendo de como o dispositivo esteja orientado, ou permitir ao usuário simular o movimento de um volante ao rotacionar o aparelho em jogos automotivos.

A interface do usuário Android divide-se em três áreas distintas:

  • Tela principal (homescreen);
  • Todos os aplicativos (all apps);
  • Tela(s) recente(s) (recent screen).

Os dispositivos Android direcionam-se à sua tela inicial (homescreen) no momento em que são ligados. Nesta tela encontram-se os elementos para navegação primária e principal do sistema, bem similar a uma área de trabalho (desktop) de um computador pessoal. Esta tela é composta pelos ícones de aplicativos instalados e também por widgets, que apresentam na tela informações como notificações de redes sociais, e-mails não lidos, previsão do tempo, notícias, entre muitos outros e atualizam constantemente seu conteúdo.

O usuário ainda pode compor a tela inicial em várias páginas e selecioná-las conforme desejar, e pode também customizá-las conforme suas preferências pessoais. Na loja Google Play disponibilizam-se vários aplicativos desenvolvidos por terceiros que reformulam por completo a tela principal tornando-a similar à de outros sistemas operacionais como Windows Phone e iOS.

Desde sua criação, o Android mudou muito suas características e interfaces. À medida que a tecnologia dos smartphones evoluía, aplicativos cada vez mais complexos são criados.

No começo, os aplicativos para Android não tinham uma interface consistente e regras bem definidas, então, cada aplicativo era desenvolvido com critérios de navegação e posicionamento dos botões diferentes uns dos outros. Isto causava confusão e era uma das características que mais deixava a desejar se comparado ao iOS.

Interface do Usuário

Estrutura dos Aplicativos Android e Padrões de Interface de Usuário

Os aplicativos para Android são muito diferentes uns dos outros, pois tentam adequar-se às diferentes necessidades dos usuários. Existem aplicativos simples com interfaces muito simples com apenas um tipo de visualização e, também existem outros muito mais complexos, com navegação muito mais estruturada e múltiplas opções de visualização.

Em geral, dizemos que um aplicativo Android é composto por visualização principal (top level view) e visualização detalhada (detail/level view).

Figura 2.1 – Visualizações de nível superior e detalhada.

Um dos maiores esforços feitos pelo Google foi definir um conjunto de regras que ajudasse os desenvolvedores a criar interfaces mais atraentes. Ao mesmo tempo, estas regras também ajudavam os usuários a navegar pelos aplicativos. Isto é chamado Consistência de Interface do Usuário. Além disso, o Android garante aos desenvolvedores a flexibilidade requerida para customizar o leiaute do aplicativo e torná-lo único. Estas regras são conhecidas como Padrões de Interface do Usuário. Padrões estes que apresentam soluções para problemas já conhecidos.

Assim, com padrões de interface bem definidos e sabendo onde e como aplicá-los, pode-se criar aplicativos atraentes que não tenham apenas características interessantes, mas que agradem aos usuários e sejam fáceis de usar.

Visualização principal

Como foi dito antes, esta é a tela principal do aplicativo, e por isso deve-se reservar a ela uma atenção especial, pois ela será a primeira tela visualizada pelos usuários. Existem alguns padrões específicos que podem ser aplicados quando desenvolve-se esta tela dependendo do tipo de informação que se deseja mostrar:

  • Fixed tabs (abas fixas);
  • Spinner;
  • Navigation drawer (gaveta de navegação).

Visualização detalhada

Nesta visualização, o usuário interage diretamente com os dados. É possível apresentar e alterar os dados. O leiaute também é muito importante para que os dados sejam bem organizados e estruturados. Neste ponto, pode-se implementar uma navegação eficiente para melhorar a utilização do aplicativo, como por exemplo deslizar a tela para apresentar diferentes tipos de visualizações detalhadas. Pode-se ainda simplificar a interação do usuário dependendo do tipo de componente utilizado para apresentar as informações detalhadas.

Action Bar (Barra de Ação)

Equivalente à seção header de um site (logotipo, título da página e itens de navegação), a barra de ação é relativamente nova no Android. A barra deve ser flexível para que seja possível acomodar ícones, menus ou caixas de texto. Surgiu na versão 3.0 (API nível 11) e apresenta diferentes áreas, tais como:

  • Branding: área reservada ao ícone ou logotipo da aplicação;
  • Área do título;
  • Action Icons (ícones de ação);
  • Contextual Action Bar (CAB ou barra de ação contextual);
  • Bottom bar (barra inferior).

O Action Overflow (figura 2.2), é um menu complementar dropdown utilizado para organizar ações complementares que não couberem na barra de ação.

Figura 2.2 – Barra de ação.

Action Icons (Ícones de Ação)

Encontram-se do centro para o canto direito e servem como atalhos para representar ações que o usuário realiza frequentemente na aplicação. A quantidade de ícones exibidos varia conforme o tamanho da área de exibição do dispositivo.

Figura 2.3 – Exemplos de ícones de ação padrões do Android.

Contextual Action Bar (CAB ou Barra de Ação Contextual)

Barra de ação temporária para substituir itens padronizados durante uma tarefa (Ex.: exibir o número de elementos selecionados em uma lista)

Figura 2.4 – Exemplo de barra de ação contextual.

Up vs. Back

O botão voltar no Android é sempre exibido, virtual ou fisicamente na tela (hardware). Sua função é retornar para a última tela em ordem cronológica, o que muitas vezes consiste em sair do aplicativo em uso, logo, trata-se de uma reflexão do histórico de navegação.
Para evitar a redundância de funções em um aplicativo, faz-se uso do botão “Up”, cujo símbolo é uma seta para a esquerda no canto superior esquerdo ao lado do logotipo. Este botão serve para a tela um nível acima da atual, ou seja, da tela “filha” para a tela “pai”. Esta é a razão do botão “Up” não existir na tela inicial de um aplicativo, pois está no primeiro nível de hierarquia.

Figura 2.5 – Exemplo de “Up vs. Back”.

Bottom Bar (Barra Inferior)

Localiza-se e permanece fixo na parte inferior do rodapé do aplicativo e complementa a barra de ação e também exibe outros ícones de ação.

Figura 2.6 – Exemplo de barra inferior.

Tipos de Navegação

Fixed Tabs (Abas Fixas)

Localizam-se no topo da tela, abaixo da “Barra de Ação”. Sua função é deixar os itens do menu sempre visíveis para facilitar a navegação entre as seções do aplicativo tocando a aba ou rolando a tela para a esquerda ou direita. Este tipo de navegação é ideal para quando é esperado que o usuário alterne de telas com muita frequência. Uma desvantagem é o fato de que devido à diferença de largura entre aparelhos, podem ser bem acomodados no máximo três itens.

Scrollable Tabs (Abas Roláveis)

O princípio de aplicação é bem semelhante ao das abas fixas, mas com a possibilidade de deslizar para o lado e visualizar mais itens. Trata-se de uma combinação das abas fixas a maiores possibilidades de exibição, onde o ideal é de 5 a 7 abas.

Figura 2.7 – Exemplos de abas fixas (esq.) e abas roláveis (dir.).

Spinners

Trata-se de um menu drop-down cujo símbolo é um pequeno triângulo localizado no canto direito inferior da âncora. Normalmente, posiciona-se o Spinner logo abaixo do logotipo do aplicativo para que o menu seja indicado, mas também podem ser utilizados sempre que houver necessidade de otimização de espaço ou apresentar diversas opções de dados.

Figura 2.8 – Exemplo de Spinner.

Navigation Drawer (Gaveta de Navegação)

É um menu deslizante da esquerda para a direita. Ideal para navegações complexas com 3 (três) ou mais itens, pois é um menu global e pode ser acessado em qualquer das telas do aplicativo. Muito prático na navegação em níveis múltiplos e na economia de espaço na tela.
Uma desvantagem é o fato de estar oculta e alguns usuários, por não estarem habituados a este tipo de acesso, levarem um tempo maior para localizá-la.

Figura 2.9 – Exemplo de gaveta de navegação.

Observações Importantes:

  • Evitar utilizar, ao mesmo tempo, vários tipos de navegação;
  • Fazer escolhas com base em critérios tais como: importância, quantidade de itens e frequência de utilização;
  • Utilizar abordagem direta na tela inicial de forma a priorizar informações mais úteis e interessantes em primeiro lugar;
  • Não reutilizar leiautes de outros sistemas operacionais.

Arquitetura Android

Para desenvolver aplicativos na plataforma Android, deve-se ter conhecimento da arquitetura envolvida. A maior parte dos componentes desta plataforma é apresentado no diagrama a seguir:

Figura 3.1 – Diagrama da Arquitetura Android.

System Apps (Aplicativos do Sistema)

A plataforma é composta por vários aplicativos principais (calendário, envio de SMS, e-mail, navegador de internet, contatos, etc.). Apilcativos terceirizados podem ser utilizados em conjunto com os inclusos no sistema, mas existem exceções, como por exemplo o aplicativo de “Configurações do Sistema”.
Os aplicativos que já acompanham a plataforma atuam também como aplicativos para os usuários e podem ser acessados pelos próprios aplicativos (Ex.: Se um aplicativo optar por enviar uma mensagem de texto em SMS, basta invocar o correspondente aplicativo já instalado, não sendo necessário programar esta funcionalidade).

Java API Framework (Estrutura da API Java)

As APIs desenvolvidas em Java tornam possível a disponibilização do conjunto completo de recursos do Sistema Operacional Android. Os blocos de programação necessários para a criação dos aplicativos são formados pela APIs, o que simplifica a reutilização de componentes e serviços de sistemas principais e em módulos, tais como:

  • Extenso sistema de visualização para desenvolver a interface do usuário composto por várias ferramentas (caixas de texto, listas, botões, grades, navegador web);
  • Fornecimento de acesso a recursos não codificados (gráficos, arquivos de leiaute, strings localizadas) através de um gerenciador de recursos;
  • Exibição personalizada de alertas dos aplicativos na barra de status através de um gerador de notificações;
    Fornecimento de pilha de navegação inversa e gerenciamento do ciclo de vida das aplicações por meio de um gerenciador de atividades;
  • Acesso aos dados de um aplicativo por outro ou o compartilhamento dos próprios dados são permitidos através dos provedores de conteúdo.

As APIs das Frameworks que os aplicativos da plataforma Android utilizam são disponibilizadas aos desenvolvedores.

Native C/C++ Libraries (Bibliotecas C/C++ Nativas)

ART e HAL, são alguns dos diversos serviços e componentes da plataforma Android, que são implementados através de codificação nativa, cuja exigências são bibliotecas, também nativas, desenvolvidas em C e C++. Com a finalidade de exibir as funcionalidades de algumas dessas bibliotecas nativas às aplicações, o Sistema Operacional Android fornece as “Java Framework APIs”.
O Android NDK pode ser utilizado para acessar algumas bibliotecas nativas da plataforma fazendo uso direto de seu código nativo, se for exigida codificação em C ou C++ no desenvolvimento do aplicativo.

Android Runtime

As versões do Sistema Operacional Android 5.0 (API nível 21) ou mais recentes executam instâncias próprias do ART (“Android Runtime”) para cada aplicativo. O ART foi desenvolvido para executar várias máquinas virtuais em dispositivos com baixa capacidade de memória através da execução de arquivos DEX (bytecode desenvolvido especificamente para a plataforma Android) que são otimizados de modo a oferecer um mínimo consumo de memória.

Os principais recursos de ART incluem:

  • Capacidade de definição de pontos de controle para monitoramento de campos específicos, compatibilidade de depuração melhorada, exceções de diagnóstico mais detalhadas e geração de relatórios de erros;
  • Coleta de lixo (GC) otimizada;
  • Compilações do tipo JIT (“just-in-time”) e AOT (“ahead-of-time”).

O tempo de execução do Android, antes da versão 5.0 (API nível 21) era realizado pela máquina virtual Dalvik. Aplicações que executam o ART, provavelmente funcionam no Dalvik, mas o caso inverso talvez não seja possível.
As principais bibliotecas de tempo de execução que são responsáveis por fornecer a maior parte das funcionalidades da linguagem Java, e também de Java 8, estão contidas na plataforma Android.

Hardware Abstraction Layer (Camada de Abstração de Hardware (HAL))

As interfaces padronizadas responsáveis por expor as capacidades de hardware do dispositivo em estruturas de maior nível Java API são fornecidas pela HAL.
A HAL é formada por módulos de biblioteca que fazem a implementação de uma determinada interface para um componente de hardware especificado. (Ex.: módulos de câmera ou bluetooth). O Sistema Operacional Android carrega o módulo da biblioteca para o componente de hardware quando uma dada Framework API realiza uma chamada para acessar o hardware do dispositivo.

Linux Kernel (Kernel do Linux)

O “Linux Kernel” é a fundação de toda a plataforma Android. A cobertura das funcionalidades de gerenciamento de memória de baixo nível e encadeamento são confiadas pelo ART ao “Linux Kernel”.
A utilização do “Linux Kernel” permite aos fabricantes de dispositivos desenvolverem drivers de hardware para um kernel já conhecido e, ao mesmo tempo, faz com que a plataforma Android faça melhor proveito dos principais recursos de segurança disponíveis.

Figura 3.2 – Tipos de arquiteturas de hardware suportadas pelo Kernel do Linux.

 

Busque mais

♦ Android

♦ Android operating system

♦ Android UI Design

♦ DevMedia

♦ Desenvolvedores Android

♦ Tableless

♦ 50 UX Best Practices

 


Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *