Web pour les appareils mobiles - les meilleures pratiques pour ASP.NET [fermé]

Question

À partir de créer des applications Web pour les appareils mobiles (tout téléphone).
Quelle serait la meilleure approche en utilisant ASP.NET 3.5 / ASP.NET 4.0 et C #?

Mise à jour (Feb2010)
Des nouvelles en utilisant Windows Mobile 7?

Answer 1

Cela dépend si vous voulez vraiment soutenir chaque téléphone cellulaire ou seulement haut de gamme ou un nouveau téléphone comme l'iPhone qui n'ont pas de limitations de rendu des pages Web. Si vous pouviez demander réel rendu HTML, support Javascript et les cookies sur le téléphone comme exigence , la contrainte réelle est la taille limitée de l'écran . Vous devriez faire très bien avec le développement web « normal » dans ASP.NET en prenant soin de la taille des pages.

Si tel est le cas, vous pourriez arrêter de lire ici.

Si vous vraiment envie de soutenir tous les téléphones cellulaires , les anciens en particulier, vous devez être conscient qu'il existe différents types de téléphones. Beaucoup d'entre eux ont limites et les contraintes affichage des pages Web. Certains d'entre eux peuvent utiliser JavaScript, mais beaucoup d'entre eux ne le font pas. Certains d'entre eux peuvent afficher le contenu HTML, mais beaucoup d'autres ne peuvent pas. Ils doivent compter sur la norme « Wireless Markup » pour l'accès Web. Ainsi, il est pas facile de construire un site Web qui prend en charge tous ces dispositifs différents.

Voici quelques liens vers le contenu général (pas ASP.NET spécifique), ce qui pourrait aider à obtenir l'image entière:

• Web mobile Best Practices 1.0 (W3C)
• Développeur Web mobile # s Guide (dotMobi)

Leur principale limitation est cependant, comme je l'ai déjà mentionné, l'écran plus petit que sur PC est normal. Et beaucoup de téléphones portables ne prennent pas en charge JavaScript, les cookies et certains ne présentent même pas les images.

Il existe des normes spéciales de marquage pour les téléphones cellulaires. pages WML est par exemple une norme largement adoptée pour les téléphones cellulaires. WML signifie « Wireless Markup » qui est basé sur XML. Vous trouverez une description et référence de WML ici sur w3schools.com .

Le code ci-dessous montre une page WML exemple:

<?xml version="1.0"?>
<!DOCTYPE wml PUBLIC "-//WAPFORUM//DTD WML 1.1//EN"
   "http://www.wapforum.org/DTD/wml_1.1.xml">

<wml>
   <card id="card1" title="Stackoverflow">
      <do type="accept" label="Menu">
         <go href="#card2"/>
      </do>
      <p>
         <select name="name"> 
            <option value="Questions">Questions</option>
            <option value="MyAccount">My account</option>
            <option value="FAQ">FAQ</option>
         </select>
      </p>
   </card>
   <card id="card2" title="Menu">
      <p>
           You selected: $(name)
      </p>
   </card>
</wml>

Les bonnes nouvelles sont que ASP.NET rend WML (et d'autres normes de balisage mobiles) contenu automatiquement. Vous ne devez pas écrire WML vous fichiers. Un mécanisme intégré détecte le type de dispositif (téléphone cellulaire) des requêtes web. Cependant, la détection de l'appareil mobile sur ASP.NET ne fonctionne pas correctement pour certains périphériques (les plus récents). Jetez un oeil à WURFL , un fichier de configuration XML qui contient des informations sur les capacités et les fonctionnalités de nombreux appareils mobiles.

Vous pouvez tester les pages que vous développez dans ASP.NET dans un navigateur Web standard, mais il ne serait pas donner l'image e droit de ce que vous avez développé. Il y a quelques émulateurs disponibles pour ce problème, qui simulent un téléphone portable sur votre ordinateur de bureau. Il y a un article de support Microsoft qui explique où vous pouvez les télécharger.

ASP.NET Mobile Controls

Les contrôles mobiles ASP.NET, anciennement knowns comme exteNd le .NET Framework "Microsoft Mobile Internet Toolkit" et Visual Studio pour créer des applications Web mobiles ASP.NET en permettant de fournir des balises à une grande variété d'appareils mobiles.

Les contrôles mobiles ASP.NET rendent le balisage approprié (HTML 3.2, WML 1.1, cHTML, XHTML) tout en traitant avec différentes tailles d'écran, des orientations et des capacités de l'appareil.

En savoir plus ici sur le site web officiel .

Answer 2

Un couple de choses que je dois mentionner que je travaille sur un réseau sans fil au Canada. Essayez de garder toutes les images de petite taille (voire inexistante) pour augmenter les temps de chargement et de réduire les frais de données. Sur notre réseau, si l'utilisateur n'a pas souscrit à un plan, notre réseau charge 15 $ / mb. Quelques images non optimisées un téléphone essaie de télécharger pourrait facilement coûter l'utilisateur, et ces grandes images ne seront pas l'air bien de toute façon.

Je sais que cela ne vous affecte pas, mais si vous utilisez d'autres protocoles, tels que le streaming, ou des protocoles basés sur UDP, définissez la taille maximale du paquet atleast 1300 octets ou moins. Juste à cause de la façon dont un mobile fonctionne comme il est se déplace autour du réseau, les informations d'en-tête supplémentaires get ajouté. Avec TCP / IP, nous utilisons MSS de serrage pour protéger contre les grands problèmes de paquets, mais cela ne peut être appliquée à toute transmission UDP, ou quoi que ce soit le protocole sécurisé qui utilise un en-tête d'authentification. Si les mobiles vous ciblez sont proposés par RIM, ce point peut être ignoré complètement.

Certains mobiles peuvent utiliser un proxy WAP lorsque vous parlez à vous êtes serveur, si tel est le cas, essayez d'éviter d'utiliser des connexions qui nécessitent une connexion TCP / IP keep-alive. Certains mandataires sont définis pour ne pas permettre à des séances de keep-alive passent par eux, même si je beleive la plupart des nouvelles sont très bien.

Je suis sûr qu'il ya plus, la chose la plus importante que vous devez garder à l'esprit que vous êtes la connectivité IP au mobile est beaucoup plus complexe que quelqu'un d'ouvrir un navigateur Web. Ce transport peut être extrêmement difficile, donc si vous essayez de faire quelque chose de vraiment de fantaisie, même si cela fonctionne maintenant, il ne fonctionne pas toujours. De plus, un dernier point rapide, le temps de latence et la perte de paquets peut varier d'une manière extravagante, donc si vous faites quoi que ce soit en temps réel, vous pouvez frapper la latence de 200 ms +, et je l'ai vu pic de perte de paquets à 20-30% pour les niveaux de court fois.

Bonne chance, et si vous avez des questions, assurez-vous de leur demander.

Answer 3

Plus d'informations ici: fenêtres-mobile-développement où-begin