Pourquoi google.com est-il différent sur blackberry & amp; phonegap vs blackberry & amp; navigateur

Question

Je suis en train de préparer un coup de téléphone pour lancer Blackberry Storm (simulateur 9530). J'avais testé ma webapp depuis le navigateur intégré de BB, et ça avait l'air correct, mais ça a été totalement bousculé une fois que j'ai essayé de regarder le code dans l'intervalle téléphonique, même si je pointais l'écart téléphone vers la même URL (je n'avais pas encore eu le point d’exécuter du code localement sur le périphérique).

J'ai essayé un cas de test sur Google et obtenu des résultats similaires. voir ci-dessous. Je soupçonne que je manque quelque chose de base ici. Je m'attendrais à ce que les deux images soient presque identiques.

Navigateur http://www.eleganttechnologies.com/outside/ImgDeviceBB9530WebGoogle.jpg

Écart téléphonique http://www.eleganttechnologies.com/outside/ImgDeviceBB9530PgGoogle.jpg

[Mise à jour] Pour faire la lumière sur ce qui se passe, j’ai exécuté le navigateur et le navigateur intégré (phonegap) contre le test d’acidité du Web mobile W3: http://www.w3.org/2008/06/mobile-test/ Je remarque certainement des différences entre les deux, mais je ne connais pas encore le "pourquoi" ni le "comment-adresser".

Acid via navigateur intégré
_{(source: eleganttechnologies.com )}
BTW - J'ai couru cela plus tôt aujourd'hui et j'ai eu un couple plus vert que maintenant.

Acide via un navigateur intégré à phonegap http://www.eleganttechnologies.com/outside/ImgDeviceBb9530PgAcid.jpg

Answer 1

Clause de non-responsabilité: je ne connais rien à Phonegap, mais j’ai une très bonne théorie. Par défaut, le contrôle de navigateur intégré sur BlackBerry utilise une version du moteur de rendu plus ancienne que le navigateur BlackBerry lui-même.

Lors de la conférence des développeurs BlackBerry l'année dernière, une discussion a eu lieu à ce sujet et il existe une option non documentée permettant d'utiliser le moteur de rendu plus récent. \

L'ID d'option est 17000 (oui, un nombre magique, qui pourrait changer, utilisez-le à vos risques et périls, etc.), et doit être défini sur true. Vous ne savez pas comment passer par cette option via Phonegap (je ne connais pas bien la boîte à outils), mais utiliser les API BlackBerry est un peu comme ceci:

BrowserContent content;
...
content.getRenderingOptions().setProperty(RenderingOptions.CORE_OPTIONS_GUID, 17000, true);

Answer 2

Je ne connais pas les spécificités des navigateurs que vous utilisez, mais je sais que la plupart des grands sites détecteront votre combinaison de navigateur OS + navigateur pour décider du code HTML à afficher.

Si Google rencontre un autre agent utilisateur, vous pouvez obtenir une version mobile générique du code HTML au lieu du code HTML spécifique au Blackberry que vous obtenez pour le navigateur intégré.

Si vous avez accès à un serveur Web, essayez de le frapper avec les deux configurations du navigateur et voyez s’il existe une différence dans le fichier journal. Cela pourrait vous dire quelque chose d'intéressant.

Answer 3

Comme on peut le voir dans vos tests Acid ...

L'un des navigateurs (le navigateur intégré) signale correctement un BlackBerry9530 et l'autre (phonegap) ne présente pas l'agent utilisateur ["Test avec."]. Dans ce cas, Google vous fournit la vue par défaut de sa page d'accueil, alors que lorsque vous vous signalez comme un terminal BlackBerry, vous obtenez le rendu spécifique à BlackBerry.

À proprement parler, phonegap supprime l’agent utilisateur par défaut (probablement parce qu’il ne reconnaît pas votre appareil). Puisque phonegap est une source ouverte, le mieux est d’y entrer, de la déboguer et de savoir ce qui se passe avec l’agent utilisateur lorsque les requêtes http quittent l’appareil et en suivent le suivi.

Answer 4

Peut-être qu'un navigateur a des fonctionnalités que l'autre ne possède pas?

Answer 5

Hm. En regardant la capture d'écran, je dirais que la deuxième page manque probablement des ressources. Il manque peut-être des images, des scripts et les fichiers CSS, ce qui expliquerait les différences de l & amp; f. Connaissant le fonctionnement de l’API Blackberry Browser Field, j’imagine que l’implémentation qui utilise BrowserField n’a pas été effectuée correctement. Juste ma conjecture. De plus, lorsque le champ du navigateur est initialisé, l'appelant doit le configurer correctement en activant les fonctionnalités appropriées du navigateur (scripts, styles, etc.). Une fois encore, l'API est conçue de manière très étrange. Je me suis entraîné une fois dans ce piège. . Lorsque vous définissez les options, vous ne pouvez pas créer un seul masque (comme CSS | WML | SCRIPT) et passer un appel. Les options sont numériques et, je crois, ne se chevauchent pas - mais vous devez toujours appeler l'API pour définir chaque option indépendamment.

Il faut également du temps pour comprendre le chargement asynchrone des ressources pour BrowserField.

Seulement mes 0,02 $.