Considerações a respeito do design do aplicativo móvel

Quando o aplicativo perde o foco para outro aplicativo, o AIR cai a taxa de quadros para 4 quadros por segundo e para a renderização de gráficos. Abaixo desta taxa de quadros, o fluxo de rede e conexões de soquete tendem a serem interrompidos. Se seu aplicativo não usa estas conexões, você pode tornar a taxa de quadros ainda menor.

Quando adequado, você deve parar de reprodução de áudio e remover os listeners para os sensores de geolocalização e acelerômetro. O objeto AIR NativeApplication despacha eventos ativos e inativos. Use estes eventos para gerenciar a transição entre o estado ativo e o estado do plano de fundo.

A maioria dos sistemas operacionais móveis encerram aplicativos em segundo plano sem aviso prévio. Ao salvar o estado do aplicativo com frequência, seu aplicativo deve ser capaz de restaurar-se a um estado razoável seja retornando para o status ativo do plano de fundo ou sendo ativado um novo.

O tamanho físico da tela de dispositivos móveis é menor que na área de trabalho, embora sua densidade em pixels (pixels por polegada) seja mais alta. O mesmo tamanho de fonte produzirá letras que são fisicamente menores na tela de um dispositivo móvel do que em um computador desktop. Muitas vezes é necessário usar uma fonte maior para garantir a legibilidade. Em geral, 14 pontos é o menor tamanho de fonte que pode ser lido facilmente.

Os dispositivos portáteis são frequentemente usados em movimento e em fracas condições de iluminação. Leve em consideração quanta informação você pode realmente mostrar na tela de forma legível. Talvez seja menos que poderia exibir em uma tela com as mesmas dimensões em pixels em uma área de trabalho.

Além disso, considere que quando um usuário está tocando a tela, o dedo e a mão bloqueiam parte da tela de exibição. Coloque elementos interativos nas laterais e na parte inferior da tela quando o usuário tiver de interagir com estes em mais de um toque momentâneo.

Muitos dispositivos usam um teclado virtual para entrada de texto. Teclados virtuais ocultam parte da tela e muitas vezes são complicados de usar. Evite contar com eventos de teclado (exceto teclas de função).

Considere a implantação de alternativas para usar campos de texto de entrada. Por exemplo, não é necessário um campo de texto para o usuário digitar um valor numérico. É possível fornecer dois botões para aumentar ou diminuir o valor.

Os dispositivos móveis incluem um número variável de teclas de função. As teclas de função são botões programáveis para funções diferentes. Siga as convenções de plataforma para essas teclas em seu aplicativo.

É possível visualizar o conteúdo móvel na orientação retrato ou paisagem. Considere a forma como o aplicativo lidará com as alterações na orientação da tela. Para obter mais informações, consulte Orientação do palco .

O AIR não evita automaticamente o escurecimento da tela enquanto o vídeo é reproduzido. Você pode usar a propriedade systemIdleMode do objeto AIR NativeApplication para controlar se o aparelho entrará no modo de economia de energia. (Em algumas plataformas você deve solicitar as permissões adequadas para que esse recurso funcione.)

O runtime de áudio silencia automaticamente quando o usuário faz ou recebe um telefonema. No Android você deve definir a permissão READ_PHONE_STATE no descritor do aplicativo se este reproduz áudio enquanto está no plano de fundo. Caso contrário, o Android impede o runtime de detectar chamadas telefônicas e de silenciar o áudio automaticamente. Consulte Permissões do Android .

Considere o tamanho dos destinos de ocorrência ao projetar botões e outros elementos da interface do usuário que o usuário pressiona. Aumente esses elementos o suficiente para serem ativados confortavelmente com o dedo na tela de toque. Além disso, certifique-se de que existe espaço suficiente entre os destinos. A área de destino deve atingir cerca de 44 pixels por 57 pixels em cada lado de uma tela comum de celular de alta dpi.

Os dispositivos móveis normalmente têm muito menos espaço de armazenamento para a instalação de aplicativos e dados do que os computadores desktop. Reduza o tamanho do pacote eliminando bibliotecas e ativos não utilizados.

No Android o pacote do aplicativo não é extraído em arquivos separados quando um aplicativo é instalado. Em vez disso, os ativos são descompactados em armazenamento temporário quando são acessados. Para reduzir este espaço de armazenamento de ativos descompactados, feche fluxos de URL e o arquivo quando os ativos estiverem completamente carregados.

Sistemas operacionais móveis diferentes impõem diferentes restrições de sistema de arquivos, e essas restrições tendem a ser diferentes das impostas pelos sistemas operacionais de desktop. O lugar apropriado para salvar arquivos e dados, portanto, pode variar de plataforma para plataforma.

Uma consequência da variação no sistema de arquivos é que os atalhos para diretórios comuns fornecidos pela classe AIR File nem sempre estão disponíveis. A seguinte tabela mostra quais atalhos podem ser usados no Android e no iOS:

Diretrizes da Apple para aplicativos iOS fornecem regras específicas sobre os locais de armazenamentos que devem ser usados para arquivos em várias situações. Por exemplo, uma diretriz é que somente arquivos que contenham dados inseridos pelo usuário ou dados que não possam ser recuperados ou baixados novamente devem ser armazenados em um diretório designado para backup remoto. Para obter informações sobre como cumprir as diretrizes da Apple para backup de arquivos e armazenamento em cache, consulte Controlar o backup de arquivos e o armazenamento em cache .

A Adobe desenvolveu uma versão otimizada para dispositivos móveis da estrutura Flex. Para obter mais informações, consulte Desenvolvimento de aplicativos móveis com o Flex e o Flash Builder .

Também estão disponíveis projetos de componentes comunitários adequados para aplicativos móveis. Isso inclui:

• Controles de difusão de IU para Starling de Josh Tynjala

• Versão da Minimal Comps com visual personalizado de Derrick Grigg

• Componentes as3flobile de Todd Anderson

Começando no AIR 3.2, o AIR para dispositivos móveis oferece suporte à renderização de gráficos Stage 3D acelerada. As APIs Stage3D do ActionScript são um conjunto de APIs aceleradas por GPU de baixo nível que ativam as capacidades de 2D e 3D avançadas. Essas APIs de baixo nível fornecem aos desenvolvedores a flexibilidade para aproveitar os significativos ganhos de desempenho. Você também pode usar os mecanismos para jogos que suportem as APIs Stage3D do ActionScript.

Para obter mais informações, consulte Mecanismos para jogos, 3D e Stage 3D .

Para melhorar o desempenho, a suavização de vídeo é desabilitada no AIR.

Muitas plataformas móveis oferecem recursos que ainda não estão acessíveis por meio da API AIR padrão. Começando no AIR 3, você pode estender o AIR com suas próprias bibliotecas de código nativas. Essas bibliotecas de extensão nativas podem acessar recursos disponíveis pelo sistema operacional ou até mesmo específicas de um determinado dispositivo. As extensões nativas podem ser criadas em C no iOS e em Java ou C no Android. Para obter informações sobre o desenvolvimento de extensões nativas, consulte Apresentação de extensões nativas para o Adobe AIR .