Estruturar um aplicativo

OBSERVAÇÃO

A Adobe recomenda o uso do Editor de SPA para projetos que exigem renderização do cliente baseada em estrutura de aplicativo de página única (por exemplo, Reagir). Saiba mais.

Um projeto da AEM Mobile envolve um conjunto diversificado de tipos de conteúdo, incluindo páginas, bibliotecas de clientes JavaScript e CSS, componentes AEM reutilizáveis, configurações de Sincronização de conteúdo e conteúdo do shell de aplicativo PhoneGap. Basear seu novo aplicativo AEM Mobile no Starter Kit é uma boa maneira de inserir todos os diferentes tipos de conteúdo em nossa estrutura recomendada para facilitar a portabilidade e a manutenção a longo prazo.

Conteúdo da página

As páginas do aplicativo devem estar todas localizadas abaixo de /content/mobileapps para que sejam reconhecidas pelo console do AEM Mobile.

chlimage_1-52

Por AEM convenção, a primeira página do aplicativo deve ser um redirecionamento para um dos filhos, que serve como o idioma padrão do aplicativo ('en' nos casos do Geometrixx e do Starter Kit). A página de local de nível superior normalmente é herdada do componente 'splash-page' da base (/libs/mobileapps/components/splash-page?lang=pt-BR) que cuida da inicialização necessária para suportar a instalação de atualizações de Sincronização de conteúdo ao ar (o código contentInit pode ser encontrado em /etc/clientlibs/mobile/content-sync/js/contentInit.js).

Modelos e componentes

O modelo e o código do componente do aplicativo devem estar localizados em /apps/<nome da marca>/<nome do aplicativo>. Em conformidade com a convenção, você deve colocar o modelo e o código do componente em /apps/<nome da marca>/<nome do aplicativo>. Esse padrão deve ser familiar para desenvolvedores que já trabalharam com o Site em AEM. Normalmente, é seguido como /apps/ está bloqueado para acesso anônimo por padrão nas instâncias de publicação. Assim, seu código JSP bruto está oculto de possíveis atacantes.

Os modelos específicos do aplicativo podem ser configurados para serem apresentados somente usando o nó de propriedade allowedPaths no próprio modelo e definindo seu valor como '/content/mobileapps(/.*?lang=pt-BR)?' - ou mesmo algo mais específico se o modelo só deve ser utilizado para um único aplicativo. As propriedades allowedParents e allowedChildren também podem ser aproveitadas para obter um controle muito refinado de quais modelos estarão disponíveis para um autor com base no local em que a nova página está sendo criada.

Ao criar um novo componente de página do aplicativo do zero, é recomendável definir sua propriedade sling:resourceSuperType como 'mobileapps/components/angle/ng-page'. Isso configurará sua página para criação e renderização como um aplicativo de página única e permitirá que você sobreponha quaisquer arquivos .jsp que seu componente precise alterar. Como ng-page não inclui nenhuma estrutura de interface de usuário, um desenvolvedor normalmente acabará sobrepondo (pelo menos) 'template.jsp' (sobreposto de /libs/mobileapps/components/angular/ng-page/template.jsp).

Os componentes de página autoráveis, que desejam aproveitar AngularJS, têm um componente sling:resourceSuperType equivalente localizado em /libs/mobileapps/components/angular/ng-component que pode ser sobreposto e personalizado da mesma maneira.

JavaScript e Clientlibs CSS

Quando se trata de bibliotecas de clientes, há algumas opções disponíveis para o desenvolvedor de onde colocá-las no repositório. O seguinte padrão é oferecido como orientação, mas não é um requisito difícil.

Se o código do cliente puder ficar por conta própria e não estiver relacionado a um componente específico do aplicativo - o que significa que ele pode ser reutilizado em outros aplicativos - recomendamos armazená-lo em /etc/clientlibs/<nome da marca>/<nome da biblioteca>. Por outro lado, se a clientlib for específica de um único aplicativo, você poderá aninhá-la como um filho do nó de design do aplicativo; /etc/designs/phonegap/<nome da marca>/<nome do aplicativo>/clientlibs. A categoria deste clientlib não deve ser usada por outras libs e deve ser usada para incorporar outras libs, conforme necessário. Seguir esses padrões evita que o desenvolvedor tenha que adicionar novas configurações de Sincronização de conteúdo sempre que uma biblioteca cliente for adicionada ao aplicativo, em vez de simplesmente atualizar a propriedade "embeds" da clientlib de design do aplicativo. Por exemplo, observe o nó de configuração Geometrixx clientlibs-all Content Sync em /content/phonegap/geometrixx-outdoors/en/jcr:content/pge-app/app-config/clientlibs-all.

Se o código do lado do cliente estiver estreitamente associado a um componente específico, coloque-o em uma biblioteca do cliente aninhada abaixo da localização do componente em /apps/ e incorpore-o à categoria do cliente 'design' do aplicativo.

Configuração do PhoneGap

Cada aplicativo AEM Mobile contém um diretório que hospeda os arquivos de configuração usados pela interface de linha de comando PhoneGap e PhoneGap build🔗 para transformar seu conteúdo da Web em um aplicativo executável. Por exemplo, na amostra de Geometrixx, esse diretório (/content/phonegap/geometrixx-outdoors/shell/jcr:content/pge-app/app-content?lang=pt-BR) está localizado como parte do Shell; uma decisão de design tomada devido ao fato de conter apenas conteúdo que não pode ser atualizado ao ar, como plug-ins que lidam com as APIs do dispositivo e a configuração do próprio aplicativo.

Neste diretório, você também encontrará vários ganchos do Cordova que podem ser usados para instalar plug-ins, colocar arquivos de recursos em seus locais específicos da plataforma e outras ações que devem ser executadas como parte da compilação. Observação: como alternativa ao download de cada plug-in como parte da criação, você pode seguir o padrão do aplicativo Kitchen Sink e incluir código fonte do plug-in com o restante do projeto do aplicativo.