Est-ce que la sous-vue codée en dur est trop fragile ou la meilleure pratique?

Question

Venant d'un arrière-plan web, où le dimensionnement explicite n'est généralement pas considéré comme la meilleure pratique, je ne suis pas habitué aux valeurs de positionnement «codées en dur».

Par exemple, est-il parfaitement acceptable de créer des UITableViewCells personnalisées avec des valeurs codées en dur pour les cadres et les limites des sous-vues? Il semble que lorsque l'utilisateur fait pivoter l'appareil, j'ai besoin d'un autre ensemble d'images/limites codées en dur. Si Apple décide de sortir une TABLETTE plus grande ... alors j'ai besoin d'encore une autre mise à jour du code - cela me semble étrange car cela ne semble pas bien évoluer.

Dans mon cas spécifique, j'aimerais utiliser une cellule de style UITableViewCellStyleValue2 mais j'ai besoin d'un UITextField à la place de detailTextLabel. Je déteste écrire complètement mon UITableViewCell mais il semble que dans la plupart des exemples de saisie de texte que j'ai trouvés, les gens créent leurs propres cellules et valeurs de dimensionnement codées en dur. Si c'est le cas, y a-t-il un moyen de respecter le positionnement et le dimensionnement prédéfinis des styles textLabel et detailTextLabel mentionnés ci-dessus (ie: je souhaite remplacer ou superposer mon UITextField à la place de detailTextLabel mais est-ce que tout le positionnement de subview reste intact)? Juste après avoir créé une cellule par défaut, cell.textLabel.frame retourne 0, donc je suppose qu'il ne sera pas dimensionné tant que la disposition de la cellule ne sera pas invoquée ... et évidemment, c'est trop tard pour ce que je dois faire.

Espérons que cette question a du sens. Je cherche juste la 'meilleure pratique' ici.

-Luther

Answer 1

Il n'y a pas de bonnes pratiques. Cela dépend de votre application. Vous pouvez utiliser IB pour effectuer un redimensionnement dynamique avec autorotation. Et définissez les propriétés pour modifier sizeOfFit, etc.

Vous pouvez également définir le cadre de n'importe quelle vue avant layoutSubViews en créant une vue et en l'initialisant avec CGRect.

Il y a beaucoup de flexibilité. J'ai tendance à faire les choses statiques dans IB et le reste dans le code.

Answer 2

En général, il est une mauvaise idée de coder ces valeurs parce que le contenu se déplaceront en fonction:

• Qu'il y ait une image dans la cellule
• mode Edit
• mode Supprimer
• Move (réorganiser) mode
• Quel type d'accessoireAfficher (le cas échéant) est affiché
• Rotation
• tailles d'écran
• etc.

Si vous utilisez les styles par défaut la plupart d'entre eux seront obtenir pris en charge, mais si vous utilisez des cellules personnalisées alors vous devrez vérifier les différents modes et ajuster la position et la taille en conséquence.

Si vous y parvenez, vous devez remplacer layoutSubviews dans la sous-classe UITableViewCell. Une approche consiste à avoir pour chaque sous-vue une méthode {subView}Frame qui renvoie un CGRect. Dans chaque méthode, vous pouvez tester la condition que vous recherchez et retourner un CGRect chargé avec la bonne position (idéalement, il sera calculé proportionnellement au lieu de absolu).

Alors votre layoutSubviews ressemblerait à quelque chose comme ceci:

- (void)layoutSubviews { 
    [super layoutSubviews]; 

    [subView1 setFrame:[self subView1Frame]]; 
    [subView2 setFrame:[self subView2Frame]]; 
    [subView3 setFrame:[self subView3Frame]]; 
    ... 
}