Best practices voor best-practices
Het maken van een AEM Mobile On-demand Services-app is anders dan het rechtstreeks maken van een app in de shell Cordova (of PhoneGap). De ontwikkelaars zouden met moeten vertrouwd zijn:
- Insteekmodules die uit de doos evenals de AEM Mobile specifieke stop- ins worden gesteund.
-
Sjablonen die plug-infunctionaliteit gebruiken, moeten zo worden geschreven dat ze nog steeds ontwerpbaar zijn in de browser, zonder dat de plug-inbridge aanwezig is.
- Zorg er bijvoorbeeld voor dat u wacht op de knop deviceready voordat u probeert toegang te krijgen tot de API van een plug-in.
Richtlijnen voor AEM ontwikkelaars guidelines-for-aem-developers
De volgende richtlijnen helpen ervaren AEM ontwikkelaars voor sites die sjablonen en componenten voor mobiele apps willen maken:
Sjablonen voor AEM sites structureren om hergebruik en uitbreidbaarheid aan te moedigen
-
Meerdere componentscriptbestanden verkiezen boven één monolithische scriptbestand
- Er wordt een aantal lege extensiepunten opgegeven, zoals customheaderlibs.html en customfooterlibs.html, waarmee de ontwikkelaar het paginasjabloon kan wijzigen terwijl zo weinig mogelijk kerncode wordt gedupliceerd
- Sjablonen kunnen vervolgens worden uitgebreid en aangepast via Sling sling:resourceSuperType mechanisme
-
Rechtsom/HTML verkiezen boven JSP als sjabloontaal
- Het gebruiken van dit moedigt een scheiding van code van prijsverhoging aan, biedt ingebouwde bescherming XSS, en heeft een meer vertrouwde syntaxis aan
Optimaliseren voor prestaties op het apparaat
- Artikelspecifiek script en stijlpagina's moeten worden opgenomen in de artikellading, met gebruik van de sjabloon voor het synchroniseren van de inhoud van het dps-artikel
- Script en stijlpagina's die door meerdere artikelen worden gedeeld, moeten in gedeelde bronnen worden opgenomen via de sjabloon voor het synchroniseren van dps-HTMLResources-inhoud
- Verwijs niet naar externe manuscripten die teruggeven-blokkeren zijn
Voorkeur voor app-specifieke client JS- en CSS-bibliotheken boven webspecifieke bibliotheken
- Overhead in bibliotheken zoals jQuery Mobile voorkomen om een enorme breedte aan apparaten en browsers af te handelen
- Wanneer een sjabloon wordt uitgevoerd in de webweergave van een app, hebt u controle over de platformen en versies die de toepassing zal ondersteunen, en over de kennis dat JavaScript-ondersteuning aanwezig is. Kies bijvoorbeeld Ionic (misschien alleen de CSS) boven jQuery Mobile en Onsen UI boven Bootstrap.
De voorkeur geven aan microbibliotheken via volledige stapel
- De tijd die nodig is om de inhoud op het glas van het apparaat te krijgen, wordt vertraagd door elke bibliotheek waarvan uw artikelen afhankelijk zijn. Deze vertraging wordt vergroot wanneer een nieuwe webweergave wordt gebruikt om elk artikel te renderen. Elke bibliotheek moet dus opnieuw volledig worden geïnitialiseerd
- Als uw artikelen niet als SPA zijn samengesteld (apps met één pagina), hoeft u waarschijnlijk geen volledige stapelbibliotheek zoals Angular op te nemen
- Voorkeur voor kleinere bibliotheken voor één doel om de interactiviteit toe te voegen die uw pagina nodig heeft, zoals Snelklikken of Snelheid.js
Grootte van artikellading minimaliseren
- Gebruik de kleinst mogelijke middelen die effectief de grootste viewport kunnen behandelen u, bij redelijke resolutie zult steunen
- Een gereedschap gebruiken als ImageOptim in uw afbeeldingen om eventuele overtollige metagegevens te verwijderen
Aan de slag getting-ahead
Zie de volgende bronnen voor meer informatie over de andere twee rollen en verantwoordelijkheden: