Pouvoir mettre plus de 10 éléments dans une ScrollView

Bonjour,
Je suis en train de travailler sur une application dans la quelle il y a des cours pour un professeur dans un lycée, et je bloque sur le fait que je ne peut mettre plus de 10 éléments dans une ScrollView ( ou il y a ma liste de cours)

Et j’ai essayer de trouver des solutions mais les seules que j’ai trouver fonctionne avec des liste et des NavigationLink, mais mon souci c’est que j’utilise des bouton pour ouvrir une Sheet. Est que vous avez une solution à mon problème ? Merci d’avance pour vos réponses

Salut j’ai déjà eu le même soucis. Il faut enfermer des blocs dans des balises Group{
Ton code
}

Et du coup tu peux faire dix groupes
Si ça ne suffit pas, divise ta view en composant de type View. Et tu peux les imbriquer. On perd en lisibilité malheureusement mais c’est ainsi que SwiftUI est conçu.

Ok nickel merci beaucoup

Salut @rayan,

Pour faire ça normal tu utilises une List ou une Lazy Vertical Stack, car sinon tu vas utiliser trop de mémoire quand ta liste sera longue.

Donc, ce que tu as trouvé avec les List est juste, il faut seulement chercher comment faire pour enclencher une Sheet avec le bouton de chaque ligne.

Et ça, c’est un autre challenge que tu dois accomplir.

L’idée de @stod fonctionne, mais je ne la recommande pas, à cause de la mémoire utilisée.

1 « J'aime »

@ThonyF j’avais eu le soucis dans une liste perso il me semble que la limitation à 10 enfants statiques est valable pour tout les composants, à moins que j’ai loupé une news de SwiftUI 3.0, ou que je sois complètement dans l’erreur :wink:

@stod tu veux dire 10 éléments que tu écris manuellement ?

Si c’est ce que tu veux dire, alors oui peut être que c’est vrai, je n’ai jamais testé, car normalement quand c’est le même objet, on crée des éléments visuels flexibles aux données qu’ils reçoivent et l’on passe par une boucle.

Vois-y une vidéo (en anglais) qui montre l’impact des différentes méthodes sur la mémoire.

1 « J'aime »

Tout à fait, je regarderais la vidéo dès que j’ai un moment merci en tout cas

ScrollView c’est le Mal ! Il ne faut jamais l’utiliser dans une application. C’est un reliquat des premières versions d’iOS. A l’époque on n’avait pas le choix, mais de nos jours il y a d’autres composants graphiques bien plus efficace.

Le problème c’est la gestion mémoire et la réactivité. Le contenu graphique doit être entièrement défini avant la première utilisation, même si la portion visible à l’écran n’est qu’une petite partie du tout. Dessiner x éléments dans un espace graphique, alors que l’utilisateur n’en a qu’un ou deux sous le regard, c’est :

  • une grosse consommation de mémoire, ce qui est toujours une ressource critique sur un système mobile.
  • un risque non négligeable d’affichage saccadé, le temps que le système dessine l’image. Pour un affichage fluide, il faut que la construction graphique se fasse en moins de 16,6 ms (60 Hz = une nouvelle image toutes les 16,6 ms).

Les composants d’affichage plus récents comme List, Grid, Lazy Stack sont construits à partir de ScrollView, mais d’une manière optimisé en ne dessinant que les éléments nécessaires à l’affichage courant, ce qui économise l’empreinte mémoire de l’application et évite les rallentissements provoqué par des opérations graphiques trop longues.

3 « J'aime »

Il ya un moyen de contourner, c’est d’utiliser Group{ } qui te permets de regrouper plusieurs vues en une. Le compilateur évalue le Group en un fois, et ensuite, reprend la vue dans laquelle il est situé, le nombre de vue est ainsi diminué, le Group étant bien entendu une vue. Lui-même, comme toutes les vues parents dans SwiftUI, ne supporte pas plus de dix vues. Mais lui-même peut être emboîté dans un autre Group{ }. J’ai eu le problème avec douze vues distinctes, une pour chaque mois de l’année. Ça ne passait pas. J’ai dû faire deux groupes de six.

Dans ces cas-là, le compilateur envoie des messages gênés, exotiques, se plaint de différentes choses imprévisibles ayant peu à voir avec la limite qu’il ne repère pas comme à l’origine de sa difficulté, comme s’il avait honte. Mais en fait, ça oblige à bien réfléchir pour structurer ses vues, et en créer le plus petit nombre possible pour le résultat attendu.

Sachant que tout est View sous SwiftUI…

Je viens de la regarder :eyes:

C’était super intéressant merci beaucoup :blush:

1 « J'aime »