WWDC 2016 : Quoi de neuf pour les CollectionView ?

WWDC 2016 CollectionViewComme chaque année, au mois de juin, se déroule la grande conférence d’Apple qui cible principalement les annonces pour les développeurs, la WWDC.

La keynote a montré nombre de nouveautés, notamment iOS 10, le changement de nom d’OS X vers Mac OS et sa nouvelle version, etc. Si iOS 10 apporte peu de changements côté design, du côté des développeurs cela va changer beaucoup de choses : nouvelle version de Swift, nouvelles APIs (Siri, Messages, etc.), autant de points qui offrent de nouvelles possibilités de jeux et d’applications sur iOS.

Si les conférences techniques de la WWDC s’axent sur le langage Swift, elles sont également intéressantes pour un développeur Xamarin, car certaines présentent des APIs ou nouveautés graphiques qui seront également disponible pour Xamarin.iOS peu après la sortie officile d’iOS 10.

La question de la CollectionView est un sujet récurrent lors du développement d’applications iOS, et une présentation lui a été dédiée pour montrer les améliorations et nouveautés dont elle va bénéficier.

Le scroll et ses performances

La première problématique abordée est celle du scroll dans une CollectionView. En effet, si globalement les performances sont plus que correctes, ce n’était pas assez pour les développeurs chez Apple.

Pour rappel, voici comment se décompose le cycle de vie d’une cellule d’une collection ou d’une table sous iOS 9 et versions antérieures :

  1. Lors d’un scroll, et qu’une nouvelle cellule est requise à l’affichage, cette cellule est sortie de la queue de réutilisation (« reuse queue »), et l’appel à la méthode PrepareForReuse permet de réinitialiser le template de la cellule à son état initial, pour qu’elle puisse recevoir de la nouvelle donnée
  2. La méthode CellForItemAtIndexPath est appelée. C’est ici que la cellule sera peuplée avec de la donnée ou configurée en fonction du besoin
  3. Juste avant que la cellule apparaisse à l’écran, la méthode WillDisplayCell est appelée, et c’est dans celle-ci que doivent être fait les derniers traitements avant l’affichage
  4. Enfin, lorsque la cellule disparait de la zone visible par l’utilisateur, la méthode DidEndDisplayingCell est appelée

Le renouveau du cycle de vie

Avec iOS 10, les étapes sont identiques, mais le timing d’appel aux méthodes citées précédemment diffère :

  1. Quand on scroll, la cellule dans la reuse queue est récupérée bien avant qu’elle n’ait besoin d’être affichée, et s’en suit l’appel à la méthode PrepareForReuse
  2. Pas de changement du côté de l’appel à la méthode CellForItemAtIndexPath
  3. Petite différence de timing sur la méthode WillDisplayCell, puisque celle-ci est appelée pile au moment où la cellule commence à apparaitre
  4. DidEndDisplayingCell est appelée lorsque la cellule va disparaître de l’écran. Ici la différence avec les versions antérieures d’iOS est que jusqu’à présent, à ce stade la cellule retourne dans la reuse queue, et si elle a besoin d’être réaffichée, il faut repasser par tout le process (CellForItem, WillDisplayCell). Avec iOS 10, seule la méthode WillDisplayCell sera rappelée.

La différence entre les enchainements ne sont pas flagrants lorsqu’ils sont décris tels quels, mais en démonstration on remarque une différence de fluidité lors d’un scroll rapide et relativement long.

CollectionView iOS Cell LifecycleDans le cas d’une CollectionView avec plusieurs colonnes, iOS 10 va s’occuper pour chaque ligne de charger une cellule à la fois pour le PrepareForReuse et CellForItemAtIndexPath (voir image ci-dessus). En revanche la méthode WillDisplayCell est appelée en même temps pour chaque colonne de la ligne. Cela améliore également les performances lors d’un scroll plutôt rapide et permet un visuel plus fluide.

A noter que les changements apportés avec iOS 10 n’impactent pas le développement, puisque c’est uniquement côté API que le timing est géré.

Le Cell Pre-Fetching, autre nouveauté pour iOS 10

Cette fonctionnalité, activée par défaut sous iOS 10, permettra comme son nom l’indique de pré-charger, et ce en asynchrone, les données des cellules. Combinée au système de réutilisation de cellule amélioré pour cette nouvelle version, les performances lors du scroll n’en seront que plus bonnes, ce qui est une excellente nouvelle pour les développeurs.

Le Pre-Fetching sera disponible pour les CollectionView, mais aussi pour les TableView, et une ligne suffit pour la désactiver.

Afin de profiter au maximum des performances qu’offrent le Pre-Fetching, un ensemble de bonnes pratique seront à appliquer :

  • Il faudra centraliser tout le « contenu lourd » (création, remplissage de données, etc.) dans la méthode CellFormItemAtIndexPath. Il est en revanche important de savoir que cette méthoe peut préparer une cellule qui ne sera jamais affichée
  • A contrario, les méthodes WillDisplay et DidEndDisplay devront traiter peu de choses

Le cas des modèles couteux

Il est très fréquent lors du développement d’une application d’avoir des étapes couteuses en terme de performances, tels quel l’accès aux images, parsing ou décodage d’images ou encore l’accès à la DB. Pour ces cas-là, Apple propose une nouvelle API pour les collections et tables, qui complète le Delegate et le DataSource : le PreFetchingDataSource.

Ce protocole (sous Swift) possède deux méthodes : une qui va s’occuper de récupérer en asynchrone les données, une autre pour annuler en cas de basse priorité. L’astuce pour bien gérer ces deux méthodes dans l’exemple d’un scroll dans un sens puis dans l’autre : il faut utiliser la méthode cancelPreFecthingForItemsAt pour annuler le chargement des éléments qui ne seront pas affichés.

CollectionView prefetchingAPI

Grâce au Cell Pre-Fetching, associé au nouveau fonctionnement du cycle de vie d’une cellule sous iOS 10, le scroll dans une Collection ou une Table sera encore plus fluide qu’il ne l’est à présent.

L’auto resize des cellules améliorée pour iOS 10 (CollectionView)

L’API de taille auto-adaptable (« self-sizing ») pour une cellule est disponible depuis iOS 8 pour les TableView et CollectionView, et permet à une cellule d’adapter elle-même sa taille en fonction de son contenu. En donnant au départ une taille estimée, il est possible grâce à différentes méthodes comme par exemple AutoLayout de modifier au runtime cette taille selon le contenu de chaque cellule. Cette feature, très intéressante, rencontre tout de même un problème quand le développeur doit estimer la taille de la cellule.

Cette API va donc elle aussi voir son fonctionnement amélioré. Il sera possible sous iOS 10 d’avoir une estimation automatique de la taille de la cellule, grâce à cette propriété : layout.estimatedItemSize = UICollectionViewFlowLayoutAutomaticSize. Elle permet de déléguer le calcul de la taille de la cellule à la CollectionView, au lieu du développeur. Finalement, la taille estimée des cellules se fera en fonction de la taille réelle des cellules déjà générées. Elle pourra donc changer au fur et à mesure pour atteindre une taille la plus proche possible de ce qui est attendu visuellement.

Ce fonctionnement permet d’être plus précis par rapport au comportement attendu, mais offre aussi de meilleures performances lors de la construction de la collection.

La réorganisation de cellules interactive

Disponible depuis iOS 9, cette API permet de réordonner des éléments d’une CollectionView grâce au Drag&Drop, avec dans le cas des cellules à taille différente une adaptivité de la taille lors de la réorganisation.

Petit rappel sur cette fonctionnalité :CollectionView InteractiveReordering

  • Quatre méthodes permettent son utilisation et sa gestion
  • Dans le UICollectionViewController, il faut activer une variable: installStandardGestureForInteractiveMovement

La nouveauté sous iOS 10 sera le support du paging pour le déplacement dans une CollectionView. Cela apportera la même expérience utilisateur que sur la page Home de l’iPhone, lorsque des applications sont déplacées.

Le refresh control

En bonus, le UIRefreshControl sera maintenant directement supporté dans les CollectionView, TableView et ScrollView.

CollectionView RefreshControl

Conclusion

Nous avons pu voir au travers de cet article que les développeurs chez Apple sont très attachés à l’expérience utilisateur et cherchent à améliorer toujours plus les performances de leurs contrôles. L’exemple des nouveautés qui affecteront la CollectionView (mais aussi la TableView dans certains cas) promettent d’être très intéressantes, d’autant plus qu’elles ne présentent à priori pas de grandes modifications côté code. On dit souvent que les développeurs sont feignants, c’est donc ici une excellente nouvelle 🙂

image-463

Vivement la sortie d’iOS 10, et la disponibilité de ces APIs avec Xamarin !

Laisser un commentaire