Planification de l'installation de IBM® MobileFirst®

Déterminez les services et la fonction de votre application hybride avant d'installer MobileFirst®. Vous devez installer un serveur MobileFirst® dans certaines instances.

Exécution d'une application hybride dans une page de portail

Lorsque votre application hybride s'exécute avec vos pages HCL affichées dans une application native, HCL charge les ressources natives appropriées pour l'appareil. Ces ressources sont chargées automatiquement via des modules fournis dans HCL. Cela commence avec le module wp_worklight_ext qui est fourni dans certains des profils par défaut, y compris profile_deferred.json, profile_dojo_deferred.json et profile_basic_content.json.

Si vous voulez accéder aux ressources natives appropriées pour l'appareil sur une page particulière d'HCL, utilisez un profil incluant le module wp_worklight_ext. Le profil par défaut, profile_deferred.json, inclut wp_worklight_ext, et, par conséquent, les ressources natives appropriées sont disponibles par défaut pour vos pages HCL.

wp_worklight est un métamodule indépendant de la version qui est défini par le fichier mobilefirst70.json dans le dossier de contributions de votre thème. Ce module est un prérequis pour les ressources MobileFirst® par défaut qui activent l'accès aux fonctions natives. Il inclut également les substitutions qui améliorent les performances et permettent aux bibliothèques d'API de fonctionner au sein de la structure de module.

Les modules de plateforme dépendants de la version inclus dans l'infrastructure de module sont mf_ios_70 et mf_android_70. Ces modules de plateforme sont définis par le fichier plugin.xml dans le dossier PortalServer_root\theme\wp.theme.worklight.ext\installedApps\wp.theme.worklight.ext.ear\wp.theme.worklight.ext.war\WEB-INF de votre thème. Ces modules de plateforme chargent les ressources natives appropriées pour l'appareil et donnent accès à tout l'ensemble des API MobileFirst® et Cordova. Par exemple, cela donne accès aux ressources suivantes sur l'appareil :

  • Caméra
  • Géolocalisation
  • Contacts
  • Stockage local
  • Média
  • Notifications push
  • Informations sur l'utilisateur

Ces modules de plateforme sont chargés ou non en fonction des conditions de classe d'appareil, comme le montre le fragment de code plugin.xml suivant pour le module mf_android_70 :

<module id="mf_android_70">
        	<runtimeActivation>
				<condition deviceClass="worklight+android"/>
			</runtimeActivation>

Le module mf_android_70 est chargé si la classe d'appareil est à la fois MobileFirst® et Android. La classe d'appareil est déterminée par le serveur HCL en fonction de la chaîne d'agent utilisateur du périphérique client. Par exemple, une chaîne d'agent utilisateur relative à un téléphone Android est similaire à l'exemple ci-dessous :

Mozilla/5.0 (Linux; U; Android 4.0.4; en-gb; GT-I9300 Build/IMM76D) AppleWebKit/534.30 (KHTML, like Gecko) Version/4.0 Mobile Safari/534.30

Une application hybride MobileFirst® ajoute automatiquement "/Worklight/version" à la fin de la chaîne d'agent utilisateur, par exemple :

Mozilla/5.0 (Linux; U; Android 4.0.4; en-gb; GT-I9300 Build/IMM76D) AppleWebKit/534.30 (KHTML, like Gecko) Version/4.0 Mobile Safari/534.30/Worklight/6.1.0.0

Les applications Windows Phone MobileFirst ne peuvent pas modifier l'agent utilisateur. En revanche, HCL définit un cookie de session appelé wp.agent.ext sur "/Worklight" chaque fois qu'un paramètre de demande uri=wl:id est détecté, et ajoute la valeur de ce cookie à l'agent avant d'évaluer les classes d'appareil. Ce paramètre doit être présent dans la demande initiale provenant de l'application hybride ou bien MobileFirst® ne sera pas disponible sur les périphériques Windows Phone.

Une mise en correspondance est effectuée avant de déterminer les classes d'appareil à partir de la chaîne d'agent utilisateur. Les classes d'appareil déterminent à leur tour les modules de plateforme à télécharger. Par exemple, les ressources natives mf_android_70 sont chargées pour un portail qui est exécuté dans une application MobileFirst® hybride sur un périphérique Android. Mais elles ne sont pas chargées dans de nombreux autres cas. Par exemple, si elles sont chargées sur un appareil iOS, ou s'il s'agit d'un portail non encapsulé dans une application hybride MobileFirst®, ces ressources ne sont pas chargées.

Les pages du portail adaptent leurs fonctionnalités automatiquement en fonction de leur contexte d'exécution. Par exemple, une page peut fournir un accès à la caméra d'un appareil si elle est exécutée dans le contexte d'une application hybride MobileFirst®. Cette même page ne peut pas y accéder si elle est exécutée hors du contexte d'une application hybride MobileFirst®.

L'API Cordova et MobileFirst® comporte des substitutions en vue d'améliorer les performances et permettre l'intégration à HCL. Les substitutions permettent à l'API client MobileFirst® de rechercher les ressources dans l'application Web déployée. Les substitutions permettent également le conditionnement des plug-ins Cordova dans un module et l'extraction des multiples ressources JavaScript dans une demande par la structure d'agrégation de ressources.

Application d'interpréteur de commandes

Si votre application est un interpréteur de commandes qui utilise une vue Web pour afficher l'intégralité du marquage issu du site HCL, vous n'avez pas besoin de serveur MobileFirst®.

Si votre application utilise une approche avec modèle mixte dans laquelle une partie du marquage de l'application est issue d'HCL et l'autre partie de ressources natives susceptibles d'extraire des ressources Web Content Manager , vous devez installer un serveur MobileFirst® pour fournir ces ressources.

Service de mise à jour directe

Si vous projetez d'utiliser la fonction de service de mise à jour directe du marquage imbriqué pour les modifications, un serveur MobileFirst® est requis.

Notifications natives

Si votre application utilise des notifications natives, MobileFirst® est invité à générer le service de notification iOS et Android.

Services d'authentification

Si vous utilisez l'authentification MobileFirst® ou le service de contrôle d'accès pour la connexion unique (SSO) entre MobileFirst® et HCL, vous devez installer un serveur MobileFirst®. Si vous projetez d'utiliser un accès anonyme ou un accès à toutes les ressources de l'application via HCL ou HCL Web Content Manager, vous n'avez pas besoin de serveur MobileFirst®.

Suivi de l'utilisation

Si votre application utilise MobileFirst® pour effectuer le suivi de l'utilisation, vous devez installer un serveur MobileFirst®. Le serveur que vous installez doit également supporter la charge générée par les clients qui envoient des données d'utilisation.

Application des accès pour les appareils

Si vous assurez l'application des accès pour l'appareil vous devez installer un serveur MobileFirst® en vue de fournir les certificats pour l'appareil et les données.

Application Center EAR

Application Center EAR est une application facultative qui fournit un environnement de magasin d'applications. Si vous l'utilisez pour gérer des applications sur un appareil en tant que solution de gestion MDM, un serveur MobileFirst® est requis pour exécuter MobileFirst® EAR et Application Center EAR.