Cocoa Autolayout: étreinte de contenu vs priorité de résistance à la compression de contenu

Je ne trouve pas de réponse claire sur la documentation d'Apple concernant Cocoa Autolayout concernant la différence entre l'étirement du contenu et la résistance à la compression.

Quelqu'un peut-il expliquer ses usages et sa différence?

Un bref résumé des concepts:

• Étreindre => le contenu ne veut pas grandir
• Résistance à la compression => le contenu ne veut pas rétrécir

Exemple:

Disons que vous avez un bouton comme celui-ci:

[       Click Me      ]

et vous avez épinglé les bords à une vue d'ensemble plus grande avec la priorité 500.

Ensuite, si la priorité à l'étreinte> 500, cela ressemblera à ceci:

[Click Me]

Si la priorité à l'étreinte <500, cela ressemblera à ceci:

[       Click Me      ]

Si la vue d'ensemble rétrécit maintenant, si la priorité de résistance à la compression> 500, cela ressemblera à ceci

[Click Me]

Sinon, si la priorité à la résistance à la compression est <500, cela pourrait ressembler à ceci:

[Cli..]

Si cela ne fonctionne pas ainsi, vous avez probablement d'autres contraintes qui gâchent votre bon travail!

Par exemple, vous pouvez l'épingler à la vue d'ensemble avec la priorité 1000. Ou vous pouvez avoir une priorité de largeur. Si oui, cela peut être utile:

Editeur> Ajuster au contenu

Jetez un oeil à ce tutoriel vidéo sur Autolayout , ils l'expliquent soigneusement

source: @mokagio

Taille de contenu intrinsèque - assez explicite, mais les vues avec un contenu variable sont conscientes de la taille de leur contenu et décrivent la taille de leur contenu via cette propriété. UIImageViews, UILabels, UIButtons sont des exemples évidents de vues qui ont des tailles de contenu intrinsèques.

Content Hugging Priority - Plus cette priorité est élevée, plus une vue résiste à devenir plus grande que sa taille de contenu intrinsèque.

Priorité de résistance à la compression du contenu - Plus cette priorité est élevée, plus une vue résiste à rétrécir plus petite que sa taille de contenu intrinsèque.

Cochez ici pour plus d'explications: MAGIE DE MISE EN PAGE AUTOMATIQUE: PRIORITÉS DE TAILLE DU CONTENU

Disons que vous avez un bouton avec le texte "Click Me". Quelle largeur doit avoir ce bouton?

Tout d'abord, vous ne voulez certainement pas que le bouton soit plus petit que le texte. Sinon, le texte serait tronqué. Il s'agit de la priorité de résistance à la compression horizontale.

Deuxièmement, vous ne voulez pas que le bouton soit plus grand qu'il ne devrait l'être. Un bouton qui ressemblait à ceci, [Click Me], est évidemment trop gros. Vous voulez que le bouton "embrasse" son contenu sans trop de remplissage. Il s'agit de la priorité d'élargissement du contenu horizontal. Pour un bouton, il n'est pas aussi fort que la priorité de résistance à la compression horizontale.

Si view.intrinsicContentSize.width != NSViewNoIntrinsicMetric, la mise en page automatique crée une contrainte de type spéciale NSContentSizeLayoutConstraint. Cette contrainte agit comme deux contraintes normales:

• une contrainte nécessitant view.width <= view.intrinsicContentSize.widthavec la priorité de calage horizontal, et
• une contrainte nécessitant view.width >= view.intrinsicContentSize.widthavec la priorité de résistance à la compression horizontale.

Dans Swift, avec les nouvelles ancres de mise en page d'iOS 9, vous pouvez configurer des contraintes équivalentes comme ceci:

let horizontalHugging = view.widthAnchor.constraint(
    lessThanOrEqualToConstant: view.intrinsicContentSize.width)
horizontalHugging.priority = view.contentHuggingPriority(for: .horizontal)

let horizontalCompression = view.widthAnchor.constraint(
    greaterThanOrEqualToConstant: view.intrinsicContentSize.width)
horizontalCompression.priority = view.contentCompressionResistancePriority(for: .horizontal)

De même, si view.intrinsicContentSize.height != NSViewNoIntrinsicMetric, la mise en page automatique crée un NSContentSizeLayoutConstraintqui agit comme deux contraintes sur la hauteur de la vue. Dans le code, ils ressembleraient à ceci:

let verticalHugging = view.heightAnchor.constraint(
    lessThanOrEqualToConstant: view.intrinsicContentSize.height)
verticalHugging.priority = view.contentHuggingPriority(for: .vertical)

let verticalCompression = view.heightAnchor.constraint(
    greaterThanOrEqualToConstant: view.intrinsicContentSize.height)
verticalCompression.priority = view.contentCompressionResistancePriority(for: .vertical)

Vous pouvez voir ces NSContentSizeLayoutConstraintinstances spéciales (si elles existent) en imprimant view.constraintsaprès l'exécution de la mise en page. Exemple:

label.constraints.forEach { print($0) }

// Output:
<NSContentSizeLayoutConstraint:0x7fd82982af90 H:[UILabel:0x7fd82980e5e0'Hello'(39)] Hug:250 CompressionResistance:750>
<NSContentSizeLayoutConstraint:0x7fd82982b4f0 V:[UILabel:0x7fd82980e5e0'Hello'(21)] Hug:250 CompressionResistance:750>

Les priorités de contention de contenu et de compression de contenu fonctionnent pour les éléments qui peuvent calculer leur taille intrinsèquement en fonction du contenu entrant.

Depuis les documents Apple :

C'est Content hugging prioritycomme un élastique qui est placé autour d'une vue. Plus la valeur de priorité est élevée, plus la bande élastique est forte et plus elle souhaite s'adapter à la taille de son contenu. La valeur de priorité peut être imaginée comme la "résistance" de l'élastique

Et Content Compression Resistancec'est à quel point une vue «résiste» à devenir plus petite La vue avec une valeur de priorité de résistance plus élevée est celle qui résistera à la compression.