L’Adobe consiglia di utilizzare l’Editor SPA per i progetti che richiedono il rendering lato client basato su framework di applicazione a pagina singola (ad esempio, React). Ulteriori informazioni.
La creazione di un sito mobile è simile alla creazione di un sito standard, in quanto comporta 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 per AEM Sites. La differenza principale consiste nell’abilitare le funzionalità mobili integrate dell’AEM all’interno del sito. Ciò si ottiene creando un modello che si basa sul componente Pagina mobile.
È inoltre consigliabile utilizzare design responsive, creando un singolo sito per schermi di dimensioni multiple.
Per iniziare, puoi dare un’occhiata al Sito di dimostrazione mobile We.Retail disponibile nell’AEM.
Per creare un sito mobile, procedi come segue:
Creare il componente Pagina:
Imposta il sling:resourceSuperType
proprietà a wcm/mobile/components/page
In questo modo il componente si basa sul componente Pagina mobile.
Creare body.jsp
con la logica specifica del progetto.
Creare il modello di pagina:
sling:resourceType
al componente pagina appena creato.allowedPaths
proprietà.Crea la pagina di progettazione per il sito.
Crea la pagina principale del sito sotto /content
nodo:
cq:allowedTemplates
proprietà.cq:designPath
proprietà.Nelle proprietà della pagina della directory principale del sito, imposta i gruppi di dispositivi in Dispositivi mobili scheda.
Creare le pagine del sito utilizzando il nuovo modello.
Il 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 drawHead()
metodo per includere il componente iniziale dell’emulatore associato al gruppo dispositivo (solo in modalità di authoring) e il CSS di rendering del gruppo dispositivo.La pagina principale del sito mobile deve trovarsi al livello 1 della gerarchia dei nodi ed è consigliabile trovarsi al di sotto del nodo /content.
Utilizza Multi Site Manager (MSM) per creare una Live Copy mobile da un sito standard. Il sito standard viene trasformato automaticamente in un sito mobile: il sito mobile presenta tutte le funzioni dei siti mobili (ad esempio l’edizione all’interno di un emulatore) e può essere gestito in sincronia con il sito standard. Consulta la sezione Creazione di una Live Copy per canali diversi nella pagina Gestione multisito.
I pacchetti Java contenenti le classi mobili sono:
Il Sito di dimostrazione mobile We.Retail utilizza i seguenti componenti mobili che si trovano sotto /libs/foundation/components
:
Nome | Gruppo | Caratteristiche |
mobilefooter | nascosto | - piè di pagina |
mobileimage | Mobile | - in base al componente image foundation - esegue il rendering di un'immagine se il dispositivo è in grado di |
mobilelist | Mobile | - in base al componente di base elenco - listitem_teaser.jsp esegue il rendering di un’immagine se il dispositivo è in grado di |
mobilelogo | nascosto | - in base al componente base del logo - esegue il rendering di un'immagine se il dispositivo è in grado di |
riferimento mobile | Mobile | - simile al componente base di riferimento : mappa un componente textimage su un elemento mobiletextimage 1 e un componente immagine su un elemento mobiletextimage 1 |
mobiletextimage | Mobile | basato sul componente textimage foundation - esegue il rendering di un'immagine se il dispositivo è in grado di |
mobiletopnav | nascosto | - basato sul componente topnav foundation - esegue solo il rendering del testo |
Il framework mobile dell’AEM consente di sviluppare componenti sensibili al dispositivo che emette la richiesta. Gli esempi di codice seguenti mostrano come utilizzare l’API mobile dell’AEM in un componente jsp e in particolare come:
Ottieni il dispositivo dalla richiesta:
Device device = slingRequest.adaptTo(Device.class);
Ottieni il gruppo di dispositivi:
DeviceGroup deviceGroup = device.getDeviceGroup();
Ottieni le funzionalità del gruppo di dispositivi:
Collection<DeviceCapability> capabilities = deviceGroup.getCapabilities();
Ottieni gli attributi del dispositivo (chiave/valori di capacità non elaborati dal database WURFL):
Map<String,String> deviceAttributes = device.getAttributes();
Ottieni l’agente utente del dispositivo:
String userAgent = device.getUserAgent();
Ottieni l’elenco dei gruppi di dispositivi (gruppi di dispositivi assegnati al sito dall’autore) dalla pagina corrente:
DeviceGroupList deviceGroupList = currentPage.adaptTo(DeviceGroupList.class);
Verifica 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 <sling:defineObjects>
tag e currentPage
tramite <cq:defineObjects>
tag.
L’authoring basato su emulatore consente agli autori di creare pagine di contenuti destinate ai clienti di dispositivi mobili. L’authoring dei contenuti per dispositivi mobili segue lo stesso principio dell’editing WYSIWYG sul posto. 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 per dispositivi mobili si basano sul framework dell’emulatore generico. Per ulteriori informazioni, consultare il Emulatori pagina.
L’emulatore del dispositivo visualizza il dispositivo mobile sulla pagina, mentre le normali modifiche (parsys, componenti) si verificano all’interno dello schermo del dispositivo. L’emulatore di dispositivi dipende dai gruppi di dispositivi configurati per il sito. È possibile assegnare diversi emulatori 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 commutati tramite il carosello dell’emulatore nella parte superiore della pagina o tramite il pulsante di modifica della barra laterale.
Creazione di un emulatore
Per creare un emulatore, consulta 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 le emulators
proprietà sotto jcr:content
nodo.
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, emulators
viene impostata con il percorso dell'emulatore o degli emulatori desiderati. Esempio: /libs/wcm/mobile/components/emulators/iPhone4
.
I componenti dell’emulatore (ad es. /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 durante la configurazione di un gruppo di dispositivi. Gli emulatori personalizzati possono quindi essere facilmente creati o estesi.
Al momento della richiesta in modalità di modifica, per eseguire il rendering della pagina viene utilizzata l’implementazione dell’emulatore.
Quando il modello della pagina si basa sul componente della pagina mobile, le funzionalità dell’emulatore vengono integrate automaticamente nella pagina (tramite il head.jsp
del componente 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 su emulatori nell’istanza di authoring e per il rendering corretto dei contenuti nell’istanza di pubblicazione: una volta che gli autori hanno aggiunto contenuti alla pagina mobile e l’hanno pubblicata, la pagina può essere richiesta nell’istanza di pubblicazione. Al suo posto, la vista di modifica dell’emulatore riproduce la pagina di contenuto utilizzando uno dei gruppi di dispositivi configurati. La selezione del gruppo di dispositivi si verifica in base a rilevamento di dispositivi mobili. Il gruppo di dispositivi corrispondente fornisce quindi le informazioni necessarie sullo stile.
I gruppi di dispositivi sono definiti come pagine di contenuto sotto /etc/mobile/devices
e utilizza Gruppo dispositivi mobili modello. Il modello gruppo di dispositivi funge da modello di configurazione per le definizioni dei gruppi di dispositivi sotto forma di pagine di contenuto. Le sue caratteristiche principali sono:
/libs/wcm/mobile/templates/devicegroup
/etc/mobile/groups/*
wcm/mobile/components/devicegroup
Quando crei un sito mobile, devi assegnare gruppi di dispositivi al sito. L’AEM fornisce tre gruppi di dispositivi a seconda delle funzionalità di rendering HTML e JavaScript del dispositivo:
Funzionalità telefoni cellulari, per dispositivi come il Sony Ericsson W800 con supporto per HTML di base, ma senza supporto per immagini e JavaScript.
Smart telefoni, per dispositivi come Blackberry con supporto per HTML di base e immagini, ma senza supporto per JavaScript.
Touch telefoni, per dispositivi come iPad con supporto completo per HTML, immagini, JavaScript e rotazione dei dispositivi.
Come emulatori possono essere associati a un gruppo di dispositivi (vedi 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, vai al Siteadmin console.
Apri la pagina root del tuo sito mobile di seguito Siti Web.
Apri le proprietà della pagina.
Seleziona la Dispositivi mobili scheda:
Una volta definiti i gruppi di dispositivi per un sito, questi 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 crei un gruppo di dispositivi, puoi selezionare i filtri da utilizzare per la valutazione dei dispositivi.
In fase di esecuzione, quando l’AEM riceve una richiesta HTTP da un dispositivo, ogni filtro associato a un gruppo confronta le funzionalità del dispositivo con criteri specifici. Il dispositivo viene considerato appartenente al gruppo quando dispone di tutte le funzionalità necessarie per i filtri. Le funzionalità vengono recuperate dal database WURFL™.
I gruppi di dispositivi possono utilizzare zero o più filtri per il rilevamento delle funzionalità. Inoltre, un filtro può essere utilizzato con più gruppi di dispositivi. L’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 necessarie per un dispositivo.
Per ulteriori informazioni, consulta Creazione di filtri per gruppi di dispositivi.
Creare un gruppo di dispositivi quando i gruppi installati da AEM non soddisfano le proprie esigenze.
Nel browser, vai al Strumenti console.
Crea una nuova pagina qui sotto Strumenti > Dispositivi mobili > Gruppi di dispositivi. In Crea pagina finestra di dialogo:
As Titolo Invio Special Phones
.
As Nome Invio special
.
Seleziona la Modello per gruppo dispositivi mobili.
Fai clic su Crea.
In CRXDE, aggiungi un static.css file contenente gli stili per il gruppo di dispositivi sotto /etc/mobile/groups/special
nodo.
Apri Telefoni speciali pagina.
Per configurare il gruppo di dispositivi, fare clic su Modifica pulsante accanto a Impostazioni.
Il giorno Generale scheda:
BlackBerryZ10
Il giorno Emulatori scheda:
Il giorno Filtri scheda:
Fai clic su OK.
La finestra di dialogo per la configurazione del gruppo di dispositivi mobili si presenta così:
Come descritto in precedenza, è possibile associare un CSS personalizzato a una pagina di gruppo di dispositivi, in modo analogo al CSS di una pagina di progettazione. Questo CSS viene utilizzato per influenzare il rendering specifico del gruppo di dispositivi del contenuto della pagina all'autore e alla pubblicazione. Questo CSS viene quindi incluso automaticamente:
Utilizza i filtri e una libreria di specifiche del dispositivo per determinare le funzionalità del dispositivo che esegue la richiesta HTTP.
Crea un filtro per gruppi di dispositivi per definire un set di requisiti di funzionalità per dispositivi. Crea tutti i filtri necessari per eseguire il targeting dei gruppi necessari di funzionalità del dispositivo.
Progetta i filtri in modo da poterne utilizzare le combinazioni per definire i gruppi di funzionalità. In genere, le funzionalità dei diversi gruppi di dispositivi si sovrappongono. Pertanto, è possibile utilizzare alcuni filtri con più definizioni di gruppi di dispositivi.
Dopo aver creato un filtro, puoi utilizzarlo nella configurazione del gruppo.
Per ulteriori informazioni, visitare il sito Creazione di filtri per gruppi di dispositivi.
L’AEM utilizza una versione troncata del WURFL™ database per eseguire query sulle funzionalità del dispositivo, ad esempio la risoluzione dello schermo o il supporto di JavaScript, in base all’agente utente del dispositivo.
Il codice XML del database WURFL™ è rappresentato come nodi di seguito /var/mobile/devicespecs
analizzando wurfl.xml
file in /libs/wcm/mobile/devicespecs/wurfl.xml.
L’espansione ai nodi si verifica la prima volta che il cq-mobile-core
bundle avviato.
Le funzionalità dei dispositivi sono memorizzate come proprietà dei nodi e i nodi rappresentano modelli di dispositivi. È possibile utilizzare le query per recuperare le funzionalità di un dispositivo o di un agente utente.
Con l'evoluzione del database WURFL™, 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, l’AEM rileva il dispositivo, lo mappa su un gruppo di dispositivi in base alle sue funzionalità e invia una visualizzazione della pagina che corrisponde al gruppo di dispositivi. Il gruppo di dispositivi corrispondente fornisce le informazioni necessarie sullo stile. Le mappature possono essere testate nella pagina di test agente utente mobile:
https://localhost:4502/etc/mobile/useragent-test.html
Il database WURFL™ troncato installato con AEM è una versione precedente al 30 agosto 2011. Se la tua versione del WURFL è stata rilasciata dopo il 30 agosto 2011, assicurati che il tuo utilizzo sia conforme alla licenza.
Per installare un database WURFL™:
/apps/wcm/mobile/devicespecs
wurfl.xml
.AEM analizza automaticamente wurfl.xml
e aggiorna i nodi sottostanti /var/mobile/devicespecs
.
Quando il database WURFL™ completo è attivato, l'analisi e l'attivazione potrebbero richiedere alcuni minuti. Puoi controllare i registri per informazioni sull’avanzamento.
Aggiungi user-agent come espressione regolare sotto /apps/wcm/mobile/devicespecs/wurfl/regexp per puntare a un tipo di dispositivo WURFL™ esistente.
In entrata CRXDE Lite, crea un nodo sotto /apps/wcm/mobile/devicespecs/regexp, ad esempio apple_ipad_ver1.
Aggiungi le seguenti proprietà al nodo:
La configurazione precedente fa sì che i dispositivi per i quali l’agente utente corrisponde all’espressione regolare fornita vengano mappati sull’ID dispositivo apple_ipad_ver1 WURFL™, se presente.
Questa sezione descrive come utilizzare il rilevamento dell’AEM lato client del dispositivo per ottimizzare il rendering della pagina o fornire al client versioni alternative del sito web.
AEM supporta il rilevamento lato client del dispositivo basato su BrowserMap
. BrowserMap
viene fornito in AEM come libreria client in /etc/clientlibs/browsermap
.
BrowserMap
fornisce tre strategie che è possibile utilizzare per fornire un sito Web alternativo a un cliente, utilizzate nell'ordine seguente:
Per ulteriori informazioni sull’integrazione della libreria client, consulta Utilizzo delle librerie HTML lato client sezione.
Il PageVariantsProvider
Il servizio OSGi è in grado di generare collegamenti alternativi per i siti appartenenti alla stessa famiglia. Per configurare i siti da prendere in considerazione dal servizio, è necessario cq:siteVariant
deve essere aggiunto al jcr:content
dalla directory principale del sito.
Il cq:siteVariant
il nodo deve avere le seguenti proprietà:
cq:childNodesMapTo
- determina a quale attributo dell’elemento di collegamento verranno 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 per una variante di lingua del sito web globale (ad esempio /content/mysite/en
, /content/mysite/de
), nel qual caso il valore della proprietà cq:childNodesMapTo
dovrebbe essere hreflang
;cq:variantDomain
- indica cosa Externalizer
Il 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 dell’elemento link BrowserMap
registrato DeviceGroups
, affinché il BrowserMap
libreria può inoltrare automaticamente i client alla variante corretta del sito web.Quando il valore di cq:variantDomain
proprietà di un cq:siteVariant
nodo non è vuoto, il PageVariantsProvider
genererà collegamenti assoluti utilizzando questo valore come dominio configurato Externalizer
servizio. Assicurati di configurare Externalizer
per riflettere la configurazione.
Quando si lavora con l’AEM, esistono diversi metodi per gestire le impostazioni di configurazione per tali servizi; vedi Configurazione di OSGi per ulteriori dettagli e le pratiche consigliate.
Se non desideri utilizzare collegamenti alternativi, puoi configurare un URL globale per ciascuno di essi DeviceGroup
. È consigliabile creare una libreria client personalizzata che incorpori 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 al BrowserMap
oggetto dalla libreria client personalizzata.
Per maggiori dettagli, consultare la Mappa browser personalizzata sezione.
Se non è stato utilizzato nessuno dei meccanismi precedenti per indicare un sito alternativo per BrowserMap
, quindi i selettori che utilizzeranno i nomi dei DeviceGroups
verrà aggiunto al URL
s, nel qual caso è necessario fornire i propri servlet che gestiranno le richieste.
Ad esempio, la navigazione dei dispositivi www.example.com/index.html
identificato come smartphone
by BrowserMap viene inoltrato a www.example.com/index.smartphone.html.
Per utilizzare la libreria client BrowserMap standard in una pagina, è necessario includere /libs/wcm/core/browsermap/browsermap.jsp
file che utilizza un cq:include
tag in della pagina head
sezione.
<cq:include script="/libs/wcm/core/browsermap/browsermap.jsp" />
Oltre ad aggiungere BrowserMap
libreria client nel tuo JSP
, è inoltre necessario aggiungere un cq:deviceIdentificationMode
Proprietà stringa impostata su client-side
al jcr:content
sotto la directory principale del sito web.
Se desideri personalizzare BrowserMap
- escludendo DeviceGroups
o aggiungendo più sonde: è necessario creare una libreria lato client in cui incorporare il browsermap.standard
libreria lato client.
Inoltre, devi chiamare manualmente il BrowserMap.forwardRequest()
metodo nel tuo JavaScript
codice.
Per ulteriori informazioni sull’integrazione della libreria client, consulta Utilizzo delle librerie HTML lato client sezione.
Dopo aver creato il personalizzato BrowserMap
libreria client, si consiglia il seguente approccio:
Creare un browsermap.jsp
file 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>
<%
}
%>
Includi broswermap.jsp
nella sezione head.
<cq:include script="browsermap.jsp" />
Se desideri escludere la libreria BrowserMap da alcune pagine in cui non è necessario il rilevamento client, puoi aggiungere un attributo di richiesta:
<%
request.setAttribute("browsermap.enabled", false);
%>
Questo renderà /libs/wcm/core/browsermap/browsermap.jsp
script per aggiungere un tag meta alla pagina che BrowserMap
per non eseguire alcun rilevamento:
<meta name="browsermap.enabled" content="false">
Normalmente, lo script BrowserMap reindirizza sempre i visitatori alla versione più adatta del sito web, in genere reindirizzando i visitatori al desktop o al sito mobile quando necessario.
Puoi forzare il dispositivo di qualsiasi richiesta per testare una versione specifica di un sito web aggiungendo il device
all'URL. L’URL seguente eseguirà il rendering della versione mobile del sito web Geometrixx Outdoors.
https://localhost:4502/content/geometrixx-outdoors/en.html?wcmmode=disabled&device=smartphone
Il wcmmode
parametro impostato su disabled
per simulare il comportamento di un’istanza Publish.
Il valore del dispositivo sovrascritto viene memorizzato in un cookie in modo da poter navigare nel sito web senza aggiungere il device
parametro per ogni URL
.
Di conseguenza, è necessario chiamare lo stesso URL
con device
imposta su browser
per tornare alla versione desktop del sito web.
BrowserMap memorizza il valore del dispositivo sostituito in un cookie denominato BMAP_device
. Se elimini questo cookie, CQ distribuirà la versione appropriata del sito Web in base al dispositivo corrente (ad esempio desktop o dispositivi mobili).
L’AEM elabora come segue una richiesta emessa da un dispositivo mobile che appartiene al gruppo di dispositivi touch:
Un’iPad invia una richiesta all’istanza di pubblicazione dell’AEM, ad esempio https://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 pagina mobile). In caso affermativo:
AEM cerca 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 reindirizza la richiesta a https://localhost:4503/content/geometrixx_mobile/en/products.touch.html.
L’AEM invia la risposta all’iPad:
products.touch.html
viene renderizzato nel modo abituale ed è memorizzabile in cache.Puoi ottenere alcune statistiche sul numero di richieste effettuate al server AEM dai dispositivi mobili. Il numero di richieste può essere suddiviso:
Per visualizzare le statistiche:
Il Statistiche La pagina si presenta come segue:
Il Statistiche viene creata la prima volta che viene rilevato un dispositivo mobile che accede all’AEM. Prima di allora, non era disponibile.
Per generare una voce nelle statistiche, procedere come segue:
https://localhost:4502/content/geometrixx_mobile/en/products.html?wcmmode=disabled
Il Statistiche è ora disponibile.
Le pagine mobili in genere sono memorizzabili nella cache in Dispatcher, perché le pagine sottoposte a rendering per un gruppo di dispositivi si distinguono nell’URL della pagina in base al 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 infine viene reindirizzato al gruppo di dispositivi corrispondente (o "nomatch" per tale questione). Una pagina mobile di cui è stato eseguito il rendering con un selettore di gruppo dispositivo viene elaborata dal rewriter del collegamento, che riscrive tutti i collegamenti all’interno della pagina in modo da contenere anche il selettore di gruppo dispositivo, impedendo di ripetere il rilevamento del dispositivo per ogni clic su una pagina già qualificata.
Pertanto, potresti incontrare lo scenario seguente:
L'utente Alice viene reindirizzato a coolpage.feature.html
, e invia tale URL a un amico Bob che vi accede con un client diverso che rientra nel touch
gruppo di dispositivi.
Se coolpage.feature.html
viene fornito da una cache front-end, l’AEM non ha la possibilità di analizzare la richiesta per scoprire che il selettore mobile non corrisponde al nuovo agente utente e Bob ottiene la rappresentazione errata.
Per risolverlo, puoi includere nelle pagine una semplice interfaccia utente di selezione, in cui gli utenti finali possono ignorare il gruppo di dispositivi selezionato dall’AEM. Nell’esempio precedente, un collegamento (o un’icona) sulla pagina consente all’utente finale di passare a coolpage.touch.html
se pensa che il suo dispositivo sia abbastanza buono per questo.