Adobe consiglia di utilizzare l'editor SPA per i progetti che richiedono il rendering lato client basato sul framework dell'applicazione a pagina singola (ad es. React). Per saperne di più.
La creazione di un sito mobile è simile alla creazione di un sito standard, ma richiede anche la creazione di modelli e componenti. Per ulteriori dettagli sulla creazione di modelli e componenti, consulta le pagine seguenti: Modelli, Componenti e Guida introduttiva allo sviluppo AEM Sites. La differenza principale consiste nell'abilitare le funzionalità mobili integrate AEM all'interno del sito. Viene ottenuto creando un modello basato sul componente Pagina mobile.
È inoltre consigliabile utilizzare responsive design, creando un singolo sito che supporti diverse dimensioni di schermo.
Per iniziare, è possibile consultare il Sito demo mobile We.Retail disponibile in AEM.
Per creare un sito mobile, effettuate le seguenti operazioni:
Creare il componente Pagina:
Impostare la proprietà sling:resourceSuperType
su wcm/mobile/components/page
In questo modo il componente si basa sul componente pagina mobile.
Create l'elemento body.jsp
con la logica specifica del progetto.
Create il modello di pagina:
sling:resourceType
sul componente pagina appena creato.allowedPaths
.Create la pagina di progettazione per il sito.
Crea la pagina principale del sito sotto il nodo /content
:
cq:allowedTemplates
.cq:designPath
.Nelle proprietà della pagina principale del sito, impostare i gruppi di dispositivi nella scheda Mobile.
Create le pagine del sito utilizzando il nuovo modello.
Componente pagina mobile ( /libs/wcm/mobile/components/page
):
head.jsp
, recupera il gruppo di dispositivi mobili corrente dalla richiesta e, se viene trovato un gruppo di dispositivi, utilizza il metodo drawHead()
del gruppo per includere il componente init dell'emulatore associato del gruppo di dispositivi (solo in modalità di creazione) e il CSS di rendering del gruppo di dispositivi.La pagina principale del sito mobile deve trovarsi al livello 1 della gerarchia dei nodi e si consiglia di trovarsi sotto il nodo /content.
Multi Site Manager (MSM) consente di creare una Live Copy mobile da un sito standard. Il sito standard viene automaticamente trasformato in un sito mobile: il sito mobile presenta tutte le funzioni dei siti mobili (ad es. edizione all’interno di un emulatore) e può essere gestito in sincronia con il sito standard. Fare riferimento alla sezione Creazione di una Live Copy per diversi canali nella pagina Gestione multisito.
I pacchetti Java contenenti le classi mobili sono:
com.day.cq.wcm.mobile.api - Definisce MobileConstants.
com.day.cq.wcm.mobile.api.device - definisce Device, DeviceGroup e DeviceGroupList.
com.day.cq.wcm.mobile.api.device.functionality - definisce DeviceCapability.
com.day.cq.wcm.mobile.api.wurfl - definisce WurflQueryEngine.
com.day.cq.wcm.mobile.core - definisce MobileUtil, che fornisce vari metodi di utilità ruotanti attorno a WCM Mobile.
Il sito dimostrativo We.Retail Mobile utilizza i seguenti componenti mobili, che si trovano sotto /libs/foundation/components
:
Nome | Gruppo | Caratteristiche |
mobilepiè di pagina | nascosto | - piè di pagina |
mobileimage | Mobile | - basato sul componente base immagine - esegue il rendering di un'immagine se il dispositivo è in grado di eseguire il rendering |
mobilista | Mobile | - in base al componente di base dell'elenco - listitem_teaser.jsp esegue il rendering di un'immagine se il dispositivo è in grado |
mobilelogo | nascosto | - in base al componente di base del logo - esegue il rendering di un'immagine se il dispositivo è in grado di eseguire il rendering |
mobilereferenza | Mobile | - simile al componente Base riferimento - mappatura di un componente di testo su un modello mobile e di un componente immagine su un’immagine mobile |
mobiletextimage | Mobile | - in base al componente di base del testo - esegue il rendering di un'immagine se il dispositivo è in grado di |
mobiletopnav | nascosto | - in base al componente di base nav superiore - esegue solo il rendering del testo |
Il framework mobile AEM consente di sviluppare componenti sensibili al dispositivo che emette la richiesta. Gli esempi di codice riportati di seguito mostrano come utilizzare l'API mobile AEM in un jsp componente e in particolare come:
Ottenete il dispositivo dalla richiesta:
Device device = slingRequest.adaptTo(Device.class);
Ottenete il gruppo di dispositivi:
DeviceGroup deviceGroup = device.getDeviceGroup();
Ottenete le funzionalità del gruppo di dispositivi:
Collection<DeviceCapability> capabilities = deviceGroup.getCapabilities();
Ottenete gli attributi del dispositivo (chiave/valori della funzionalità non elaborati dal database WURFL):
Map<String,String> deviceAttributes = device.getAttributes();
Ottenere l’agente utente del dispositivo:
String userAgent = device.getUserAgent();
Ottenete l’elenco dei gruppi di dispositivi (gruppi di dispositivi assegnati al sito dall’autore) dalla pagina corrente:
DeviceGroupList deviceGroupList = currentPage.adaptTo(DeviceGroupList.class);
Verificate se il gruppo di dispositivi supporta le immagini
if (deviceGroup.hasCapability(DeviceCapability.CAPABILITY_IMAGES)) {
…
OPPURE
if MobileUtil.hasCapability(request, DeviceCapability.CAPABILITY_IMAGES) {
…
In un jsp, slingRequest
è disponibile tramite il tag <sling:defineObjects>
e currentPage
tramite il tag <cq:defineObjects>
.
L’authoring basato su emulatore offre agli autori gli strumenti per creare pagine di contenuto destinate ai client mobili. La creazione di contenuti per dispositivi mobili segue lo stesso principio della modifica WYSIWYG locale. Affinché gli autori possano percepire l’aspetto della pagina su un dispositivo mobile, una pagina di contenuto mobile viene modificata utilizzando un emulatore di dispositivo.
Gli emulatori dei dispositivi mobili si basano sul framework emulatore generico. Per ulteriori dettagli, fare riferimento alla pagina Emulatori.
L'emulatore del dispositivo visualizza il dispositivo mobile sulla pagina, mentre la modifica standard (parsys, components) avviene all'interno dello schermo del dispositivo. L'emulatore del dispositivo dipende dai gruppi di dispositivi configurati per il sito. Diversi emulatori possono essere assegnati a un gruppo di dispositivi. Tutti gli emulatori sono quindi disponibili nella pagina del contenuto. Per impostazione predefinita viene visualizzato il primo emulatore assegnato al primo gruppo di dispositivi assegnato al sito. Gli emulatori possono essere attivati tramite il carosello emulatore nella parte superiore della pagina o tramite il pulsante di modifica della barra laterale.
Creazione di un emulatore
Per creare un emulatore, fare riferimento alla sezione Creazione di un emulatore mobile personalizzato nella pagina Emulatori generici.
Caratteristiche principali degli emulatori mobili
Un gruppo di dispositivi è composto da uno o più emulatori: la pagina di configurazione del gruppo di dispositivi, ad esempio /etc/mobile/groups/touch, contiene la proprietà emulators
sotto il nodo jcr:content
.
Nota: anche se è possibile che lo stesso emulatore appartenga a diversi gruppi di dispositivi, non ha molto senso.
Tramite la finestra di dialogo di configurazione del gruppo di dispositivi, la proprietà emulators
viene impostata con il percorso dell'emulatore o degli emulatori desiderati. Esempio: /libs/wcm/mobile/components/emulators/iPhone4
.
Componenti dell’emulatore (ad esempio /libs/wcm/mobile/components/emulators/iPhone4
) estendere il componente emulatore mobile di base ( /libs/wcm/mobile/components/emulators/base
).
Ogni componente che estende l’emulatore mobile di base è disponibile per la selezione quando si configura un gruppo di dispositivi. Gli emulatori personalizzati possono quindi essere facilmente creati o estesi.
Al momento della richiesta in modalità di modifica, l'implementazione dell'emulatore viene utilizzata per eseguire il rendering della pagina.
Quando il modello della pagina dipende dal componente della pagina mobile, le funzionalità dell'emulatore vengono automaticamente integrate nella pagina (tramite head.jsp
del componente della pagina mobile).
I gruppi di dispositivi mobili forniscono la segmentazione dei dispositivi mobili in base alle funzionalità del dispositivo. Un gruppo di dispositivi fornisce le informazioni necessarie per l’authoring basato sull’emulatore nell’istanza di creazione e per il corretto rendering del contenuto nell’istanza di pubblicazione: dopo che gli autori hanno aggiunto contenuto alla pagina mobile e l’hanno pubblicata, la pagina può essere richiesta nell’istanza di pubblicazione. Qui, invece della visualizzazione di modifica dell'emulatore, viene eseguito il rendering della pagina del contenuto utilizzando uno dei gruppi di dispositivi configurati. La selezione del gruppo di dispositivi avviene in base al rilevamento dei dispositivi mobili. Il gruppo di dispositivi corrispondente fornisce quindi le informazioni di stile necessarie.
I gruppi di dispositivi sono definiti come pagine di contenuto sotto /etc/mobile/devices
e utilizzano il modello Mobile Device Group. Il modello per gruppi di dispositivi funge da modello di configurazione per le definizioni dei gruppi di dispositivi nel modulo delle pagine di contenuto. Le sue caratteristiche principali sono:
/libs/wcm/mobile/templates/devicegroup
/etc/mobile/groups/*
wcm/mobile/components/devicegroup
Quando create un sito mobile, dovete assegnare gruppi di dispositivi al sito. AEM fornisce tre gruppi di dispositivi a seconda delle capacità di rendering HTML e JavaScript del dispositivo:
Caratteristiche dei telefoni, per dispositivi quali Sony Ericsson W800 con supporto per HTML di base ma nessun supporto per immagini e JavaScript.
Smartphone, per dispositivi come Blackberry con supporto per HTML e immagini di base, ma senza supporto per JavaScript.
TouchPhone, per dispositivi come l’iPad con supporto completo per HTML, immagini, JavaScript e rotazione del dispositivo.
Poiché gli emulatori possono essere associati a un gruppo di dispositivi (vedere la sezione Creazione di un gruppo di dispositivi), l'assegnazione di un gruppo di dispositivi a un sito consente agli autori di selezionare tra gli emulatori associati al gruppo di dispositivi per modificare la pagina.
Per assegnare un gruppo di dispositivi al sito:
Nel browser, passate alla console Site Admin (Amministrazione sito).
Aprite la pagina principale del sito mobile sotto Siti Web.
Aprite le proprietà della pagina.
Selezionate la scheda Mobile:
Quando i gruppi di dispositivi sono stati definiti per un sito, vengono ereditati da tutte le pagine del sito.
I filtri per gruppi di dispositivi definiscono criteri basati sulle funzionalità per determinare se un dispositivo appartiene al gruppo. Quando create un gruppo di dispositivi, potete selezionare i filtri da utilizzare per valutare i dispositivi.
In fase di esecuzione quando AEM ricevuto una richiesta HTTP da un dispositivo, ogni filtro associato a un gruppo confronta le funzionalità del dispositivo con criteri specifici. Il dispositivo è considerato appartenente al gruppo quando dispone di tutte le funzionalità richieste dai filtri. Le funzionalità vengono recuperate dal database WURFL™.
I gruppi di dispositivi possono utilizzare zero o più filtri per il rilevamento delle funzionalità. È inoltre possibile utilizzare un filtro con più gruppi di dispositivi. AEM fornisce un filtro predefinito che determina se il dispositivo dispone delle funzionalità selezionate per un gruppo:
Se il gruppo di dispositivi non utilizza un filtro, le funzionalità selezionate configurate per il gruppo sono le uniche che un dispositivo richiede.
Per ulteriori informazioni, vedere Creazione di filtri per gruppi di dispositivi.
Crea un gruppo di dispositivi quando i gruppi che AEM installati non soddisfano i tuoi requisiti.
Nel browser, accedete alla console Strumenti.
Create una nuova pagina sotto Strumenti > Mobile > Gruppi di dispositivi. Nella finestra di dialogo Crea pagina:
Special Phones
.special
.In CRXDE, aggiungete un file static.css contenente gli stili per il gruppo di dispositivi sotto il nodo /etc/mobile/groups/special
.
Aprite la pagina Telefoni speciali.
Per configurare il gruppo di dispositivi, fare clic sul pulsante Modifica accanto a Impostazioni.
Nella scheda Generale:
BlackBerryZ10
Nella scheda Emulatori:
Nella scheda Filtri:
Fai clic su OK.
La finestra di dialogo di configurazione del gruppo di dispositivi mobili si presenta come segue:
Come descritto in precedenza, è possibile associare un CSS personalizzato a una pagina di gruppo di dispositivi, proprio come il CSS di una pagina di progettazione.Questo CSS viene utilizzato per influenzare il rendering specifico del gruppo di dispositivi del contenuto della pagina sull'autore e sulla pubblicazione.Questo CSS viene quindi incluso automaticamente:
Utilizzate i filtri e una libreria di specifiche dispositivo per determinare le capacità del dispositivo che esegue la richiesta HTTP.
Create un filtro gruppo di dispositivi per definire un set di requisiti di funzionalità dei dispositivi. Create tutti i filtri necessari per eseguire il targeting dei gruppi necessari di funzionalità dei dispositivi.
Progettate i filtri in modo da poter utilizzare combinazioni di essi per definire i gruppi di funzionalità. In genere, esiste una sovrapposizione delle capacità di diversi gruppi di dispositivi. Di conseguenza, potete utilizzare alcuni filtri con più definizioni di gruppi di dispositivi.
Dopo aver creato un filtro, potete usarlo nella configurazione del gruppo.
Per ulteriori informazioni, vedere Creazione di filtri per gruppi di dispositivi.
AEM utilizza una versione troncata del database WURFL™ per eseguire query sulle funzionalità dei dispositivi, come la risoluzione dello schermo o il supporto JavaScript, in base all'agente utente del dispositivo.
Il codice XML del database WURFL™ è rappresentato come nodi sotto /var/mobile/devicespecs
analizzando il file wurfl.xml
in /libs/wcm/mobile/devicespecs/wurfl.xml.
L'espansione ai nodi si verifica la prima volta che viene avviato il bundle cq-mobile-core
.
Le funzionalità dei dispositivi sono memorizzate come proprietà dei nodi e i nodi rappresentano modelli di dispositivi. Potete utilizzare le query per recuperare le funzionalità di un dispositivo o agente utente.
Poiché il database WURFL™ si sta evolvendo, potrebbe essere necessario personalizzarlo o sostituirlo. Per aggiornare il database dei dispositivi mobili sono disponibili le seguenti opzioni:
Quando un dispositivo accede al sito mobile, AEM rileva il dispositivo, lo mappa a un gruppo di dispositivi in base alle sue capacità e invia una visualizzazione della pagina che corrisponde al gruppo di dispositivi. Il gruppo di dispositivi corrispondente fornisce le informazioni di stile necessarie. Le mappature possono essere testate nella pagina di test dell'agente utente mobile:
http://localhost:4502/etc/mobile/useragent-test.html
Il database WURFL™ troncato installato con AEM è una versione precedente alle date
30 agosto 2011. Se la vostra versione del WURFL è stata rilasciata dopo il 30 agosto 2011, accertatevi che l'utilizzo sia conforme alla licenza.
Per installare un database WURFL™:
/apps/wcm/mobile/devicespecs
wurfl.xml
.AEM automaticamente analizza il file wurfl.xml
e aggiorna i nodi sottostanti /var/mobile/devicespecs
.
Quando il database WURFL™ completo è abilitato, l'analisi e l'attivazione potrebbero richiedere alcuni minuti. È possibile controllare i registri per informazioni sull’avanzamento.
Aggiungi un agente utente come espressione regolare di seguito /apps/wcm/mobile/devicspecs/wurfl/regexp per puntare a un tipo di dispositivo WURFL™ esistente.
In CRXDE Lite, create un nodo sotto /apps/wcm/mobile/devicspecs/regexp, ad esempio apple_ipad_ver1.
Aggiungi le seguenti proprietà al nodo:
La configurazione di cui sopra causa la mappatura dei dispositivi per i quali l'agente utente corrisponde all'espressione regolare fornita all'ID dispositivo apple_ipad_ver1 WURFL™, se esistente.
In questa sezione viene descritto come utilizzare il rilevamento lato client del dispositivo per AEM al fine di ottimizzare il rendering della pagina o per fornire al client versioni alternative del sito Web.
AEM supporta il rilevamento lato client del dispositivo in base a BrowserMap
. BrowserMap
viene spedito in AEM come libreria cliente in /etc/clientlibs/browsermap
.
BrowserMap
fornisce tre strategie che potete utilizzare per fornire un sito Web alternativo a un cliente, che vengono utilizzate nel seguente ordine:
Per ulteriori informazioni sull'integrazione con la libreria client, consultare la sezione Utilizzo delle librerie HTML lato client.
Il servizio PageVariantsProvider
OSGi è in grado di generare collegamenti alternativi per siti appartenenti alla stessa famiglia. Per configurare i siti da prendere in considerazione dal servizio, è necessario aggiungere un nodo cq:siteVariant
al nodo jcr:content
dalla radice del sito.
Il nodo cq:siteVariant
deve avere le seguenti proprietà:
cq:childNodesMapTo
- determina a quale attributo dell'elemento di collegamento saranno mappati i nodi secondari; si consiglia di organizzare il contenuto del sito Web in modo che gli elementi secondari del nodo principale rappresentino la radice di una variante della lingua del sito Web globale (ad esempio /content/mysite/en
, /content/mysite/de
), nel qual caso il valore del cq:childNodesMapTo
prodotto deve essere hreflang
;
cq:variantDomain
- indica quale Externalizer
dominio verrà utilizzato per generare gli URL assoluti delle varianti di pagina; se questo valore non è impostato, le varianti di pagina verranno generate utilizzando collegamenti relativi;
cq:variantFamily
- indica a quale famiglia di siti web appartiene questo sito; più rappresentazioni specifiche per dispositivo dello stesso sito web dovrebbero appartenere alla stessa famiglia;
media
- memorizza i valori dell'attributo media dell'elemento link; si consiglia di utilizzare il nome della BrowserMap
registrazione DeviceGroups
, in modo che la BrowserMap
libreria possa inoltrare automaticamente i client alla variante corretta del sito Web.
Quando il valore della proprietà cq:variantDomain
di un nodo cq:siteVariant
non è vuoto, il servizio PageVariantsProvider
genererà collegamenti assoluti utilizzando questo valore come dominio configurato per il servizio Externalizer
. Accertatevi di configurare il servizio Externalizer
in modo che rifletta la configurazione.
Quando lavorate con AEM esistono diversi metodi per gestire le impostazioni di configurazione di tali servizi; per ulteriori informazioni e procedure consigliate, vedere Configurazione di OSGi.
Se non si desidera utilizzare collegamenti alternativi, è possibile configurare un URL globale per ogni DeviceGroup
. È consigliabile creare una propria libreria client che incorpora la libreria client browsermap.standard
, ma ridefinisce i gruppi di dispositivi.
BrowserMap è progettato in modo tale che le definizioni dei gruppi di dispositivi possano essere ignorate creando e aggiungendo un nuovo gruppo di dispositivi con lo stesso nome all'oggetto BrowserMap
dalla libreria client personalizzata.
Per ulteriori dettagli, consultare la sezione BrowserMap personalizzata.
Se nessuno dei meccanismi precedenti è stato utilizzato per indicare un sito alternativo per BrowserMap
, i selettori che utilizzeranno i nomi di DeviceGroups
saranno aggiunti agli URL
s, nel qual caso è necessario fornire i propri servlet che gestiranno le richieste.
Ad esempio, la ricerca di un dispositivo www.example.com/index.html
identificata come smartphone
da BrowserMap viene inoltrata a www.example.com/index.smartphone.html.
Per utilizzare la libreria client BrowserMap standard in una pagina, è necessario includere il file /libs/wcm/core/browsermap/browsermap.jsp
utilizzando un tag cq:include
nella sezione head
della pagina.
<cq:include script="/libs/wcm/core/browsermap/browsermap.jsp" />
Oltre ad aggiungere la BrowserMap
libreria client nei file JSP
, è necessario aggiungere anche una proprietà cq:deviceIdentificationMode
String impostata su client-side
al nodo jcr:content
sotto la radice del sito Web.
Se si desidera personalizzare BrowserMap
, ignorando la DeviceGroups
o aggiungendo più sonde, è necessario creare una propria libreria lato client in cui incorporare la browsermap.standard
libreria lato client.
Inoltre, è necessario chiamare manualmente il metodo BrowserMap.forwardRequest()
nel codice JavaScript
.
Per ulteriori informazioni sull'integrazione con la libreria client, consultare la sezione Utilizzo delle librerie HTML lato client.
Dopo aver creato la libreria client personalizzata BrowserMap
, consigliamo il seguente approccio:
Creare un file browsermap.jsp
nell'applicazione
<%@include file="/libs/foundation/global.jsp" %>
<%@ taglib prefix="c" uri="https://java.sun.com/jsp/jstl/core" %>
<%@ page import="
com.day.cq.wcm.api.variants.PageVariant,
com.day.cq.wcm.api.variants.PageVariantsProvider,
com.day.cq.wcm.api.devicedetection.DeviceIdentificationMode,
com.day.cq.wcm.api.WCMMode"
%>
<%
final PageVariantsProvider p = sling.getService(PageVariantsProvider.class);
if(p == null) {
throw new IllegalStateException("Missing PageVariantsProvider service");
}
for(PageVariant v : p.getVariants(currentPage, slingRequest)) {
final String curVar = v.getAttributes().get("data-current-variant");
String media = v.getAttributes().get("media");
if (media != null) {
media = media.replaceAll(" ", "");
}
%>
<link
rel="alternate"
data-cq-role="site.variant"
title="<%= xssAPI.encodeForHTMLAttr(v.getTitle()) %>"
hreflang="<%= xssAPI.encodeForHTMLAttr(v.getAttributes().get("hreflang")) %>"
media="<%= xssAPI.encodeForHTMLAttr(media) %>"
href="<%= xssAPI.getValidHref(v.getURL()) %>"
<% if(curVar != null) { %> data-current-variant="<%= curVar %>"<% } %>
/>
<%
}
Boolean browserMapEnabled = true;
final DeviceIdentificationMode dim = sling.getService(DeviceIdentificationMode.class);
String[] selectors = slingRequest.getRequestPathInfo().getSelectors();
boolean isPortletRequest = false;
for (int i = 0; i < selectors.length; i++) {
if ("portlet".equals(selectors[i])) {
isPortletRequest = true;
break;
}
}
if (isPortletRequest) {
log.debug("Request was made by a portlet container - BrowserMap will not be embedded");
} else {
final WCMMode wcmMode = WCMMode.fromRequest(slingRequest);
boolean shouldIncludeClientLib = false;
if (WCMMode.EDIT != wcmMode && WCMMode.PREVIEW != wcmMode && WCMMode.DESIGN != wcmMode) {
if (dim != null) {
final String mode = dim.getDeviceIdentificationModeForPage(currentPage);
shouldIncludeClientLib = DeviceIdentificationMode.CLIENT_SIDE.equals(mode);
if (shouldIncludeClientLib) {
browserMapEnabled = (Boolean) request.getAttribute("browsermap.enabled");
if (browserMapEnabled == null) {
browserMapEnabled = true;
}
}
}
}
%>
<c:if test="<%= !browserMapEnabled %>">
<meta name="browsermap.enabled" content="false">
</c:if>
<c:if test="<%= shouldIncludeClientLib %>">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<cq:includeClientLib categories="browsermap.custom"/>
</c:if>
<%
}
%>
Includete il file broswermap.jsp
nella sezione head.
<cq:include script="browsermap.jsp" />
Se desiderate escludere la libreria BrowserMap da alcune pagine in cui non è necessario il rilevamento client, potete aggiungere un attributo di richiesta:
<%
request.setAttribute("browsermap.enabled", false);
%>
In questo modo lo script /libs/wcm/core/browsermap/browsermap.jsp
aggiungerà un tag meta alla pagina che renderà BrowserMap
non eseguibile il rilevamento:
<meta name="browsermap.enabled" content="false">
Normalmente, lo script BrowserMap reindirizzerà sempre i visitatori alla versione più adatta del sito Web, in genere reindirizzando i visitatori verso il desktop o il sito mobile quando necessario.
Potete forzare il dispositivo di qualsiasi richiesta per testare una versione specifica di un sito Web aggiungendo il parametro device
all'URL. Il seguente URL renderà la versione mobile del sito Web Geometrixx Outdoors.
http://localhost:4502/content/geometrixx-outdoors/en.html?wcmmode=disabled&device=smartphone
Il parametro wcmmode
è impostato su disabled
per simulare il comportamento di un'istanza di pubblicazione.
Il valore del dispositivo ignorato viene memorizzato in un cookie in modo da poter navigare nel sito Web senza aggiungere il parametro device
a ogni elemento URL
.
Di conseguenza, è necessario chiamare lo stesso URL
con il device
impostato su browser
per tornare alla versione desktop del sito Web.
BrowserMap memorizza il valore del dispositivo ignorato in un cookie denominato BMAP_device
. Se eliminate questo cookie, CQ distribuirà la versione appropriata del sito Web in base al dispositivo corrente (ad esempio, desktop o mobile).
AEM elabora una richiesta emessa da un dispositivo mobile appartenente al gruppo di dispositivi touch come segue:
Un iPad invia una richiesta all’istanza di pubblicazione AEM, ad esempio http://localhost:4503/content/geometrixx_mobile/en/products.html
AEM determina se il sito della pagina richiesta è un sito mobile (verificando se la pagina di primo livello /content/geometrixx_mobile
estende il componente della pagina mobile). In caso affermativo:
AEM le funzionalità del dispositivo in base all'agente utente nell'intestazione della richiesta.
AEM mappa le funzionalità del dispositivo al gruppo di dispositivi e imposta touch
come selettore del gruppo di dispositivi.
AEM reindirizzare la richiesta a http://localhost:4503/content/geometrixx_mobile/en/products.touch.html.
AEM invia la risposta all’iPad:
products.touch.html
è rappresentato nel modo usuale ed è memorizzabile nella cache.Potete ottenere alcune statistiche sul numero di richieste effettuate al server AEM dai dispositivi mobili. È possibile suddividere il numero di richieste:
Per visualizzare le statistiche:
Passate alla console Strumenti.
Aprite la pagina Device Statistics sotto Tools > Mobile.
Fate clic sul collegamento per visualizzare le statistiche relative a un anno, un mese o un giorno specifico.
La pagina Statistics si presenta come segue:
La pagina Statistics viene creata la prima volta che un dispositivo mobile accede AEM e viene rilevata. Prima di questo, non è disponibile.
Per generare una voce nelle statistiche, è possibile procedere come segue:
Usate un dispositivo mobile o un emulatore (ad esempio https://chrispederick.com/work/user-agent-switcher/ su Firefox).
Richiedete una pagina mobile nell’istanza di creazione disattivando la modalità di authoring, ad esempio:
http://localhost:4502/content/geometrixx_mobile/en/products.html?wcmmode=disabled
È ora disponibile la pagina Statistiche.
Le pagine mobili sono generalmente memorizzabili nella cache del dispatcher, perché le pagine di cui viene eseguito il rendering per un gruppo di dispositivi vengono distinte nell'URL della pagina dal selettore del gruppo di dispositivi, ad esempio /content/mobilepage.touch.html
. Una richiesta a una pagina mobile senza un selettore non viene mai memorizzata nella cache, come in questo caso, il rilevamento del dispositivo funziona e alla fine viene reindirizzato al gruppo di dispositivi corrispondente (o alla "copia" in quel caso). Il rendering di una pagina mobile con un selettore di gruppi di dispositivi viene elaborato dalla riscrittura dei collegamenti, che riscrive tutti i collegamenti all'interno della pagina per contenere anche il selettore di gruppi di dispositivi, impedendo la ripetizione del rilevamento dispositivi per ogni clic su una pagina già qualificata.
Di conseguenza, si potrebbe verificare il seguente scenario:
L'utente Alice viene reindirizzato a coolpage.feature.html
e invia l'URL a un amico Bob che accede con un altro client appartenente al gruppo touch
del dispositivo.
Se coolpage.feature.html
viene distribuito da una cache front-end, AEM non ha la possibilità di analizzare la richiesta per scoprire che il selettore mobile non corrisponde al nuovo agente utente, e Bob riceve la rappresentazione sbagliata.
Per risolverlo, puoi includere una semplice interfaccia utente di selezione nelle pagine, in cui gli utenti finali possono ignorare il gruppo di dispositivi selezionato da AEM. Nell'esempio precedente, un collegamento (o un'icona) sulla pagina consente all'utente finale di passare a coolpage.touch.html
se ritiene che il dispositivo sia sufficientemente adatto.