Vraiment, vraiment grand UIScrollViews

Question

J'essaye de faire un graphique linéaire de niveau de détail, où l'utilisateur peut zoomer horizontalement en utilisant deux doigts, et développer l'attribut contentSize du champ UIScrollView. Ils peuvent également faire défiler horizontalement pour décaler vers la gauche ou la droite et voir plus du graphique (vérifiez n'importe quel stock sur les graphiques Google Finance pour avoir une idée de ce dont je parle). Potentiellement, la vue de défilement pourrait atteindre jusqu'à 100 fois sa taille d'origine, lorsque l'utilisateur zoome.

Mes questions sont: - Quelqu'un at-il eu une expérience avec UIScrollViews qui ont de telles restrictions de taille de contenu? Est-ce que ça marchera? - L'affichage de la vue défilante peut potentiellement être énorme, puisque l'utilisateur effectue un zoom avant. Comment cela est-il géré en mémoire?
- Juste une idée, mais serait-il possible d'utiliser UITableViewCells, orienté pour faire défiler horizontalement, pour entrer/sortir les données?

Ceci est une sorte de question ouverte en ce moment - je suis encore en train de faire un brainstorming. Si quelqu'un a des idées ou a déjà mis en œuvre une telle chose, veuillez répondre avec votre expérience. Merci!

Answer 1

J'ai quelque chose de similaire, mais probablement pas à la taille de votre parler. L'UIScrollView n'est pas un problème. Le problème est que si vous dessinez UIViews dessus (plutôt que de tracer des lignes vous-même) UIViews qui sont bien, bien à l'écran continuent d'exister en mémoire. Si vous dessinez réellement les lignes en créant votre propre UIView et en répondant à drawRect, tout va bien. En supposant que vous êtes un programmeur raisonnablement expérimenté, obtenir une grande vue de défilement qui dessine des parties du graphique est seulement une journée de travail, donc ma recommandation serait de créer un prototype pour cela, et exécuter le prototype sous la outil d'allocations d'objets et voir si cela indique des problèmes. Désolé pour l'imprécision de ma réponse; c'est une question de brainstorming

Answer 2

Ceci est un sujet assez ancien, mais je veux quand même partager quelques unes de mes expériences. L'utilisation d'un tel UIView (100 fois supérieur à sa taille d'origine) dans UIScrollView peut entraîner un avertissement de la mémoire. Vous devriez éviter de rendre tout le UIView en même temps. Une meilleure façon de l'implémenter est de rendre la seule zone que vous pouvez voir et la zone qui l'entoure. Ainsi, UIViewScroll peut défiler en douceur dans cette zone. Mais que faire si l'utilisateur a fait défiler hors de la zone qui a été rendue? Utilisez le délégué pour recevoir une notification lorsque l'utilisateur fait défiler la zone pré-rendue et essaie de restituer la nouvelle zone qui va être affichée. L'idée de base de cette implémentation est d'utiliser 9 UIViews (ou plus) pour mosaïquer une zone plus grande, lorsque l'utilisateur a fait défiler (ou s'est déplacé) de l'ancienne position à la nouvelle position. Il suffit de déplacer certains UIViews vers un nouvel emplacement pour vous assurer que l'un des UIView est la vue principale que vous pouvez voir principalement, et que 8 autres UIViews sont juste autour d'elle. J'espère que c'est utile.

Answer 3

Mais encore, cette approche (dans l'exemple ci-dessus) n'est pas assez bonne dans certains cas. Parce que nous avons seulement rendu une zone limitée dans l'UIScrollView.

L'utilisateur peut utiliser différents gestes dans UIScrollView: glisser ou lancer. Avec le glisser, les 8 petits UIViews pré-rendus suffisent pour couvrir la zone de défilement dans la plupart des cas. Mais en lançant, UIScrollView peut défiler sur une très grande zone lorsque l'utilisateur fait un mouvement rapide, et cette zone est totalement vide (parce que nous ne l'avons pas rendu) pendant le défilement. Même nous pouvons afficher le bon contenu après que UIScrollView arrête de défiler, le blanc pendant le défilement n'est pas très convivial pour l'utilisateur.

Pour certaines applications, c'est Ok, par exemple Google map. Puisque les données n'ont pas pu être téléchargées immédiatement. Attendre avant de télécharger est raisonnable.Mais si les données sont locales, nous devrions éliminer autant que possible cette zone vide. Donc, pré-rendre la zone qui va être défilée est cruciale. Contrairement à UITableView, UIScrollView n'a pas la capacité de nous dire quelle cellule va être affichée et quelle cellule va être recyclée. Donc, nous devons le faire nous-mêmes. La méthode [UIScrollViewDelegate scrollViewWillEndDragging: withVelocity: targetContentOffset:] sera appelée quand UIScrollView commencera à décélérer (en fait, scrollViewWillBeginDecelerating est la méthode appelée avant la décélération, mais dans cette méthode nous ne connaissons pas les informations sur le contenu qui sera affiché ou défilé) . Donc, basé sur UIScrollView.contentOffset.x et le paramètre targetContentOffset, nous pouvons savoir exactement où UIScrollView démarre et où s'arrête UIScrollView, puis pré-rendre cette zone pour rendre le défilement plus fluide.