Mobil med innehållssynkronisering mobile-with-content-sync

Använd Innehållssynkronisering för att paketera innehåll så att det kan användas i inbyggda mobilprogram. Sidor som har skapats i AEM kan användas som appinnehåll, även när enheten är offline. Eftersom AEM bygger på webbstandarder fungerar de på olika plattformar så att du kan bädda in dem i alla inbyggda wrapper. Den här strategin minskar utvecklingsinsatserna och gör att du enkelt kan uppdatera appinnehåll.

I ramverket för innehållssynkronisering skapas en arkivfil som innehåller webbinnehållet. Innehållet kan vara allt från enkla sidor, bilder och PDF eller hela webbprogram. API:t för innehållssynkronisering ger åtkomst till arkivfilen från mobilappar eller byggprocesser så att innehållet kan hämtas och inkluderas i appen.

Följande stegsekvens visar ett typiskt användningsfall för Innehållssynkronisering:

Konfigurera innehåll för innehållssynkronisering configuring-the-content-sync-content

Skapa en konfiguration för innehållssynkronisering för att ange innehållet i ZIP-filen som skickas till klienten. Du kan skapa valfritt antal konfigurationer för innehållssynkronisering. Varje konfiguration har ett namn för identifieringsändamål.

Om du vill skapa en konfiguration för innehållssynkronisering lägger du till en cq:ContentSyncConfig till databasen med sling:resourceType egenskap inställd på contentsync/config. The cq:ContentSyncConfig noden kan finnas var som helst i databasen, men noden måste vara tillgänglig för användare på AEM publiceringsinstans. Därför bör du lägga till noden nedan /content.

Om du vill ange innehållet i ZIP-filen för innehållssynkronisering lägger du till underordnade noder i cq:ContentSyncConfig-noden. Följande egenskaper för varje underordnad nod identifierar ett innehållsobjekt som ska inkluderas och hur det bearbetas när det läggs till:

Se Exempel på konfiguration av innehållssynkronisering.

När du har skapat konfigurationen för innehållssynkronisering visas den i konsolen för innehållssynkronisering.

Konfigurera åtkomst till hämtningar för innehållssynkronisering configuring-access-to-content-sync-downloads

Ange en användare eller grupp som kan hämtas från Innehållssynkronisering. Du kan konfigurera standardanvändaren eller standardgruppen som kan hämtas från alla cacheminnen för innehållssynkronisering, och du kan åsidosätta standardinställningen och konfigurera åtkomst för en viss konfiguration för innehållssynkronisering.

När AEM är installerat kan medlemmar i administratörsgruppen hämta från innehållssynkronisering som standard.

Ange standardåtkomst för hämtning av innehållssynkronisering setting-the-default-access-for-content-sync-downloads

Tjänsten Day CQ Content Sync Manager styr åtkomsten till Content Sync. Konfigurera den här tjänsten för att ange den användare eller grupp som kan hämtas från innehållssynkronisering som standard.

Om du konfigurera tjänsten med webbkonsolenskriver du namnet på användaren eller gruppen som värdet på egenskapen Authorizable för återställningscache.

Om du konfigurera i databasenanvänder du följande information om tjänsten:

Åsidosätta hämtningsåtkomst för en cache för innehållssynkronisering overriding-download-access-for-a-content-sync-cache

Om du vill konfigurera hämtningsåtkomst för en viss konfiguration för innehållssynkronisering lägger du till följande egenskap i cq:ContentSyncConfig nod:

Med din app kan användare till exempel installera uppdateringar direkt från innehållssynkronisering. Om du vill att alla användare ska kunna hämta uppdateringen anger du värdet för egenskapen authable till everyone.

Om cq:ContentSyncConfig noden har ingen auktoriseringsbar egenskap, standardanvändaren eller standardgruppen som är konfigurerad för egenskapen Autentiserbar för reservcache i tjänsten för dagen CQ Content Sync Manager avgör vem som kan hämta.

Konfigurera användaren för uppdatering av en cache för innehållssynkronisering configuring-the-user-for-updating-a-content-sync-cache

När en användare uppdaterar cachen för innehållssynkronisering utför ett specifikt användarkonto åtgärden åt användaren. Den anonyma användaren uppdaterar alla cacheminnen för innehållssynkronisering som standard.

Du kan åsidosätta standardanvändaren och ange en användare eller grupp som uppdaterar en viss cache för innehållssynkronisering.

Om du vill åsidosätta standardanvändaren anger du en användare eller grupp som utför uppdateringar för en specifik konfiguration för innehållssynkronisering genom att lägga till följande egenskap i cq

Om cq:ContentSyncConfig-noden inte har någon updateuser-egenskap, uppdaterar standard anonym användare cachen.

Konfigurationstyper configuration-types

Bearbetningen kan omfatta allt från rendering av enkel JSON till fullständig rendering av sidor, inklusive deras refererade resurser. I det här avsnittet visas tillgängliga konfigurationstyper och deras specifika parametrar:

copy Kopiera bara filer och mappar.

innehåll Återge innehåll med standardbehandling av Sling-begäran.

clientlib Paketera ett JavaScript- eller CSS-klientbibliotek.

resurser

Samla in ursprungliga återgivningar av resurser.

image Samla in en bild.

Bildtypen används för att inkludera logotypen We.Retail i zip-filen.

sidor Återge AEM sidor och samla in refererade resurser.

rewrite Noden rewrite definierar hur länkarna skrivs om på den exporterade sidan. De omskrivna länkarna kan antingen peka på filerna som finns i ZIP-filen eller på resurserna på servern.

The rewrite noden måste finnas under page nod.

The rewrite noden kan ha en eller flera av följande egenskaper:

Varje egenskap kan ha något av följande värden:

AEM anropade PathRewriterTransformerFactory I kan du konfigurera de specifika HTML-attribut som ska skrivas om. Tjänsten kan konfigureras i webbkonsolen och har en konfiguration för varje egenskap i rewrite nod: clientlibs, images och links.

Den här funktionen lades till i AEM 5.5.

Exempel på konfiguration för innehållssynkronisering example-content-sync-configuration

I listan nedan visas ett exempel på en konfiguration för innehållssynkronisering.

+ weretail_go [cq:ContentSyncConfig]
  - sling:resourceType = "contentsync/config"

  + etc.designs.default [nt:unstructured]
    - path = "/etc/designs/default"
    - type = "copy"

  + etc.designs.mobile [nt:unstructured]
    - path = "/etc/designs/mobile"
    - type = "copy"

  + events.plist [nt:unstructured]
    - path = "/content/weretail_mobile/en/events/jcr:content/par/events"
    - type = "content"
    - extension = "plist"

  + events.touch.html [nt:unstructured]
    - path = "/content/weretail_mobile/en/events"
    - type = "pages"
    - extension = "html"
    - selector = "touch"

  + logo [nt:unstructured]
    - path = "/etc/designs/mobile/jcr:content/mobilecontentpage/logo"
    - type = "logo"

  + manifest [nt:unstructured]
    - indexPage = "/content/weretail_mobile/en/events.touch.html"
    - metadataPlist = "/content/weretail_mobile/en/events/_jcr_content/par/events.plist"

  + ...

etc.designs.default och etc.designs.mobile De första två posterna i konfigurationen bör vara helt uppenbara. Eftersom vi ska ta med ett antal mobilsidor behöver vi de relaterade designfilerna nedan /etc/designs. Och eftersom ingen extra bearbetning behövs räcker det med en kopia.

events.plist Den här posten är lite speciell. Som nämndes i inledningen bör programmet tillhandahålla en kartvy med markörer för händelsernas platser. Vi kommer att tillhandahålla nödvändig platsinformation som en separat fil i PLIST-format. För att detta ska fungera har händelselistkomponenten som används på indexsidan ett skript som heter plist.jsp. Skriptet körs när komponentens resurs begärs med tillägget .plist. Som vanligt anges komponentsökvägen i egenskapen path och typen ställs in på content eftersom vi vill utnyttja bearbetningen av Sling-begäran.

events.touch.html Därefter kommer de faktiska sidorna som visas i appen. Egenskapen path ställs in på händelsens rotsida. Alla händelsesidor under den sidan inkluderas också eftersom egenskapen deep har standardvärdet true. Vi använder sidor som konfigurationstyp, så att alla bilder eller andra filer som kan refereras från en bild eller en nedladdningskomponent på en sida inkluderas. Om du dessutom ställer in pekväljaren får vi en mobilversion av sidorna. Konfigurationen i funktionspaketet innehåller fler poster av den här typen, men utelämnas för enkelhetens skull här.

logo Konfigurationstypen för logotypen har inte nämnts hittills och är ingen av de inbyggda typerna. Ramverket för innehållssynkronisering är dock delvis utökningsbart och det är ett exempel på det, som kommer att behandlas i nästa avsnitt.

manifest Det är ofta önskvärt att ZIP-filen innehåller någon typ av metadata, till exempel startsidan för innehållet. Om du däremot hårdkodar sådan information kan du inte ändra den senare. Innehållssynkroniseringsramverket stöder det här användningsexemplet genom att söka efter en manifestnod i konfigurationen, som bara identifieras med namn och som inte kräver någon konfigurationstyp. Alla egenskaper som definieras på den aktuella noden läggs till i en fil, som också kallas manifest och finns i zip-filens rot.

I exemplet ska händelselistsidan vara den inledande sidan. Denna information finns i indexPage och kan därför ändras när som helst. En andra egenskap definierar sökvägen till events.plist -fil. Som vi kommer att se senare kan klientprogrammet nu läsa manifestet och agera utifrån det.

När konfigurationen är klar kan innehållet laddas ned med en webbläsare eller en annan HTTP-klient, eller om du utvecklar för iOS kan du använda det dedikerade WAppKitSync-klientbiblioteket. Hämtningsplatsen består av konfigurationens sökväg och .zip tillägg, t.ex. när du arbetar med en lokal AEM: http://localhost:4502/content/weretail_go.zip

Konsolen Innehållssynkronisering the-content-sync-console

I konsolen Innehållssynkronisering visas alla konfigurationer för innehållssynkronisering i databasen (alla noder av typen cq:ContentSyncConfig) och för varje konfiguration kan du göra följande:

Det kan vara användbart för utveckling och felsökning.

Konsolen finns på:

http://localhost:4502/libs/cq/contentsync/content/console.html

Den ser ut så här:

Utöka ramverket för innehållssynkronisering extending-the-content-sync-framework

Även om antalet konfigurationsalternativ redan är ganska många kanske det inte täcker alla krav som gäller ditt specifika användningsfall. I det här avsnittet beskrivs tilläggen för ramverket för innehållssynkronisering och hur du skapar anpassade konfigurationstyper.

För varje konfigurationstyp finns det en Hanterare för innehållsuppdatering, som är en OSGi-komponentfabrik som är registrerad för den typen. Hanterarna samlar in, bearbetar och lägger till innehåll i ett cacheminne som underhålls av ramverket för innehållssynkronisering. Implementera följande gränssnitt eller abstrakt basklass:

Registrera klassen som OSGi-komponentfabrik och distribuera den i OSGi-behållaren i ett paket. Detta kan du göra med Maven SCR plugin antingen med JavaDoc-taggar eller anteckningar. I följande exempel visas JavaDoc-versionen:

/*
 * @scr.component metatype="no"
 * factory="com.day.cq.contentsync.handler.ContentUpdateHandler/customtype"
 */
public class CustomTypeUpdateHandler implements ContentUpdateHandler {
    // add your code here
}

/*
 * @scr.component metatype="no" inherit="true"
 * factory="com.day.cq.contentsync.handler.ContentUpdateHandler/othertype"
 */
public class OtherTypeUpdateHandler extends AbstractSlingResourceUpdateHandler {
    // add your code here
}

Observera att fabrik definitionen innehåller det gemensamma gränssnittet och den anpassade typen separerad med snedstreck. Den här strategin gör att innehållssynkroniseringsramverket kan hitta och skapa en instans av din anpassade klass som känner igen den anpassade typen i en konfigurationspost. I nästa avsnitt finns ett konkret exempel på en anpassad uppdateringshanterare.

Implementera en anpassad uppdateringshanterare implementing-a-custom-update-handler

På varje sida för e-butiksmobilen finns en logotyp i det övre vänstra hörnet som vi förstås vill inkludera i zip-filen. För cacheoptimering refererar AEM inte till bildfilens verkliga plats i databasen, vilket förhindrar oss från att använda copy konfigurationstyp. Vad vi måste göra istället är att erbjuda våra logo konfigurationstyp som gör bilden tillgänglig på den plats som AEM begär. I följande kodexempel visas den fullständiga implementeringen av hanteraren för uppdatering av logotyp:

LogoUpdateHandler.java logoupdatehandler-java

package com.day.cq.wcm.apps.weretail.impl;

import javax.jcr.Node;
import javax.jcr.RepositoryException;
import javax.jcr.Session;

import org.apache.sling.api.resource.Resource;
import org.apache.sling.api.resource.ResourceResolver;
import org.apache.sling.jcr.resource.JcrResourceResolverFactory;

import com.day.cq.commons.jcr.JcrUtil;
import com.day.cq.contentsync.config.ConfigEntry;
import com.day.cq.contentsync.handler.ContentUpdateHandler;
import com.day.cq.wcm.foundation.Image;
import com.day.text.Text;

/**
 * The <code>LogoUpdateHandler</code> is used to update the content sync cache
 * with a page logo added using a logo component.
 *
 * @scr.component metatype="no"
 * factory="com.day.cq.contentsync.handler.ContentUpdateHandler/logo"
 */
public class LogoUpdateHandler implements ContentUpdateHandler {

    private static final Logger log = LoggerFactory.getLogger(LogoUpdateHandler.class);

    /** @scr.reference policy="static" */
    protected JcrResourceResolverFactory resolverFactory;

    public boolean updateCacheEntry(ConfigEntry configEntry, Long lastUpdated, String configCacheRoot, Session admin, Session session) {
        ResourceResolver resolver = resolverFactory.getResourceResolver(admin);
        Resource resource = resolver.getResource(configEntry.getContentPath());

        Image img = new Image(resource);
        img.setItemName(Image.NN_FILE, "image");
        img.setItemName(Image.PN_REFERENCE, "imageReference");
        img.setSelector("img");

        try {
            if(img.getLastModified() == null || lastUpdated < img.getLastModified().getTime().getTime()) {
                String src = img.getSrc();
                String parentPath = configCacheRoot + Text.getRelativeParent(src, 1);

                Node parent = JcrUtil.createPath(parentPath, "sling:Folder", admin);
                Node image = resolver.getResource(resource.getPath() + "/image").adaptTo(Node.class);
                JcrUtil.copy(image, parent, Text.getName(src));

                admin.save();

                return true;
            }
        } catch (RepositoryException e) {
            log.error("Unexpected error while updating logo: ", e);
        }

        return false;
    }
}

The LogoUpdateHandler klassen implementerar ContentUpdateHandler gränssnitt updateCacheEntry(ConfigEntry, Long, String, Session, Session) -metod, som tar ett antal argument:

Om du vill implementera den anpassade hanteraren skapar du först en instans av klassen Image baserat på resursen som anges i konfigurationsposten. Detta är i princip samma procedur som den faktiska logotypkomponenten på våra sidor gör. Det ser till att målsökvägen för bilden är densamma som den som en sida refererar till.

Kontrollera sedan om resursen har ändrats sedan den senaste uppdateringen. Anpassade implementeringar bör undvika onödiga uppdateringar av cachen och returnera false om inget ändras. Om resursen har ändrats kopierar du bilden till den förväntade målplatsen i förhållande till cacheroten. Äntligen true returneras för att ange för ramverket att cachen har uppdaterats.

Använda innehållet på klienten using-the-content-on-the-client

För att kunna använda innehåll i en mobilapp som tillhandahålls av Content Sync måste du begära innehåll via en HTTP- eller HTTPS-anslutning. Det innebär att hämtat innehåll (packat i en ZIP-fil) kan extraheras och lagras lokalt på den mobila enheten. Observera att innehåll inte bara avser data utan även logik, dvs. fullständiga webbapplikationer. vilket gör det möjligt för mobilanvändaren att köra hämtade webbprogram och motsvarande data även utan nätverksanslutning.

Innehållssynkronisering levererar innehåll på ett intelligent sätt: Endast dataändringar sedan den senaste lyckade datasynkroniseringen levereras, vilket minskar tiden för dataöverföring. Vid den första körningen av en programdataändring begärs ändringar sedan den 1 januari 1970, medan endast data som ändrats sedan den senaste lyckade synkroniseringen efterfrågas. AEM använder ett klientkommunikationsramverk för iOS för att förenkla datakommunikation och dataöverföring så att en minimal mängd systemspecifik kod krävs för att aktivera ett iOS-baserat webbprogram.

Alla överförda data kan extraheras till samma katalogstruktur, det finns inga ytterligare steg (t.ex. beroendekontroller) som krävs när data extraheras. Om det gäller iOS lagras alla data i en undermapp i mappen Documents i iOS App.

Vanlig körningssökväg för en iOS-baserad AEM Mobile-app:

Om det inte går att upprätta en anslutning visas tidigare hämtade data.

Komma framåt getting-ahead

Mer information om roller och ansvar för en administratör och utvecklare finns i resurserna nedan: