Struttura di un'app structure-an-app

Un progetto AEM Mobile include un set diversificato di tipi di contenuto, tra cui pagine, librerie client JavaScript e CSS, componenti AEM riutilizzabili, configurazioni di sincronizzazione dei contenuti e contenuto della shell dell’app PhoneGap. Basare la nuova app AEM Mobile su Kit iniziale è un buon modo per inserire tutti i diversi tipi di contenuto nella struttura consigliata per facilitare sia la portabilità che la manutenzione a lungo termine.

Contenuto della pagina page-content

Le pagine dell’applicazione devono essere tutte situate sotto /content/mobileapps per essere riconosciute dalla console AEM Mobile.

Per convenzione, la prima pagina dell’app deve essere un reindirizzamento a uno dei suoi elementi figlio, che funge da lingua predefinita dell’app ("en" nei casi Geometrixx e Starter Kit). La pagina locale di primo livello eredita tipicamente dal componente 'splash-page' di base (https://experienceleague.adobe.com/libs/mobileapps/components/splash-page?lang=it) che si occupa dell'inizializzazione necessaria per supportare l'installazione degli aggiornamenti di sincronizzazione dei contenuti offline (il codice contentInit può essere trovato all'indirizzo /etc/clientlibs/mobile/content-sync/js/contentInit.js).

Modelli e componenti templates-and-components

Il modello e il codice del componente per l'app devono trovarsi in /apps/<brand name="">/<app name="">. In conformità alla convenzione, dovresti inserire il modello e il codice componente in /apps/<brand name="">/<app name="">. Questo modello deve essere familiare agli sviluppatori che hanno già lavorato con Site in AEM. Viene generalmente seguito come /apps/ viene bloccato per impostazione predefinita all’accesso anonimo nelle istanze di pubblicazione. Di conseguenza, il codice JSP non elaborato è nascosto a potenziali aggressori.

È possibile configurare modelli specifici per le app in modo che siano presentati solo utilizzando il allowedPaths nodo di proprietà sul modello stesso e impostazione del relativo valore su '/content/mobileapps(https://experienceleague.adobe.com/.*?lang=it)?" - o qualcosa di più specifico se il modello deve essere utilizzabile solo per una singola app. La allowedParents e allowedChildren è inoltre possibile sfruttare le proprietà per un controllo a grana molto fine sui modelli disponibili per un autore in base alla posizione in cui viene creata la nuova pagina.

Quando crei un nuovo componente per la pagina dell’app da zero, si consiglia di impostarlo come sling:resourceSuperType su 'mobileapps/components/angular/ng-page'. Questo consente di impostare la pagina sia per l’authoring che per il rendering come app a pagina singola e di sovrapporre eventuali file .jsp che il componente potrebbe dover modificare. Poiché ng-page non include alcun framework di interfaccia utente, uno sviluppatore generalmente finisce per sovrapporre (almeno) 'template.jsp' (sovrapposto da /libs/mobileapps/components/angular/ng-page/template.jsp).

I componenti di pagina autorizzati che desiderano sfruttare AngularJS hanno un equivalente sling:resourceSuperType componente situato in /libs/mobileapps/components/angular/ng-component che può essere sovrapposto e personalizzato nello stesso modo.

Clientlibs JavaScript e CSS javascript-and-css-clientlibs

Per quanto riguarda le librerie client, lo sviluppatore può scegliere dove inserirle nell’archivio. Il seguente modello è offerto per la guida, ma non è un requisito difficile.

Se il tuo codice clientside può stare da solo e non si riferisce a un componente specifico della tua applicazione - ovvero può essere riutilizzato in altre applicazioni - si consiglia di memorizzarlo in /etc/clientlibs/<brand name="">/<lib name="">. D’altro canto, se la clientlib è specifica per una singola app, puoi nidificarla come elemento secondario del nodo di progettazione dell’app; /etc/designs/phonegap/<brand name="">/<app name="">/clientlibs. La categoria di clientlib non deve essere utilizzata da altre librerie e deve essere utilizzata per incorporare altre librerie come necessario. Seguendo questi pattern, lo sviluppatore non deve aggiungere nuove configurazioni di sincronizzazione dei contenuti ogni volta che una libreria client viene aggiunta all’app, ma semplicemente aggiornare la proprietà "embeds" della clientlib di progettazione dell’app. Ad esempio, dai un'occhiata al nodo di configurazione clientlibs-all Content Sync in /content/phonegap/geometrixx-outdoors/en/jcr:content/pge-app/app-config/clientlibs-all.

Se il codice lato client è strettamente associato a un componente specifico, inseriscilo in una libreria client nidificata sotto la posizione del componente in /apps/ e incorporalo nella clientlib 'design' dell'app.

Configurazione di PhoneGap phonegap-configuration

Ogni app AEM Mobile contiene una directory che ospita i file di configurazione utilizzati da PhoneGap interfaccia a riga di comando e PhoneGap build per trasformare il contenuto web in un’applicazione eseguibile. Nell’esempio di Geometrixx, ad esempio, questa directory (https://experienceleague.adobe.com/content/phonegap/geometrixx-outdoors/shell/jcr:content/pge-app/app-content?lang=it) si trova come parte della Shell; una decisione di progettazione presa a causa del fatto che contiene solo contenuti che non possono essere aggiornati nell’aria, come plug-in che si occupano delle API dei dispositivi e della configurazione dell’app stessa.

In questa directory troverete anche una serie di Hook Cordova che può essere utilizzato per installare i plug-in, inserire i file di risorse nelle rispettive posizioni specifiche della piattaforma e altre azioni che devono essere eseguite come parte della build. Nota: come alternativa al download di ogni plug-in come parte della build, è possibile seguire il modello dell'app Kitchen Sink e include il codice sorgente del plug-in con il resto del progetto dell'app.

Passaggi successivi the-next-steps

Una volta appresa la struttura dell’app, consulta Creazione e modifica delle app tramite la console App.