2009-08-31 2 views
6

Il semble qu'il n'existe pas de véritable standard pour spécifier "taille d'écran" dans un en-tête http d'un agent utilisateur.Résolution de l'appareil mobile (largeur, hauteur) taille de l'écran en-tête

Par exemple, les deux têtes ci-dessous:

X-UP-devcap-screenpixels: 320x240 

ou

UA-pixels: 320x240 

sont deux têtes couramment utilisés. La seconde est principalement utilisée par les appareils Windows Mobile. Le X-UP semble provenir de la passerelle du navigateur UP.

Une autre option est

X-Screen-Width: 320 
X-Screen-Height: 240 

X-Screen-largeur peut être un en-tête vers le haut.

Ma question est:

Qu'est-ce qu'un bon niveau d'adopter notre « transcodeur » aller de l'avant? Ce n'est pas vraiment un navigateur Web complet, mais c'est surtout pour les sites limités. Mais ce devrait être la norme qui serait adoptée par Opera Mini/GWT, etc.

Ni Opera Mini ni Google Web Transcoder n'envoient ces informations dans leurs requêtes HTTP. Je suppose qu'ils s'attendent à ce que le site recherche le modèle du téléphone, et donc la largeur et la hauteur de l'écran, côté serveur.

En fait, j'ai trouvé ce RFC 4229 appelé HTTP Header Field Inscriptions. C'est un peu démodé, et une mission à apporter des correctifs.

Si je devais voir ce qui est principalement utilisé sur le terrain, je finirais probablement par "UA-Pixels".

Quelques références

  • Certains appareils (principalement Windows Mobile encore) ont une valeur 320x240 dans l'en-tête de l'agent utilisateur
+0

Une autre bonne ressource: http://mobiforge.com/developing/blog/useful-x-headers Je ne pouvais pas poster ce lien en raison de la limite de 1 lien pour les nouveaux utilisateurs. –

+1

Je travaille dans une entreprise de fournisseur de contenu, En interne, nous utilisons la base de données [WURFL] [1] pour déterminer la taille de l'écran des appareils particuliers. [1]: http://wurfl.sourceforge.net – ariefbayu

+0

Vrai, mais ce que nous avons est un CLIENT -> Proxy -> SITE. Nous possédons le CLIENT et le Proxy, nous voulons donc simplifier le SITE que nous demandons en fournissant déjà la largeur et la hauteur pour que chaque SITE ne soit pas obligé de réimplémenter la recherche et la maintenance de Wurfl etc. Parce que nous avons déjà l'information de l'appareil dans notre client. (JME etc) –

Répondre

3

Il est pire que vous le pensez.

UA-pixels: 320x240

est souvent un mensonge. Sur IEMobile, la version < 8 (Windows Mobile.1.4) les appareils avec 640x480 pixels se signalent toujours comme 320x240. En outre, dans la plupart des versions d'IEMobile, la vue peut être agrandie dans une certaine mesure, de sorte que la taille du motif à atteindre ne soit pas liée à la taille UA-pixels.

Les possibilités de mise en page liquide sont limitées avant IEMobile 8. Pourtant, dans IEMobile 8 sur WinMobile 6.5, vous obtenez une résolution XGA, un zoom arrière, que cela vous plaise ou non. Oh, et il n'y a aucun moyen de renifler IEM8-on-6.5 par rapport à IEM8-on-6.1 à partir des en-têtes. Je ne suis pas sûr quel est exactement le but de votre application, mais la sortie de HTML/CSS qui rend exactement à la taille de l'écran est pratiquement impossible si vos cibles incluent l'horreur abyssale qu'est IEMobile.

+0

Le but est plus de corriger les largeurs d'image (Probablement l'objectif le plus commun de la plupart des bases de données de périphériques). Mais c'est plus comme Opera Mini, prend le HTML, le place dans un langage de binaire binaire, qui est ensuite interprété par le client. –

0

Voici une liste des en-têtes de résolution d'écran commun:

X-UP-devcap-screenpixels 

ou

UA-pixels 

ou

X-JPHONE-DISPLAY 

Je regardais l'extrait de code que Google donne de leur Adsense mobile et ce sont les trois qu'ils vérifient jusqu'à présent.

Questions connexes