Discussion :

[aso14]

Bonjour à tous !
Je me suis lancé dans le projet de créer une liste de Frame, dynamiquement. Les frames seront créés dans un TVertScrollBox qui sera donc le parent de mes TFrames. Je pourrais ainsi ajouter sur mes TFrames créés dynamiquement des composants enfants (TImage,TLabel...). Le problème ne se situe pas principalement au niveau de la création de mes TFrames. Mais au niveau de la mémoire. Je redoute que la création de 500 Frames dynamiquement avec ses enfants, ne puisse consommé trop de mémoire sur mon téléphone Android.

1- Comment donc faire pour éviter une surconsommation de la mémoire avec la création de TFrame illimité ?
2- Comment éviter les mauvaise rafraichissement lors du défilement des TFrames et de ses composants.

PS :
- TFrame stock principalement des images qui seront chargés elles aussi dynamiquement depuis une base de donnée.
- Application est multiplateforme et doit tourné sur Android principalement et Windows.

[pprem]

Pas vraiment de solution : plus on crée des objets, plus on consomme de la mémoire. C'est la base de la programmation.

Pour éviter de saturer, il faut recycler.

Si en plus on a des images en quantité il est vital de les dégager dès que possible.

Quand des éléments ne sont pas affichés à l'écran il faudrait soit les réutiliser, soit les éliminer. Idéalement il serait pratique de n'avoir que le nombre de cadres nécessaires à l'affichage +1 (selon la vitesse d'affichage, de chargement des données censées être traitées, la hauteur de chaque élément, etc). Quand l'un d'eux est au dessus ou en dessous de l'écran, on l'alimente avec les infos censées être de l'autre côté et on le déplace. C'est plus une programmation économe qu'on retrouve dans le développement de jeux vidéo que dans les applications bureautiques, mais ça n'empêche pas de l'implémenter quand on fait tout à la main.

[aso14]

Merci beaucoup M. Patrick !!! En effet je veux mettre en place un système de cardview comme le fait l'application Android FacebooK. La particularité du mien est qu'il doit être entièrement personnalisable en UI.
https://cdn.dribbble.com/users/13348...esize=1200x900

[Paul TOTH]

oui l'idée c'est de ne pas tout avoir en mémoire en effet

même s'il n'est pas nécessaire de se limiter à ce qui est visible + 1, ça peut être une 20ène, une 50ène ... bref un nombre fixe, et quand on scroll, on vient placer ces éléments à une position adaptée et remplir les champs avec les données de l'enregistrement en question...c'est d'autant plus simple à faire si la frame est de taille fixe....mais sinon ça reste faisable.

l'autre approche, que j'ai tendance à utiliser sous VCL, c'est de dessiner manuellement les éléments sans passer par des composants.

ça me fait penser à libPDFium, dans le reader j'ai la taille de toutes les pages, et une procédure LoadVisiblesPages qui s'assure que les pages visibles à l'écran sont accessibles, et pour gérer leur durée de vie, je considère que si une page est invisible depuis plus de 5 affichages, elle peut être supprimée. Dans le Paint je regarde si ce qui est visible à changé et je lance le dessin des pages visibles. Donc potentiellement le PDF peut contenir des centaines de pages, seules les quelques pages qui ont été affichées récemment sont en mémoire.

Là c'est la DLL qui dessine les pages, mais j'ai une classe TPDFPage qui peut correspondre à ta Frame.

[aso14]

Cela me ferait beaucoup plaisir M. Paul ! Est-ce que je peux l'utiliser en FMX, c'est en effet pour une application Android que j'aimerais le développer. Néanmoins si cela nécessite une adaptation c'est pas de refus.

PS : Si vous pouvez nous apprendre le principe cela serait encore plus cool !!
Merci pour vos réponses.