Une introduction à ASP.NET Mobile

procedure TWebFormDefault.Page_Load(sender: System.Object; e: System.EventArgs);
begin
  if (Request.Browser['IsMobileDevice']= 'true' )  then Response.Redirect(DEFAULT_MOBILEINDEX)
  else Response.Redirect(DEFAULT_DESKTOPINDEX);
end;

Dans le cas du traitement d'un PostBack, il faut utiliser la méthode « RedirectToMobilePage » de MobilePage.

ASP.NET fournit trois modes d'authentication paramétrables dans le fichier web.config du site : le mode d'authentification par formulaire, windows et passport. Les authentifications spécifiques « au monde Windows » ne sont généralement pas implémentées par les périphériques mobiles. Sur IIS l'authentification « Anonyme » et « de Base » (login/password en clair) fonctionnement généralement. Par contre l'authentification NTLM est un charabia indécryptable pour les mobiles.

Dans le fichier config.web du site, la section authentication permet de spécifier le mode d'authentification utilisé par le site.

<authentication mode="Forms">
    <forms name=".ASPXAUTH" loginURL="logon.aspx" protection="All" timeout="60"/>
</authentication>

Idéalement située sur le serveur, la session est liée à la configuration du client. Par exemple un navigateur n'acceptant pas les cookies persistants passera l'état d'authentification le temps d'une requête. La requête suivante, le cookie non présent (puisque refusé), n'indexera plus ce client comme authentifié… Cette limitation est encore plus marquée pour les mobiles. Les cookies ne sont pas supportés par les périphériques mobiles comme les téléphones portables. ASP.NET intègre un paramétrage avancé des différents modes de session. Dans la section <system.web> du fichier de configuration, la section sessionState indique au framework comment celle-ci est gérée. Voici les différents paramètres possibles :

<sessionState mode="InProc" cookieless="true" timeout="10"/>

ASP.NET permet de fonctionner avec les mobiles sans avoir à développer une gestion de session particulière comme il était nécessaire encore avec ASP et la gestion de session via l'url type url?SessionId=ad1j8k7bbjhoo12871. Il est à noter que pour une session maintenue sans cookie, l'url présentée au client est préfixée de l'ID de session :

http://www.Delphinaute.be/ChapsAndChips/(agemaq55xturnxrpyv0rh2ag)/MobileDefault.aspx

Attention, des problèmes de redémarrage automatique de l'application (« recycling ») sont référencés dans différentes situations par exemple lors du parcours de l'arborescence avec un antivirus (http://support.microsoft.com/default.aspx?scid=kb;en-us;324772 ou http://support.microsoft.com/kb/316148/EN-US/). Dans cette situation, avec le mode « InProc », les données de session sont réinitialisées et donc perdues ! La résolution classique est le stockage persistant (Stateserver ou SQLServer) de la session. Par exemple, en mode « StateServer » via le service ASP.NET State Service en ajoutant l'attribut « StateConnectionString » indiquant quel serveur est utilisé :

<sessionState mode="StateServer" stateConnectionString="tcpip=localhost:42424"
        cookieless="true" timeout="10"/>

Avec ASP.NET, l'état des pages est automatiquement sauvegardé dans une zone VIEWSTATE. Cette zone d'information est postée au client. Le VIEWSTATE pouvant être important, en général les capacités des périphériques mobiles ne sont pas suffisantes pour gérer ces informations. Les caractéristiques du/des client(s) cible(s) déterminent le choix de l'utilisation de cette fonctionnalité intégrée.

Les filtres sont recensés dans le fichier web.config du site dans la section <system.web><deviceFilters>.

<deviceFilters>
    <filter name="isJScript" compare="javascript" argument="true"/>
    <filter name="isPocketIE" compare="browser" argument="Pocket IE"/>
    <filter name="isHTML32" compare="preferredRenderingType" argument="html32"/>
</deviceFilters>

Le contrôle ASP.NET Mobile « DeviceSpecific » associé à « Choice » et son argument « filter » utilisent cette liste pour déterminer le filtre qui correspond au client. Cette logique correspond à une figure algorithmique du type « Case » (Pascal) ou du type « Switch » en C avec comme opérande le type de périphérique du client mobile du site.

<mobile:panel id=summary runat="server">
 <mobile:devicespecific id=DeviceSpecific1 runat="server">
   <choice filter="isJScript">
    <contenttemplate>
      <aspnetportal:title runat="server"/>  
         <%#mobileSummary %>
            <asp:linkbutton id="LinkButton1" runat="server" 
               commandname="Details" text="(+)" visible="<%# mobileDetails != String.Empty %>">
            </asp:linkbutton>  
    </contenttemplate>
  </choice>
 </mobile:devicespecific>
</mobile:panel>

Le contenu du composant panel du contrôle DeviceSpecific1 est variable en fonction de la validité du filtre appliqué au client. Dans cet exemple, le panel « summary » sera enrichi de la partie <contenttemplate> dans le cas où le client est compatible JavaScript.

Les adaptateurs personnalisés sont référencés dans le fichier Web.config du site dans la section <system.web><mobileControls>. Ces adaptateurs (cf. Design Pattern) correspondent à une implémentation personnalisée pour un contrôle et un format de sortie.

<mobileControls>

  <device name="PortalHtmlDeviceAdapters" inheritsFrom="HtmlDeviceAdapters">
    <control name="MobileControls.TabbedPanel,ASPNET.StarterKit.delphiPortal.PortalCSSDK"
      adapter="MobileControls.HtmlTabbedPanelAdapter,ASPNET.StarterKit.delphiPortal.PortalCSSDK"/>
    <control name="MobileControls.LinkCommand,ASPNET.StarterKit.delphiPortal.PortalCSSDK"
      adapter="MobileControls.HtmlLinkCommandAdapter,ASPNET.StarterKit.delphiPortal.PortalCSSDK"/>
  </device>

  <device name="PortalChtmlDeviceAdapters" inheritsFrom="ChtmlDeviceAdapters">
    <control name="MobileControls.TabbedPanel,ASPNET.StarterKit.delphiPortal.PortalCSSDK"
      adapter="MobileControls.ChtmlTabbedPanelAdapter,ASPNET.StarterKit.delphiPortal.PortalCSSDK"/>
  </device>

  <device name="PortalWmlDeviceAdapters" inheritsFrom="WmlDeviceAdapters">
    <control name="MobileControls.TabbedPanel,ASPNET.StarterKit.delphiPortal.PortalCSSDK" 
      adapter="MobileControls.WmlTabbedPanelAdapter,ASPNET.StarterKit.delphiPortal.PortalCSSDK"/>
  </device>

</mobileControls>

Dans cet exemple, pour chacun des trois formats (html, chtml, wml) supportés par ASP.NET Mobile un nouveau « device » est recensé. Pour chacun de ces « device », le contrôle « TabbedPanel » est recensé avec un attribut « adapter » qui référence dans quelle classe de quel assemblage le nouveau contrôle est implémenté. Le contrôle « TabbedPanel » est disponible pour les trois formats standards. Le contrôle « LinkCommand » est uniquement disponible pour le format html.

Avant de démarrer les tests, il est important de vérifier les différents points abordés précédemment. L'authentification ne devrait pas causer d'effets de bord. Par contre une mauvaise anticipation des différents autres paramètres peut avoir des conséquences dramatiques sur les tests.

Une page dédiée Mobiles est visualisable avec votre navigateur habituel. Cependant pour tester le rendu réel ainsi que la compatibilité avec le système cible, il est fortement conseillé d'utiliser un émulateur ou encore mieux de tester avec le périphérique cible. Chaque constructeur fournit généralement un émulateur permettant de vérifier la compatibilité avec ses périphériques. D'autres éditeurs proposent des émulateurs multipériphériques. Ces émulateurs permettent de simuler des périphériques génériques ou un périphérique plus spécifiquement ciblé. Les SDK Microsoft Pocket PC et SmartPhone sont intégrés dans environnement Visual Studio .NET. Nous utiliserons Openwave V7 simulator pour tester le projet accompagnant cet article en raison de sa mise en œuvre très simple et indépendante d'un outil de développement particulier.

Téléchargement du projet Delphi .NET

Cette application ASP.NET Mobile est un exemple ayant pour cible différents périphériques : les navigateurs « du monde Desktop » et les périphériques Mobiles. Cet exemple simple met en œuvre des contrôles Mobiles standards et un exemple de filtre.

La version du framework utilisée est Microsoft .NET Framework 1.1.

Les étapes suivies avec Delphi 8 .Net pour construire une page Mobiles du projet accompagnant cet article sont résumées ci-dessous. Ces étapes permettent de contourner l'erreur Delphi de conception avec « le concepteur de premier niveau » qui (a priori) correspond à un concepteur typé « WebForm ».

Cet exemple utilise le webservice « GlobalWeather » de CapeSciencepour obtenir les informations météorologiques. Le web service proxy, développé par Bernhard Gaul @ http://www.bgxcomponents.com, est nécessaire sur le serveur où est installé l'application ASP.NET Mobile. Il chaîne les demandes vers le webservice CapeScience : c'est un Web Service Proxy.

L'importation du WSDL dans Delphi est effectuée via l'ajout d'une référence Web pointant sur le web service proxy local.

Type
....
GET_Weather = class(System.Web.Services.Protocols.SoapHttpClientProtocol)
....
.... 

constructor GET_Weather.Create;
begin
  inherited Create;
  Self.Credentials:=System.Net.CredentialCache.DefaultCredentials; // ++
  Self.Url := 'http://localhost/meteows/GET_Weather.asmx';
end;

Ce code copie les informations d'authentification système du contexte de sécurité en cours dans le client SOAP delphi. Pour les applications ASP.NET, les informations d'authentification par défaut sont les informations d'authentification utilisateur de l'utilisateur en cours ou de l'utilisateur ayant effectué un emprunt d'identité. Cette affectation permet au client du web service de négocier avec le serveur pour déterminer quel mode d'authentification utiliser (NTLM et/ou Kerberos).

Cet exemple est assez « minimaliste », mais peut-être très facilement étendu. Par exemple la transmission des données des stations météo mériterait d'être conservée en cache afin de ne pas accéder à chaque requête (de choix de station) au webservice « ReportWeather de CapeScience ». De même le « look and feel » de l'application n'est pas « très travaillé », le but de cette démonstration n'étant pas de faire du design web. Cette partie est facilement améliorable. Ces améliorations constituent un bon exercice de test afin de vérifier vos connaissances d'ASP.NET Mobile.