ligne Ipad sur l'écran lors du défilement

iPad et un seul doigt Défilement dans flexmls

par Nick le 13 Avril 2011

Le post d'aujourd'hui est de Nick Larson, l'un des stagiaires de développement web de FBS qui a été chargé de faire l'iPad compatible avec flexmls. Il décrit les détails techniques ci-dessous comment il a mis en œuvre le défilement sur l'iPad dans les flexmls.

-Greg Kilwein

iPad: un seul doigt IFrame Scrolling

Lorsque nous avons commencé à tester l'iPad pour la compatibilité avec flexmls, un problème majeur est que le défilement ne fonctionne pas dans de nombreux endroits de base au sein de flexmls. Par défaut sur l'iPad, non seulement ne défilement d'un div nécessite deux doigts au lieu d'un seul doigt, mais les iframes ne sont pas en mesure de faire défiler à tous. L'objectif était de fournir seul doigt défilement chaque fois que possible.

Heureusement, l'iPad nous offre un grand construit dans les événements tactiles que nous pouvons utiliser pour commencer à résoudre le problème. En utilisant quelques-uns des événements, touchstart et touchmove spécifiquement. nous sommes en mesure de créer une fonction simple qui peut prendre soin de initialisant un seul doigt de défilement sur un div ou un autre élément de défilement en dehors de iframes (nous en parlerons plus tard iframes). Les bonnes nouvelles est que cela est assez cross-browser compatible, même parmi les navigateurs tactiles capables. Je l'ai testé sur les navigateurs mobiles un couple, et il semble même de travailler avec Internet Explorer sur Windows Phone 7! Ainsi, grâce à venir à travers quelques ressources utiles, je suis venu avec ceci:

Ce que je pensais initialement allait être un énorme projet, a fini par être une solution simple grâce à la construction dans les événements tactiles et un peu de recherche.

Passons maintenant à la partie difficile, les iframes. flexmls repose sur iframes pour afficher une grande partie du contenu vu dans tout le système. Le problème avec l'iPad est qu'il ne joue pas bien avec des cadres du tout.

Pour une raison quelconque l'iPad ne respecte pas leur valeur de hauteur. Au lieu de garder la hauteur désirée et permettant le défilement, l'iPad étend simplement le iframe verticalement pour accueillir tout le contenu. Je me sens comme cela pourrait être un bug avec l'iPad, ou quelque chose qu'ils ne sont pas anticiper. De toute façon, nous avions besoin d'une solution.

Tout de suite je pensais simplement envelopper un div autour de lui et l'utiliser div pour le défilement. Cependant, cela ne fonctionne pas. Le problème avec cela est lorsque la fonction initMobileScroll est appliquée à l'iframe et essayer de faire défiler, l'iframe capture seulement les événements tactiles au lieu de la div. Eh bien, après réflexion, j'ai pu avec deux méthodes.

La première méthode, «version 1», consiste à placer une div en position absolue sur l'iframe de sorte que les événements tactiles restent dans le cadre de la même fenêtre et ne se coincent pas par le iframe. Le seul problème avec cette méthode est qu'elle rend tout dans le iframe unclickable (comme des liens). Cette option ressemblerait à quelque chose comme ceci:

Eh bien c'est une option décente, mais si les utilisateurs doivent être en mesure de cliquer sur les choses dans l'iframe? La deuxième méthode, «version 2», traite de cette question. Bien qu'il exige que le contenu encadrée être hébergé sur le même domaine que le document parent, il fonctionne vraiment.

Ce que nous pouvons faire est tout simplement garder le iframe caché et utiliser la propriété "innerHTML" pour tirer le contenu de l'iframe après il est chargé. On peut alors placer le contenu dans une div, et appliquer notre défilement mobile à la div au lieu de l'iframe.

Cette méthode ressemblerait à quelque chose comme ce qui suit:

C'est à peu près ça. Tout en prenant le contenu de l'iframe cachée et en le jetant à un div, qui se comporte beaucoup mieux sur un iPad. Maintenant, chaque fois la source de l'iframe est modifiée, la div rechargera automatiquement avec le nouveau contenu! Une chose à noter est que innerHTML ne fonctionne que lorsque le contenu de l'iframe est hébergé sur le même domaine. Si ce n'est pas, le navigateur va bloquer la tentative.

J'espère que cela donne un aperçu sur la façon d'accomplir le défilement sur l'iPad.

L'expansion des iframes est par conception. Je pense que scrolling = "no" sera le désactiver, mais je ne suis pas sûr si vous serez alors en mesure de faire défiler le contenu de JS.

Mais ceci est un grand bon début pour moi. Merci

Nick 20 Juin 2011 à 07:46

Merci! Vous pouvez toujours essayer d'ajouter un multiplicateur à touchMovedY et touchMovedX. Je ne sais pas si cela se sentir naturel ou non lors du défilement, mais ce serait la peine d'essayer.

Je crois que je manque quelque chose ici.

Je besoin d'un iFrame pour héberger mon contenu principal sur un iPad (et tout autre «grand écran») en raison de la «glissement contenu page change commun à l'iPhone - diapositive de droite avec toboggan simultanée sur à gauche par exemple. Dans ce cas, une balise 'div' ne parvient pas à masquer le contenu coulissant en montrant entièrement les deux pages entrantes et sortantes, côte à côte, comme ils glissent en place. Pas un bon look.

Je suis donc retourné à mon modèle iFrame vieux, développé à l'origine pour le flash overlay HTML affiche le contenu. Le iFrame 'masques' the the de contenu coulissant afficher une seule page vue comme prévu. Ces pages de contenu sont conçus avec un en-tête et pied de page fixe en haut à l'intérieur et en bas de l'écran iFrame, et une étiquette «div» avec le contenu scrollable entre - mon intention exacte souhaitée.

Ce scroller est seul doigt défilante, le contenu est sélectionnable et la page est swipe-mesure aussi bien.

Donc, je trouve le poste ci-dessus un peu perplexe. Pour moi, la balise 'div' est / était pas une solution viable. Mais l'iFrame est parfait et semble fonctionner très bien dans mes tests limités. (Note: J'ai un peu plus javascript que ceux énumérés ci-dessus.)

Nick 7 Septembre 2011 à 10:45

C'est intéressant. Dernière, je regardais, les gens ont été avoir une tonne de problèmes avec les iframes et le défilement sur l'iPad. A moins que l'une des nouvelles versions de ios a depuis fixé certains des problèmes. Dans ce cas, impressionnant! Il suffit de faire une recherche Google de "iframes ipad" vous remplissez sur certains des problèmes que j'ai eu affaire à.

michael 7 Septembre 2011 à 00:10

«Une chose à noter est que innerHTML ne fonctionne que lorsque le contenu de l'iframe est hébergé sur le même domaine. Si ce n'est pas, le navigateur va bloquer la tentative. "

pas sûr de ce que cela signifie - le contenu affiché dans le iFrame doit résider sur le même serveur que le site Web sur lequel l'iframe est affiché? Si tel est le cas, il serait contraire à l'objectif majeur de iFrames, y compris dans un site Web: y compris le contenu hébergé là.

Merci de clarifier

Nick 7 Septembre 2011 à 10:29

C'est correct, le contenu doit être sur le même serveur en raison de la politique de même origine (en.wikipedia / wiki / Same_origin_policy).

Dans notre cas, nous avons utilisé principalement iframes dans le passé pour afficher différentes caractéristiques / éléments / etc. sur une page plutôt que le contenu d'un autre domaine. La page Wikipedia sur l'élément iframe a une assez bonne explication de la raison pour laquelle nous avons d'abord choisi de les utiliser: en.wikipedia / wiki / HTML_element # Cadres

Cependant, maintenant qu'il ya beaucoup meilleur soutien pour les demandes de XMLHTTP (sous forme de ajax), la plupart (sinon la totalité) de ces situations que nous avons courons pour peut être évitée.

Salut à tous. J'ai oublié ce post, désolé.

Aussi j'utilise iScroll de Cubiq 4 actuellement pour le défilement du contenu. Cela permet à un en-tête et pied de page fixe tout en faisant défiler le contenu; fondamentalement tout ce qu'il fallait. Quoi qu'il en soit, voici un lien vers une version dénudée du scroller dans un récipient tondue (pas iFrame). Il est conçu (un travail en cours tout à l'heure) sur quoi que ce soit - navigateurs, ipad, iphone, etc. L'iPhone est trop petit pour le conteneur disparaît.

Celui-ci utilise jQuery comme base du code cross-navigateur et également utilisé le contrôleur JavaScriptMVC en tant que gestionnaire "widget". Sur l'exemple, les boutons et tous ne fonctionnent pas; il est pour la démo de scroller seulement. Le scroller fonctionne comme un rêve.

(Le texte de l'or en haut est un journal de débogage actif.)

Est-ce que l'utilisation de innerHTML fonctionne, si certains contenus sont dynamiquement créés par javascripts et que les gestionnaires d'événements ont également été fixés dynamiquement aux éléments?