Configurações comuns

Especifique a versão do runtime do AIR exigido pelo seu aplicativo usando o namespace do arquivo do descritor do aplicativo.

O namespace, atribuído no elemento do aplicativo , determina, em grande parte, que recursos seu aplicativo pode usar. Por exemplo, se seu aplicativo usa o namespace AIR 2.7, e o usuário tem alguma versão futura instalada, o aplicativo ainda verá o comportamento do AIR 2.7 (mesmo que o comportamento for alterado na versão futura). Somente quando mudar o namespace e publicar uma atualização sua aplicação terá acesso ao novo comportamento e recursos. As correções de segurança são uma importante exceção a essa regra.

Em dispositivos que usam um runtime separado do aplicativo, como o Android no AIR 3.6 e posteriores, será solicitado ao usuário que instale ou atualize AIR se não tiver a versão necessária. Em dispositivos que incorporam o runtime, como o iPhone, esta situação não ocorre (desde que a versão necessária seja fornecida com o aplicativo em primeiro lugar).

Especifique o namespace usando o atributo xmlns do elemento do aplicativo raiz. Os namespaces a seguir devem ser usados para aplicativos móveis (dependendo da plataforma móvel visada):

iOS 4+ and iPhone 3Gs+ or Android: 
                            <application xmlns="http://ns.adobe.com/air/application/2.7"> 
                            iOS only: 
                            <application xmlns="http://ns.adobe.com/air/application/2.0">

Diversas configurações devem ser exclusivas para cada aplicativo que você publicar. Estas incluem o ID, o nome, e o nome de arquivo.

<id>com.example.MyApp</id> 
                                <name>My Application</name> 
                                <filename>MyApplication</filename>

No AIR 2.5 e posterior, especifique a versão do aplicativo no elemento versionNumber . O elemento version não pode mais ser usado. Ao especificar um valor para versionNumber, você deve usar uma sequência de até três números separados por pontos, como: "0.1.2". Cada segmento do número de versão pode ter até três dígitos. (Em outras palavras, "999.999.999" é o maior número de versão autorizada.) Você não precisa incluir todos os três segmentos do número; "1" e "1.0" são números de versão legal.

Você também pode especificar um rótulo para a versão com o elemento versionLabel . Ao adicionar um rótulo de versão este é exibido em vez do número da versão em lugares como a tela de informações dos aplicativos Android. Uma etiqueta de versão deve ser especificada para aplicativos distribuídos através do Android Market. Se você não especificar um valor versionLabel no descritor de aplicativo do AIR, o valor versionNumber é atribuído ao campo de rótulo da versão Android.

<!-- AIR 2.5 and later --> 
                            <versionNumber>1.23.7<versionNumber> 
                            <versionLabel>1.23 Beta 7</versionLabel>

No Android, o AIR versionNumber é traduzido para o Android inteiro versionCode usando a fórmula: a*1000000 + b*1000 + c , onde a, b, e c são os componentes do número da versão do AIR: a.b.c .

Especifique o arquivo SWF do aplicativo principal no filho content do elemento initalWindow . Ao direcionar dispositivos no perfil móvel, você deve usar um arquivo SWF (aplicativos com base HTML não estão disponíveis).

<initialWindow> 
                            <content>MyApplication.swf</content> 
                            </initialWindow>

Você deve incluir o arquivo no pacote AIR (usando ADT ou sua IDE). Simplesmente fazer referência do nome no descritor do aplicativo não faz com que o arquivo seja incluído no pacote de maneira automática.

Vários elementos filho do elemento initialWindow controlam a aparência inicial e o comportamento da tela principal do aplicativo.

• aspectRatio — especifica se o aplicativo deverá ser exibido inicialmente em um formato retrato (altura maior do que largura), um formato paisagem (altura menor do que largura) ou qualquer formato (o palco orienta automaticamente em todas as orientações).

  <aspectRatio>landscape</aspectRatio>

• autoOrients — Especifica se o palco deve mudar automaticamente a orientação quando o usuário gira o aparelho ou executa outro gesto relacionado à orientação, como abertura ou fechamento de um teclado deslizante. Se false , que é o padrão, o palco não mudará a orientação com o dispositivo.

  <autoOrients>true</autoOrients>

• depthAndStencil — Especifica o uso do buffer de profundidade ou de estêncil. Normalmente, você usa esses buffers ao trabalhar com conteúdo 3D.

  <depthAndStencil>true</depthAndStencil>

• fullScreen — Especifica se o aplicativo deve tomar a tela completa do dispositivo, ou se deve compartilhar a tela com o cromo, como uma barra de status do sistema.

  <fullScreen>true</fullScreen>

• renderMode — Especifica se o runtime deve renderizar o aplicativo com a unidade de processamento gráfico (GPU) ou a unidade central de processamento (CPU) principal. Em geral, a renderização da GPU aumentará a velocidade de renderização, mas alguns recursos, como certos modos de mesclagem e filtros PixelBender, não estão disponíveis no modo de GPU. Além disso, diversos dispositivos e drivers de dispositivo diferentes têm diferentes capacidades e limitações de GPU. Você sempre deve testar seu aplicativo em uma ampla variedade de dispositivos possíveis, especialmente quando usando o modo de GPU.

  Você pode definir o modo de renderização como gpu , cpu , direct ou auto . O valor padrão é auto , que no momento volta para o modo de cpu.

  Nota: Para aproveitar a aceleração GPU do conteúdo Flash com o AIR para plataformas móveis, o Adobe recomenda que você use renderMode="direct", o Stage3D e não o renderMode="gpu". A Adobe oferece suporte e recomenda oficialmente as seguintes estruturas baseadas em Stage3D: Starling (2D) e Away3D (3D). Para obter mais detalhes do Stage3D e do Starling/Away3D (3D), consulte http://gaming.adobe.com/getstarted .

  <renderMode>direct</renderMode>

  Nota: Não é possível usar renderMode="direct" para aplicativos executados em segundo plano.

  As limitações do modo de GPU são as seguintes:

  • A estrutura do Flex não suporta o modo de renderização de GPU.

  • Não existe suporte para filtros

  • Mesclagens PixelBender e preenchimentos não estão disponíveis

  • Não há suporte para os seguintes modos de mistura: camada, alfa, apagar, sobrepor, realçar, clarear e escurecer

  • Não é recomendado o uso do modo de renderização pela GPU em um aplicativo que reproduz vídeo.

  • No modo de renderização pela GPU, os campos de texto não são devidamente movidos para um local visível quando o teclado virtual é aberto. Para assegurar que o campo de texto seja visível enquanto o usuário insere texto, use a propriedade softKeyboardRect do palco e os eventos de teclado virtual para mover o campo de texto para a área visível.

  • Se um objeto de exibição não puder ser renderizado pela GPU, ele não é exibido. Por exemplo, se um filtro for aplicado para um objeto de exibição, este não é exibido.

  Nota: A implementação de GPU para iOS no AIR 2.6+ é muito diferente da usada na versão AIR 2.0 anterior. Diferentes considerações de otimização aplicáveis.

Você pode adicionar o elemento supportedProfiles para especificar com quais perfis de dispositivo seu aplicativo é compatível. Use o perfil mobileDevice para dispositivos móveis. Ao executar o aplicativo com o Adobe Debug Launcher (ADL), este usa o primeiro perfil da lista como o perfil ativo. Você também pode usar o sinalizador -profile ao executar o ADL para selecionar um perfil específico na lista de suporte. Se o aplicativo for executado em todos os perfis, você pode excluir o elemento supportedProfiles . O ADL usa o perfil desktop como o perfil padrão ativo neste caso.

Para especificar que o aplicativo é compatível tanto com os perfis desktop quanto com o dispositivo móvel, e que normalmente você quer testar o aplicativo no perfil móvel, adicione o seguinte elemento:

<supportedProfiles>mobileDevice desktop</supportedProfiles>

Os aplicativos que suportam o perfil mobileDevice podem usar extensões nativas.

Indique todas as extensões nativas que o aplicativo do AIR utiliza no descritor do aplicativo. O seguinte exemplo ilustra a sintaxe para especificar duas extensões nativas necessárias:

<extensions> 
                            <extensionID>com.example.extendedFeature</extensionID> 
                            <extensionID>com.example.anotherFeature</extensionID> 
                            </extensions>

O elemento extensionID tem o mesmo valor que o elemento id no arquivo descritor de extensão. O arquivo descritor da extensão é um arquivo XML chamado extension.xml. Ela está compactada no arquivo ANE recebido do desenvolvedor da extensão nativa.

Defina o elemento softKeyboardBehavior como none para desativar o comportamento de deslocamento e redimensionamento automático que o runtime usa para verificar se o campo de entrada de texto está centrado na exibição quando o teclado virtual é gerado. Se você desativar o comportamento automático, seu aplicativo fica responsável por conferir se a área de entrada de texto ou outros conteúdos relevantes estão visíveis após o teclado ser ativado. Você pode usar a propriedade softKeyboardRect do palco em conjunto com SoftKeyboardEvent para detectar quando o teclado é aberto e determinar a área que fica oculta.

Para ativar o comportamento automático defina o valor do elemento para pan :

<softKeyboardBehavior>pan</softKeyboardBehavior>