Ustawienia wspólne

Kilka ustawień deskryptora aplikacji jest ważnych dla wszystkich aplikacji dla urządzeń przenośnych.

Wymagana wersja środowiska wykonawczego AIR

Wersję środowiska wykonawczego AIR, która jest wymagana przez aplikację, należy określić przy użyciu przestrzeni nazw pliku deskryptora aplikacji.

Przestrzeń nazw (przypisana w elemencie application ) w dużej mierze określa funkcje, których aplikacja może używać. Jeśli na przykład aplikacja korzysta z przestrzeni nazw środowiska AIR 2.7 i użytkownik ma zainstalowaną nowszą wersję, to aplikacja rozpozna zachowania takie jak w środowisku AIR 2.7 (mimo zmiany wersji środowiska na nowszą). Dopiero zmiana przestrzeni nazw i opublikowanie aktualizacji umożliwiają aplikacji uzyskanie dostępu do nowych zachowań i funkcji. Poprawki zabezpieczeń stanowią ważny wyjątek od tej reguły.

Jeśli na urządzeniu korzystającym ze środowiska wykonawczego niezależnie od aplikacji, takim jak urządzenie z systemem Android i środowiskiem AIR 3.6, użytkownik nie ma wymaganej wersji środowiska AIR, jest wyświetlany monit o jej zainstalowanie lub uaktualnienie. Na urządzeniach, w przypadku których środowisko wykonawcze jest osadzone, takich jak telefon iPhone, ta sytuacja nie występuje (ponieważ wymagana wersja jest pakowana z aplikacją).

Uwaga: (AIR 3.7 i nowsze wersje) Domyślnie narzędzie ADT pakuje środowisko wykonawcze wraz z aplikacjami dla systemu Android.

Przestrzeń nazw należy określić przy użyciu atrybutu xmlns głównego elementu application . W przypadku aplikacji dla urządzeń przenośnych należy używać następujących przestrzeni nazw (w zależności od tego, na którą platformę dla urządzeń przenośnych jest przeznaczona aplikacja):

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">
Uwaga: Obsługa urządzeń z systemem iOS 3 jest zapewniana przez zestaw SDK Packager for iPhone, oparty na zestawie SDK środowiska AIR 2.0. Informacje na temat tworzenia aplikacji AIR dla systemu iOS 3 zawiera artykuł Tworzenie aplikacji na telefon iPhone . Zestawy SDK środowiska AIR 2.6 oraz nowszych wersji obsługują system iOS 4 lub nowszy na telefonie iPhone 3G, telefonie iPhone 4 i tablecie iPad.

Tożsamość aplikacji

Niektóre ustawienia powinny być niepowtarzalne dla każdej publikowanej aplikacji. Takie ustawienia obejmują identyfikator, nazwę aplikacji i nazwę pliku.

Identyfikatory aplikacji w systemie Android

W systemie Android identyfikator jest konwertowany na nazwę pakietu Android przez dodanie przedrostka „air.” do identyfikatora AIR. Jeśli więc identyfikator AIR ma wartość com.example.MyApp , wówczas nazwą pakietu Android jest air.com.example.MyApp .

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

Ponadto jeśli identyfikator nie jest poprawną nazwą pakietu w systemie operacyjnym Android, jest on konwertowany na poprawną nazwę. Znaki dywizu są zastępowane podkreśleniami, a cyfry wiodące w każdym składniku identyfikatora są poprzedzane wielką literą „A”. Na przykład identyfikator 3-kozy.1-owca zostanie przekształcony w nazwę pakietu air.A3_kozy.A1_owca .

Uwaga: Przedrostek dodawany do identyfikatora aplikacji może służyć do identyfikowania aplikacji AIR w sklepie Android Market. Jeśli aplikacja nie ma być rozpoznawana jako aplikacja AIR z powodu przedrostka, należy rozpakować plik APK, zmienić identyfikator aplikacji i ponownie spakować go zgodnie z opisem w artykule Rezygnacja z funkcji analizy aplikacji AIR dla systemu Android .

Identyfikatory aplikacji w systemie iOS

Należy ustawić identyfikator aplikacji AIR zgodny z identyfikatorem aplikacji utworzonym w witrynie iOS Provisioning Portal firmy Apple.

Identyfikatory aplikacji systemu iOS składają się z identyfikatora wartości początkowej pakietu, po którym następuje identyfikator pakietu. Identyfikator wartości początkowej pakietu to ciąg znaków, taki jak 5RM86Z4DJM, przypisywany przez firmę Apple do identyfikatora aplikacji. Identyfikator pakietu zawiera wybraną przez użytkownika nazwę w odwrotnej notacji domen. Identyfikator pakietu może kończyć się znakiem gwiazdki (*) oznaczającym wieloznaczny identyfikator aplikacji. Jeśli identyfikator pakietu kończy się znakiem wieloznacznym, ten znak można zastąpić dowolnym poprawnym ciągiem.

Na przykład:

  • Jeśli identyfikator aplikacji Apple to 5RM86Z4DJM.com.example.witamWszystkich , w deskryptorze aplikacji należy zastosować ciąg com.example.witamWszystkich .

  • Jeśli identyfikator aplikacji Apple to 96LPVWEASL.com.example.* (wieloznaczny identyfikator aplikacji), wówczas można użyć identyfikatora com.example.witamWszystkich , com.example.innaAplikacja lub innego identyfikatora zaczynającego się od ciągu com.example .

  • Jeśli identyfikator aplikacji Apple składa się wyłącznie z identyfikatora wartości początkowej pakietu i znaku wieloznacznego, na przykład 38JE93KJL.* , wówczas w środowisku AIR można użyć dowolnego identyfikatora aplikacji.

Podczas określania identyfikatora aplikacji nie należy uwzględniać fragmentu identyfikatora aplikacji określającego identyfikator wartości początkowej pakietu.

Wersja aplikacji

W środowisku AIR 2.5 lub nowszym wersję aplikacji należy określić w elemencie versionNumber . Nie można już stosować elementu version . Określając wartość elementu versionNumber , należy użyć sekwencji składającej się z maksymalnie trzech liczb rozdzielonych kropkami, na przykład „0.1.2”. Każda z tych liczb w numerze wersji może zawierać do trzech cyfr. Innymi słowy, największym dozwolonym numerem wersji jest „999.999.999”. Numer wersji nie musi zawierać wszystkich trzech liczb. Zarówno „1”, jak i „1.0” stanowią prawidłowe numery wersji.

Przy użyciu elementu versionLabel można określić etykietę wersji. Po dodaniu etykiety wersji jest ona wyświetlana zamiast numeru wersji w takich miejscach jak ekran informacyjny aplikacji systemu Android. Aplikacje rozpowszechniane za pomocą sklepu Android Market muszą mieć określoną etykietę wersji. Jeśli w deskryptorze aplikacji AIR nie zostanie określona wartość versionLabel , wówczas do pola etykiety wersji systemu Android zostanie przypisana wartość versionNumber .

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

W systemie Android element versionNumber środowiska AIR jest konwertowany na liczbę całkowitą systemu Android versionCode przy użyciu wzoru a*1000000 + b*1000 + c , gdzie a, b i c są elementami numeru wersji środowiska AIR: a.b.c .

Główny plik SWF aplikacji

Należy określić główny plik SWF aplikacji w elemencie potomnym content elementu initialWindow . Jeśli aplikacja jest przeznaczona na urządzenia o profilu urządzenia przenośnego, należy używać pliku SWF. (Aplikacje oparte na standardzie HTML nie są obsługiwane).

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

Plik musi zostać umieszczony w pakiecie aplikacji AIR (przy użyciu narzędzia ADT lub środowiska programistycznego). Samo umieszczenie odniesienia do nazwy w deskryptorze aplikacji nie powoduje automatycznego zawarcia pliku w pakiecie.

Właściwości ekranu głównego

Kilka elementów potomnych elementu initialWindow steruje początkowym wyglądem i działaniem głównego ekranu aplikacji.

  • aspectRatio — określa, czy aplikacja powinna być na początku wyświetlana w formacie portrait (pionowym, z wysokością większą niż szerokość), landscape (poziomym, z wysokością mniejszą niż szerokość, czy any (dowolnym, z orientacją określaną automatycznie przez stół montażowy).

    <aspectRatio>landscape</aspectRatio>
  • Element autoOrients określa, czy orientacja stołu montażowego powinna automatycznie zmieniać się, gdy użytkownik obraca urządzenie lub wykonuje inne gesty związane z orientacją, takie jak otwieranie lub zamykanie wysuwanej klawiatury. Jeśli ten element ma wartość false , która jest wartością domyślną, wówczas stół montażowy nie zmienia orientacji razem z urządzeniem.

    <autoOrients>true</autoOrients>
  • depthAndStencil — Określa, czy ma być używany bufor głębi czy bufor szablonu. Te bufory są zazwyczaj używane podczas pracy z zawartością 3D.

    <depthAndStencil>true</depthAndStencil>
  • Element fullScreen określa, czy aplikacja powinna zajmować cały wyświetlacz, czy powinna współdzielić wyświetlacz z normalną karnacją systemu operacyjnego, na przykład z systemowym paskiem stanu.

    <fullScreen>true</fullScreen>
  • Element renderMode określa, czy środowisko wykonawcze powinno renderować aplikację za pomocą GPU czy procesora (CPU, central processing unit). Renderowanie za pomocą GPU zazwyczaj zwiększa wydajność, ale niektóre funkcje, takie jak pewne tryby mieszania i filtry PixelBender, są niedostępne w trybie GPU. Ponadto różne urządzenia i różne sterowniki urządzeń mają inne możliwości oraz ograniczenia dotyczące GPU. Aplikację należy zawsze testować na możliwie największej liczbie urządzeń, szczególnie w przypadku używania trybu GPU.

    Można ustawić tryb renderowania gpu , cpu , direct lub auto . Wartością domyślną jest auto , co obecnie oznacza wybranie trybu cpu.

    Uwaga: Aby można było stosować przyspieszanie GPU zawartości Flash w środowisku AIR dla platform przenośnych, firma Adobe zaleca, aby zamiast opcji renderMode="direct" (obiektu Stage3D) użyć opcji renderMode="gpu". Firma Adobe oficjalnie oferuje pomoc techniczną dla następujących architektur opartych na obiekcie Stage3D i zaleca ich stosowanie: Starling (2D) i Away3D (3D). Więcej informacji o architekturach Stage3D oraz Starling/Away3D znajduje się w dokumencie http://gaming.adobe.com/getstarted/ .
    <renderMode>direct</renderMode>
    Uwaga: W przypadku aplikacji działających w tle nie można używać parametru renderMode z wartością „direct”.

    Ograniczenia trybu GPU:

    • Architektura Flex nie obsługuje trybu renderowania GPU.

    • Filtry nie są obsługiwane.

    • Mieszanie PixelBender i wypełnianie nie są obsługiwane.

    • Nie są obsługiwane tryby mieszania: layer, alpha, erase, overlay, hardlight, lighten, darken.

    • Nie jest zalecane korzystanie z trybu renderowania GPU w aplikacji odtwarzającej wideo.

    • W trybie renderowania GPU pola tekstowe nie są prawidłowo przenoszone w widoczne miejsca po otwarciu klawiatury wirtualnej. W celu zapewnienia widoczności pola tekstowego podczas wpisywania tekstu przez użytkownika należy przesunąć pole tekstowe w obręb widocznego obszaru za pomocą właściwości softKeyboardRect stołu montażowego oraz zdarzeń klawiatury programowej.

    • Jeśli GPU nie może renderować danego obiektu ekranowego, w ogóle nie zostanie on wyświetlony. Jeśli na przykład względem obiektu ekranowego zostanie zastosowany filtr, obiekt nie zostanie wyświetlony.

    Uwaga: Implementacja funkcji GPU dla systemu iOS w środowisku AIR 2.6+ znacznie różni się od implementacji stosowanej we wcześniejszej wersji środowiska AIR (2.0). Są stosowane inne założenia optymalizacji.

Obsługiwane profile

Można dodać element supportedProfiles w celu określenia, które profile urządzeń obsługuje dana aplikacja. Dla urządzeń przenośnych należy używać profilu mobileDevice. W przypadku uruchamiania aplikacji za pomocą narzędzia Adobe Debug Launcher (ADL) ten program używa jako profilu aktywnego pierwszego profilu na liście. Podczas uruchamiania narzędzia ADL można użyć flagi -profile w celu wybrania konkretnego profilu z listy obsługiwanych. Jeśli aplikacja działa we wszystkich profilach, można całkowicie pominąć element supportedProfiles . Narzędzie ADL użyje wówczas profilu komputera stacjonarnego jako domyślnego profilu.

Aby określić, że aplikacja obsługuje profile dla urządzeń przenośnych i komputerów oraz że normalnie ma być testowana w profilu dla urządzeń przenośnych, należy dodać następujący element:

<supportedProfiles>mobileDevice desktop</supportedProfiles>

Wymagane rozszerzenia natywne

Aplikacje obsługujące profil mobileDevice mogą korzystać z rozszerzeń natywnych.

Wszystkie rozszerzenia natywne używane przez aplikację AIR należy zadeklarować w deskryptorze aplikacji. W poniższym przykładzie przedstawiono składnię umożliwiającą określenie dwóch wymaganych rozszerzeń natywnych:

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

Element extensionID ma wartość taką samą jak element id w pliku deskryptora rozszerzenia. Plik deskryptora rozszerzenia jest plikiem XML o nazwie extension.xml. Jest on spakowany w pliku ANE otrzymanym od programisty rozszerzenia natywnego.

Działanie klawiatury wirtualnej

Aby wyłączyć działanie automatycznego panoramowania i zmieniania rozmiaru — funkcji stosowanych przez środowisko wykonawcze w celu zapewnienia widoczności aktywnego pola wpisywania danych po uniesieniu klawiatury wirtualnej — dla elementu softKeyboardBehavior należy ustawić wartość none . Jeśli zachowanie automatyczne zostanie wyłączone, wówczas to aplikacja będzie odpowiedzialna za gwarantowanie widoczności obszaru wpisywania tekstu lub innej ważnej zawartości po uniesieniu klawiatury. Do wykrywania momentu otwierania klawiatury i zakrywanego przez nią obszaru można używać właściwości softKeyboardRect stołu montażowego w połączeniu z obiektem SoftKeyboardEvent.

Aby włączyć automatyczne zachowanie, dla tego elementu należy ustawić wartość pan .

<softKeyboardBehavior>pan</softKeyboardBehavior>
Wartość pan jest wartością domyślną, więc pominięcie elementu softKeyboardBehavior również powoduje włączenie automatycznego zachowania klawiatury.
Uwaga: Jeśli jest również stosowane renderowanie GPU, nie jest obsługiwane zachowanie panoramowania.