Overwegingen bij het ontwerpen van mobiele toepassingen

Wanneer uw toepassing beeldscherpte verliest vanwege een andere toepassing, wordt de framesnelheid door AIR verlaagd naar 4-frames-per-seconde en wordt het renderen van afbeeldingen stopgezet. Onder deze framesnelheid kunnen verbindingen met streamingnetwerken en sockets worden verbroken. Als uw toepassing dergelijke verbindingen niet gebruikt, kunt u de framesnelheid zelfs nog lager zetten.

Indien van toepassing moet u het afspelen van geluid stopzetten en luisteraars naar de geolocatie en acceleratiemetersensoren verplaatsen. Het AIR NativeApplication-object verzendt het activeren en deactiveren van gebeurtenissen. U kunt deze gebeurtenissen gebruiken om de overgang tussen de actieve status en de achtergrondstatus te regelen.

De meeste besturingssystemen beëindigen achtergrondtoepassingen zonder een waarschuwing te geven. Als u de status van uw toepassing regelmatig opslaat, moet de status van de toepassing automatisch worden hersteld in een redelijke status: hetzij vanuit de achtergrondstatus in een actieve status of door op nieuw op te starten.

De fysieke grootte van het scherm van mobiele apparaten is kleiner dan op het scherm van een desktopcomputer, hoewel de pixeldichtheid (pixels per inch) daarvan hoger is. Dezelfde tekengrootte levert letters op die fysiek kleiner zijn op het scherm van een mobiel apparaat dan op een scherm van een desktopcomputer. U moet vaak een grotere tekengrootte gebruiken om te zorgen dat de tekst leesbaar is. Over het algemeen is een lettergrootte van 14 punten de kleinste lettergrootte die gemakkelijk kan worden gelezen.

Mobiele apparaten worden vaak onderweg gebruikt en onder slechte lichtomstandigheden. Ga na hoeveel informatie u realistisch gezien leesbaar op het scherm kunt weergeven. Het zou wel eens minder kunnen zijn dan u kunt weergeven op een scherm met dezelfde pixeldichtheid op een desktopcomputer.

Houd er ook rekening mee dat bij het aanraken van een scherm een deel van de weergave wordt geblokkeerd door de vinger en hand van de gebruiker. Plaats interactieve elementen aan de zijkanten en onderkant van het scherm wanneer de gebruiker deze langer interactief moet gebruiken dan gedurende een kortstondige aanraking.

Bij veel apparaten wordt een virtueel toetsenbord voor tekstinvoer gebruikt. Virtuele toetsenborden verbergen een deel van het scherm en zijn vaak lastig te gebruiken. U moet proberen te vermijden om afhankelijk te zijn van toetsenbordgebeurtenissen (behalve schermtoetsen).

Implementeer eventueel alternatieven voor het gebruik van invoertekstvelden. Als u de gebruiker bijvoorbeeld een numerieke waarde wilt laten invoeren, hebt u geen tekstveld nodig. U kunt twee knoppen maken om de waarde te verhogen of te verlagen.

Mobiele apparaten beschikken over een verschillend aantal schermtoetsen. Schermtoetsen zijn knoppen die u kunt programmeren voor verschillende functies. Volg de platformconventies voor deze toetsen in uw toepassing.

Mobiele inhoud kan staand en liggend worden weergegeven. Overweeg hoe uw toepassing omgaat met de wijzigingen van de schermoriëntatie. Zie Oriëntatie werkgebied voor meer informatie.

Met AIR wordt niet automatisch voorkomen dat het scherm wordt gedimd als er beelden wordt afgespeeld. U kunt de eigenschap systemIdleMode van het object van de AIR Native Application gebruiken om te beslissen of het apparaat in een energiebesparingsmodus wordt gezet. (Op bepaalde platforms moet u de relevante machtigingen aanvragen om deze functie te kunnen gebruiken.)

Het geluid wordt automatisch door de AIR-runtime gedimd wanneer de gebruiker een telefoongesprek initieert of ontvangt. Bij Android moet u de Android-machtiging READ_PHONE_STATE in de toepassingsdescriptor instellen als door uw toepassing geluid wordt afgespeeld wanneer deze op de achtergrond wordt uitgevoerd. Wanneer u dit niet doet, wordt door Android voorkomen dat telefoongesprekken door de runtime worden gedetecteerd en dat het geluid automatisch wordt gedimd. Zie Android-machtigingen .

Denk na over de grootte van aanraakdoelen wanneer u knoppen en andere elementen voor de gebruikersinterface ontwerpt waarop de gebruiker tikt. Zorg ervoor dat deze elementen groot genoeg zijn om eenvoudig met een vinger op een aanraakscherm te kunnen worden geactiveerd. Zorg er ook voor dat er voldoende tussenruimte is tussen doelen. Het gebied van de aanraakdoelen moet aan elke kant circa 44 pixels tot 57 pixels zijn voor een standaard telefoonscherm met hoge dpi.

Mobiele apparaten hebben doorgaans veel minder opslagruimte voor het installeren van toepassingen en voor gegevens dan desktopcomputers. U moet de grootte van het pakket beperken door ongebruikte assets en bibliotheken te verwijderen.

Bij Android wordt het toepassingspakket niet uitgepakt en in afzonderlijke bestanden geplaatst wanneer een toepassing wordt geïnstalleerd. In plaats daarvan worden assets op een tijdelijke opslaglocatie gedecomprimeerd wanneer deze worden geopend. Voor het minimaliseren van de opslagruimte van de gerecombineerde asset, moet u de bestandsstream en de URL-stream afsluiten wanneer de assets volledig zijn geladen.

De verschillende mobiele besturingssystemen leggen verschillende beperkingen op de bestandssystemen op. Deze beperkingen zijn vaak niet gelijk aan de door bureaubladbesturingssystemen opgelegde beperkingen. De voor het opslaan van bestanden en gegevens geschikte locatie kan dus per platform verschillen.

Een resultaat van deze verschillende bestandssystemen is dat snelkoppelingen naar gemeenschappelijke mappen die door de klasse AIR File worden verschaft niet altijd beschikbaar zijn. De volgende tabel geeft aan welke snelkoppelingen kunnen worden gebruikt voor Android en iOS:

De richtlijnen van Apple voor iOS-toepassingen bieden specifieke regels waarop opslaglocaties moeten worden gebruikt voor bestanden in diverse situaties. Eén richtlijn houdt bijvoorbeeld in dat alleen bestanden met door gebruikers ingevoerde gegevens of gegevens die niet op een andere manier opnieuw kunnen worden gegenereerd of gedownload, in een map moeten worden opgeslagen die is opgegeven voor externe back-up. Zie Back-ups en caching van bestanden beheren voor informatie over het naleven van de richtlijnen van Apple met betrekking tot back-ups en caching van bestanden.

Adobe heeft een versie van het Flex-framework ontwikkeld die is geoptimaliseerd voor mobiele apparaten. Voor meer informatie gaat u naar Developing Mobile Applications with Flex and Flash Builder .

Componenten van communityprojecten die geschikt zijn voor mobiele toepassingen, zijn ook beschikbaar. Deze zijn onder meer:

• Josh Tynjala's Feathers-softwarebesturingselementen voor Starling

• 'skinnable' versie van Minimal Comps van Derrick Grigg

• as3flobile components van Todd Anderson

Vanaf AIR 3.2 biedt AIR for Mobile ondersteuning voor met Stage 3D versnelde rendering van afbeeldingen. De Stage3D -ActionScript-API's worden gevormd door een set laag-niveau-API's met GPU-versnelling die geavanceerde 2D- en 3D-functies mogelijk maken. Deze laag-niveau-API's geven ontwikkelaars de flexibiliteit om GPU-hardwareversnelling te benutten, hetgeen de prestaties aanzienlijk ten goede komt. U kunt ook de gamingengines gebruiken die de Stage3D-ActionScript-API's ondersteunen.

Zie Gamingengines, 3D en Stage 3D voor meer informatie.

Met het oog op de prestaties is het vloeiend maken van video's uitgeschakeld in AIR.

Veel mobiele platformen bieden functionaliteit die nog niet beschikbaar is via de standaard-API van AIR. Vanaf AIR 3 kunt u AIR uitbreiden met uw eigen bibliotheken met native code. Via deze native extensiebibliotheken hebt u toegang tot beschikbare functies van het besturingssysteem en zelfs tot functies die specifiek bij een bepaald apparaat horen. Native extensies kunnen worden geschreven in C voor iOS, en in Java of C voor Android. Zie Inleiding tot native extensies voor Adobe AIR voor meer informatie over het ontwikkelen van native extensies.