Je me lance dans une application de gestion de cave à vin, avec CoreData et CloudKit.
L’utilisateur pourra sélectionner des photos des bouteilles / des étiquettes, qui seront stockées en haute définition.
Dans l’affichage des bouteilles en mode liste, je vais naturellement présenter des images de taille réduite (thumbnails) pour accompagner le descriptif des vins.
La taille de ces thumbnails va dépendre de l’appareil sur lequel tourne l’application: sur un iPad, ou bien en mode paysage sur un grand iPhone, le thumbnail pourra être de taille bien supérieure que en mode portrait sur un iPhone SE.
Qu’est-il préférable de faire ? je vois trois possibilités:
créer et stocker dans CoreData et CloudKit un « gros » thumbnail qui servira dans tous les cas mais ne sera pas optimisé
générer un thumbnail « à la volée » à partir de l’image originale, au moment où l’application en a besoin. L’image sera toujours de la bonne taille, mais la fluidité de l’app risque d’en souffrir
générer localement, et stocker localement également des thumbnails optimisés pour chaque appareil: optimisation de la taille de l’image, bonne fluidité, mais plus compliqué à gérer pour le développement.
Si vous avez une recommandation ou un retour d’expérience, je suis preneur !
Tu veux renoncer à une possibilité parce qu’elle « risque » de ne pas être efficiente ?
Implémente là, et regarde ce que cela donne concrètement sur différents devices. Si c’est trop lent, passe à autre chose, mais y renoncer sans tester c’est Mal !
Je n’ai pas de retour d’expérience à t’offrir, mais d’un point de vue optimisation, j’opterai pour un mélange des 2 dernières propositions :
Générer et stocker des thumbnails en fonction de leur affichage dans ta liste (les x premiers), et en créer d’autres à la volée au fur et à mesure que l’utilisateur descendra dans sa liste. Ces dernières ne seront stockées que pendant la durée d’utilisation de l’application.
Pour fluidifier le tout, pas besoin d’attendre d’être au bout de la liste pour commencer à les générer. S’y prendre à partir du moment où l’utilisateur commence à faire défiler la liste.
Pour éviter les problèmes de fluidité, il ne faut pas effectuer les redimensionnement des images dans le thread principal (utilisé par iOS pour gérer l’interface), mais de manière asynchrone, dans des threads secondaires.
Il date un peu, mais le fond est là, il te permettra probablement d’étayer ton choix.
Concernant mon propre retour d’expérience, habituellement, j’utilise Image I/O qui a l’avantage d’être performant, automatiquement adapté au device et en plus d’avoir un cache. Bref, je n’ai jamais eu de soucis avec.
Question complémentaire: mon image en « full résolution » va donc être stockée par core data sous forme de « Binary Data », sachant que j’active naturellement l’option « Allows external Storage ».
Les différentes méthodes pour passer d’une image full size à un thumbnail nécessitent de passer en paramètre l’URL de l’image.
Cela voudrait donc dire que quand j’ai besoin de créer le thumbnail, je dois récupérer les données de l’image à partir de core data, copier l’image sur le disque, obtenir son URL, créer le thumbnail à partir de cet URL, puis supprimer la copie de l’image sur le disque.
Il n’y a pas plus simple ?
C’est quelque chose que je n 'ai jamais fait, mais j’ai des doutes sur la rapidité du processus, surtout dans une logique temps réel et peuplement d’une List.
Non, tu n’as pas forcément à passer par une URL. Par exemple dans l’exemple donné avec Image I/O dans l’article, au lieu de CGImageSourceCreateWithURL tu peux utiliser CGImageSourceCreateWithData.
@Draken C’est une idée, oui. Mais à mon avis, il faut commencer par une génération à la volée. Ensuite, identifier les éventuelles questions de performances, il se peut que cela soit négligeable, mais il n’y a qu’en le développement qu’on le sait.
J’ai fait mien un diction que je ressors très souvent « Early optimization is evil » ! En gros, on optimise quand on tombe sur un problème, pas quand on réfléchit et qu’on se dit qu’il y en aura un… Car bien souvent, le problème n’est pas là où on y avait pensé, voire, pas là du tout… C’est donc un bon moyen, pragmatique, de ne pas sur-complexifier inutilement des traitements.
