Human Interface Guidelines
Bonjour à tous,
Je suis à la recherche des valeurs recommandées à utiliser pour la taille (la hauteur) des différentes barres (navigation, tool...). J'ai trouvé les tailles que recommande la pomme dans les guidlines officiels pour les icônes que l'on place à l'intérieur mais rien sur les barres en elles-mêmes. Existe-t-il une norme les concernant ? Si oui, où les trouver ?
Pour information je construis mes IHM via du code Swift. Donc pas la peine de me répondre "garde les valeurs par défauts de xib). :-p
Merci pour votre aide !
Je suis à la recherche des valeurs recommandées à utiliser pour la taille (la hauteur) des différentes barres (navigation, tool...). J'ai trouvé les tailles que recommande la pomme dans les guidlines officiels pour les icônes que l'on place à l'intérieur mais rien sur les barres en elles-mêmes. Existe-t-il une norme les concernant ? Si oui, où les trouver ?
Pour information je construis mes IHM via du code Swift. Donc pas la peine de me répondre "garde les valeurs par défauts de xib). :-p
Merci pour votre aide !
Mots clés:
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
Pour suivre le conseils pour configurer une vue de telle façon que elle s'adapte correctement en rotation ou sur les différents tailles d'écran, il faut utiliser l'autolayout, dont c'est fortement déconseillé de spécifier les tailles des composants ; seulement les contraintes entre les composants.
La plupart des composants a un "intrinsic size" et, si tu l'ignores, tu auras les erreurs de conflits entre les contraintes. Et, en plus, qu'est-ce qui arrive quand l'utilisateur fait une rotation, ou il utilise le mode "split-screen" sur le grand iPad Pro ?
Pourquoi tu insistes de te battre autour la tête en faisant l'agencement en code ?
C'est un dinosaure allergique à Storyboard, un peu comme moi avant la Divine Révélation !
Mais tu crées des navigation bar en utilisant des UIView ou en utilisation des UINavigationController? Car il me semble que leurs inits leur donne les tailles classiques.
Où ai-je dit que je n'utilisais pas les Autolayout ? C'est bien mignon de vouloir ouvrir un débat sur un autre sujet (tu aurais pu aussi parler de l'état islamique, ça aurait été la même) mais ça ne répond pas à la question qui était : Existe-t-il une norme les concernant ? Si oui, où les trouver ?
De plus la hauteur (en pts) d'une UIToolBar est exactement la même sur un iPad mini que le Pro 12" (de mémoire 44 pts d'après Interface Builder). Bref passons...
Je t'invite à consulter ce post, tu en seras grandement rassurée.
Me battre ? Bref passons... (x2) ???
1 - Je trouve xib trop lourd (il est vrai que j'ai loin d'avoir un MBP dernière génération)
2 - Dans un contexte où tu travailles à plusieurs sur un projet (via Git) va faire un merge quand tu as un conflit sur le code généré par xib... C'est largement plus simple quand tu passe par du code Objective-C / Swift
3 - Je trouve qu'il est plus simple de faire évoluer simplement ton IHM via du code que par xib (mais je peux me tromper)
4 - Va créer ta propre barre de progression / d'attente sur xib
5 - L'utilisation du caractère "!" dans la déclaration des IBOutlet (oui je me l'interdis purement et simplement j'essaie de l'utiliser le moins possible)
Sur ce dernier point j'ai d'ailleurs toujours trouvé très amusant celles et ceux qui hurlent lorsque on trouve ce caractère dans du code mais qui l'utilisent à tout va avec le designer. On va me sortir "oui mais là c'est pas pareil [bla bla bla]". Effectivement, les liaisons sont matérialisées par un petit rond (remplis ou non) à côté de ta déclaration. Jusqu'au jour où xib m'a dit que la liaison existait alors que je l'avais supprimée par inadvertance.
Dans le cadre d'une fenêtre contextuelle (un menu ou autre), ça sert à quoi de la déclarer dans xib et de la cacher si l'utilisateur ne demande jamais à l'afficher ? Il est où le but d'instancier une UIView qui ne sera jamais affichée ? Consommer de la mémoire vive ? Tu vas me dire "oui mais là tu l'instancies en Swift [bla bla bla]"...
J'utilise le designer pour des interfaces simples. Mais des quelles sont à minima complexes, je passe par du code.
Ne vois pas ma réponse comme une attaque personnelle contre toi. Ca n'aurait d'ailleurs aucun sens. Mais partir en live sur des questions hors sujet c'est vraiment chiant. Enfin je sais pas mais devoir justifier pourquoi j'utilise (ou non) xib me gave. Je voulais simplement savoir si un/une guideline existait.
C'est fort probable !
En programmation, j'ai jamais été un grand fana des designers. J'ai développé cette allergie suite à l'utilisation de Dreamweaver. :P
Dans un UINavigationController. Il est vrai que je n'ai pas pensé à ne pas setter de hauteur... Je ferai le test.
Ah ? Peut être un début de réponse ?
Peux tu me donner les hauteurs en question et où tu tiens ta source ?
Merci pour vos réponses !
Si tu utilises autolayout, tu n'as pas besoin d'assigner les tailles aux navigationBars, tabBars, toolBars, etc. Comme j'ai déjà dit, ils ont tous une taille intrinsèque. Et, en assignant une taille spécifique, tu luttes contre le sytème d'autolayout.
Je ne prendrai pas le temps de chercher les tailles parce que, franchement, je m'en fiche 8--)
1. "Lourd" tu dis ? Comment ? J'ai un MacBook Pro 2010 ; oui, il faut attendre le premier chargement mais, après ça, pas de problème.
2. Si tu utilises plusieurs storyboards, aucun problème - chacun à son fichier. Si tu utilises un seul, dans un groupe, t'es fou ! Il faut assigner les tâches afin que on ne travaille jamais sur le même viewController au même temps qu'un autre développeur.
3. Tu te trompes. Avec le code, c'est beaucoup plus difficile à suivre les modifications pendant l'évolution sans beaucoup de commentaires et explications. J'ai fait plusieurs projets comme tête de projet et je peux t'assurer, le plus de code, le plus d'erreurs ; et le plus de temps gaspillé en cherchant les bogues.
4. J'ai créé les barres de progression ; il faut écrire le code pour les dessiner mais, après ça, tu peux les mettre dans le storyboard.
5. Les @IBOutlets sont écrit avec les ! parce qu'on est assuré que le système de chargement des storyboard s'occupera de garantir que tous telles vars ne seront pas nil. Mais, en revanche, tu doit rassurer le compilateur en le disant ; sinon, il faut mettre une valeur par défaut ou les mettre en optionnelles et tu devrais utiliser les ? ou les "if let" partout dans le code.
Tu parles des fenêtres "cachées" ? En créant les storyboards, on ne cache pas les vues qui se trouvent là dedans, elles ne sont pas instanciées qu'au moment qu'on on a besoin. Si on ne les veux jamais afficher, elles ne sont jamais instanciées.
On peut instancier les viewControllers, soit par moyen d'un segue dans le storyboard, soit en code ; on a toujours le choix et le code pour le faire est minimal.
Le designer est là pour les interfaces complexes.
Regardes mon appli pour Fest Jazz - 7 storyboards pour les différents vues, dont un réutilisé en deux différents situations ; aucune ligne de code pour manipuler les positions ou les tailles des vues. Mais, en fait, les utilisateurs peuvent la télécharger sur n'importe quel iBidule (de l'iPhone 4 jusqu'à l'iPad Pro 12" en se rassurant que l'agencement suit le modèle, en utilisant le splitViewController où et comme il le convient, en n'importe quelle rotation voulu.
Mes questions n'étaient pas hors sujet. Je ne voulais que dire que ce que tu cherches faire mène sur un chemin plus difficile que nécessaire ou sage. De ma part, il ne vaut pas le temps de faire les recherches sur un sujet qui mène à trop de travaille pour rien gagner.
à‰galement, ce n'est une attaque personnelle mais, si tu veux gaspiller le temps en faisant les bêtises, tu auras assez de temps pour fouiller dans les docs de la Pomme ::) J'espère que tu ne fais pas payer un client pour tout ça ???
Mais, ici, on ne parle pas de design pour web, on parle de design d'une interface qui conviendra multiples appareils beaucoup plus sophistiqués qu'un browser. Le système des contraintes et d'autolayout pourrait être difficile de piger au premier regard mais, si tu t'occupais de l'apprendre, à la place d'écrire quelques centaines de lignes de code, tu y trouveras to bonheur :-*
Encore une fois, tu as parlé d'utiliser l'autolayout, oui en code mais c'est pareil ; mais, au même temps, tu parle d'assigner les tailles des composants ; ce qui est fortement déconseillé parce que ça créera les conflits entre les tailles et les contraintes (quelque chose qui soit bien évident dans un storyboard mais beaucoup plus difficile de trouver dans le code)
Ca y est, j'ai tapé dans l'égo de Joanna et nous entrons dans un débat sans fin.
Bon déjà quand je lis ça, je me demande quand même pourquoi tu interviens sur le sujet. Bon okay, je te le concède, il y avait The Voice à la tv. :P Je pose une question qui est de savoir si une guide line existe, le sujet t'intéresse pas, tu réponds à une question que ne n'ai même pas posée... C'est pas de la programmation que tu aurais du faire mais de la politique.
C'était de l'humour... ::) Promis la prochaine fois je vais placer des hashtag pour que tu comprennes. Par ailleurs j'ai déjà utilisé à mainte reprise le storyboard. Mais tu as raison de prendre les gens de haut ici sans savoir ce qu'ils font ou non. Je n'ai d'ailleurs jamais dit que je n'utilisais jamais xib... Bref c'est pas grave.
1 - C'est pas faux mais ce n'est pas seulement au lancement que c'est lourd. Il n'est pas rare que xib freeze quand je zoom sur une vue (mais tu as raison je suis le seul à trouver xib lourdingue #ironie)
2 - Ah... Donc ce que je dis n'est pas si faux que ça puisque tu m'incites à passer par plusieurs storyboard... Donc à savoir si je suis un fou ou pas, peut être. Mais toujours est il que tu n'as pas d'autre solution que de passer pas une usine à gaz. Viens surtout pas m'expliquer que de créer un storyboard par développeur (#exagération) c'est bien plus simple que d'en avoir un commun. Si deux devs doivent mener des tâches distinctes sur une même fenêtre, tu fais quoi ? Tu envoies un mec en vacances pendant que l'autre fait son taff. La prochaine étape c'est quoi ? Me sortir qu'il faut dupliquer du code à l'infini pour éviter les conflits ? Dans une cadre d'un projet en équipe, ta solution n'aura pas d'autres vertus que de mettre un pansement sur une jambe en bois. Par ailleurs, quand je discutais (cocoahead à Paris) avec des mecs qui bossaient sur des projets iOS dans une équipe, ils faisaient le même constat du bordel que représentait xib dans ce cas précis. Quand tu es tout seul dans ta chambre effectivement tu vas pas être en conflit avec grand monde lors de commit. Je t'invite à les former et démontrer que ta solution est la plus simple. Et surtout quelle règle la complexité des merges avec le code généré par xib dans la une équipe qui bosse sur une même ihm. :-*
3 - C'est possible, je donne juste mon avis (contrairement à toi je n'ai pas le culot de dire que j'ai raison de tout).
4 - Donc oui, on doit coder la barre puis l'ajouter, comme quoi coder n'est pas si mal que ça... C'est vrai que c'est beaucoup plus compliquer de la coder et de l'intancier directement dans ton code... Puis il est également vrai que la placer dans xib est judicieux surtout si elle n'apparait pas obligatoirement... #ironie
5 - Oui donc utiliser "!" c'est le mal mais finalement c'est pas si mal que ça. C'est vrai que passer tes déclarations optionnelles contourne le problème à condition d'employer des blocs conditionnels. Il est également vrai que c'est aussi largement plus simple que d'utiliser le code suivant qui lui ne t'impose pas d'utiliser "!" ou "?"... #ironie
Ah mais si, c'est d'une complexité inouà¯e !
#humour
Oui, dans ta storyboard courante (une fenêtre contextuelle par exemple). Tu es sur un écran A. Dans ton écran, tu as une fenêtre contextuelle qui apparaitra que dans un cas précis. Tu vas le placer dans xib au risque qu'il soit instancier pour rien ? Viens pas parler de segue et compagnie. Tu crées pas systématiquement ce genre de mécanisme pour afficher une petite fenêtre "volante" d'options. Si ? #usineAGazQuandTuNousTiens
Et ce que tu décris ne résout pas le problème...
C'est une blague ? Je parlais d'une interface à minima complexe, ce que tu montres c'est loin d'être le cas... Là effectivement, pour si peu, xib fera bien le travail. Mais bon, vu que tu vas encore une fois mal le prendre, on dira que c'est une IHM super sophistiquée.
Bah vayons... C'est vrai que de passer par 7 storyboards tu gagnes un temps de folie. Surtout que je n'ai jamais dit qu'utiliser xib est une hérésie, je dis juste qu'il y a des cas où son emploi ne me semble pas judicieux...
Un peu plus loin et comme dirait un ancien ami "cerise sur le McDo"
Si c'est pas une attaque personnelle, c'est quoi, une insulte ? ::) Ne pas rentrer dans ton sectarisme c'est être incompétent ? Où ai-je dis qu'utiliser xib c'était le mal absolu ? Au risque de me répéter, je dis simplement qu'il n'est pas adapté à tous les cas.
Au vu de ce que tu es capable de sortir, je serais toi je me serais abstenu d'écrire ce genre de phrase.
Ah ! Enfin ! Non parce que tu me vends de l'Autolayout à tout va mais je n'ai jamais dit que je ne l'utilisais pas...
Absolument faux, je cherche une doc officielle (relis mon premier post). Je sais même pas où tu as lu que je settais en dur la taille de mes composants. D'ailleurs c'est simple, j'utilise uniquement les autolayout sauf dans le cas de prototype... Ce qui m'intéresse de savoir c'est si j'ai la possibilité de passer une toolbar de 44pts à 35pts sans avoir de souci lors de la validation (avec ou sans xib). Tu vois que ma question est bien loin de tout ton bla bla dans lequel tu dis tout et le contraire de tout.
Encore une fois je n'ai rien contre toi mais c'est exaspérant que tu interviennes dans des posts pour répondre à des questions que je ne pose pas. Je demande où est une doc et pas de savoir si c'est bien où mal de faire du 100% xib.
Cette mentalité... Tu viens me faire des beaux discours sur quelque chose que je n'ai jamais dite. Tu viens démontrer des éléments en donnant des solutions (pas toutes, je tiens à préciser avant que tu gueules) qui ne résolvent en rien les cas que j'ai cité. Tout en balançant des phrases (que je ne sais trop qualifier, méchante ?) sous couvert d'une non attaque...
Ici...
Puis là ...
Dans la série je dis tout et le contraire de tout...
Mais Joanna, on est où là ? Sur une communauté d'entre aide où dans un endroit qui te permet d'exalter ton égos ? Ca rime à quoi de venir dire "j'ai l'info mais je te la donnerai pas". Je me souviens d'un sujet auquel on a participé tous les deux où tu disais que le forum était de moins en moins actif et qu'il semblait mourir à petit feu... Ce genre de comportement n'est il pas l'une des causes de ce phénomène ?
Tu aurais pu les trouver, en tapant dans Google, beaucoup plus vite que les demander ici. Ce genre de question me dit que tu as la flemme de rechercher toi-même, préférant de pencher sur la bienveillance des autres de faire les recherches à ta place.
En plus tu as écrit :
On est bien dans une communauté d'entraide mais n'oublies pas que c'est pratiquement impossible de se souvenir de tous que l'on a lu et appris ; ça mets le temps des autres, qui ont souvent déjà beaucoup dans leurs assiettes.
Suis-je égoà¯ste pour donner les conseils d'une professionnelle de plus de 25 ans d'expérience ? C'était et c'est encore mon métier de conseiller les entreprises, des petites aux grandes, comment faire le design et la programmation, pour qu'ils puissent mieux profiter.
à‰videment, ce que je t'ai conseillé, en évitant le code et en ne modifiant pas les dimensions des composants, ne t'as pas plu. ç'arrive de temps en temps dans un forum. Tu aurais pu dire, tout simplement, merci mais non merci et je t'aurais entendu.
Sur mon iPad j'ai des applications dont les toolbars connaissent des tailles différentes (de différentes sociétés ou de devs indeps). Je me demandais simplement quelle était la norme, si elle existe une hauteur mini et maxi de la barre. (Tiens, je t'invite ici à aller les insulter...)
J'ai donc cherché une info officielle de Cupertino. Je suis tombé sur ça qui n'apporte aucune réponse à ma question. Et sur ça qui donne un début de réponse mais sans plus. Donc oui j'ai cherché. Et c'est bien pour cette raison que j'ai précisé "si elle existe" car j'ai un doute. Alors si tu as la doc officielle, ça serait gentil de me faire passer le lien pour clore le débat.
Je suis entièrement d'accord avec toi. Je cherche une doc, alors pourquoi tu tergiverses sur des sujets divers et variés ? Tu te rends quand même bien compte que ma question ne concernait en rien l'emploi (ou pas) du storyboard...
Egoà¯ste non. J'ai d'ailleurs surement beaucoup à apprendre de tes conseils. Borné ? Peut être un tout petit peu (non ?).
Me sortir que tu utilises 7 storyboard lorsque je dis que les merges sont inbouffables dans le cadre d'un dev en équipe, n'a strictement aucun rapport. Si ? Lequel ? Tu as déjà vu les commits du code généré par le storyboard, comment tu t'y retrouves dedans ? L'emploi de multiple sb diminuera le risque, rien de plus (et encore...).
Enfin j'en sais rien mais aller conseiller de ne pas faire de dev en concurrence sur un même storyboard c'est limite. L'équipe va faire quoi quand (tôt ou tard) deux devs vont bosser sur la même partie graphique par accident ? Bah c'est simple, elle va se faire ierch... Tu parles d'un conseil toi... ??? Pour toi, ça n'arrive jamais dans une équipe de travailler sur les mêmes parties ? Dans la mienne tous les jours (malheureusement). Je pourrais dire "J'espère que tu ne fais pas payer un client pour ça" mais je serai débile et méchant. Bref, je me rabaisse pas à ça.
Et toc ! 
Tu t'évertues à prôner haut et fort l'utilisation d'xib. Okay, pourquoi pas. Moi je te dis simplement qu'il n'est pas adapté à tous les cas. Mais ça n'empêche pas qu'xib reste un bon moyen pour faire des IHMs propres de façon rapide.
Je vois vraiment pas ce qui peut me déplaire la dedans, à l'exception que tu t'enflammes sur des sujets extérieurs alors que je n'ai jamais dit que je n'utilisais pas le mécanisme de l'autolayout (je sais vraiment plus comment te l'expliquer). Je te demande si il faisait beau ce matin dans ta ville, tu me réponds que tu t'es levée à 7h en me faisant de beaux discours sur les vertus de se lever de bonheur... Alors oui il y a un sujet commun qui est matin mais le reste...
#humour
Tout ce blabla avec toi pour voir si une doc existe c'est de la folie.
J'ai fait le test hier soir avant de me coucher. Effectivement, si tu ne settes pas de hauteur, elle prendra la valeur par défaut. A voir maintenant si je peux la positionner à 35pts sans me faire taper sur les doigts par la pomme. ::)
Joanna nous aide bcp ici et prend du temps pour ça. Je te trouve très limite limite dans tes posts polémiques de 15 km de long... >:(
A la base, elle a raison : storyboard t'exempte de savoir s'il y a des guidelines sur la hauteur d'une navbar ou pas. Et c'est un réel conseil que te dire de l'utiliser. Positionner ses vues par code, ça se fait plus, tout simplement parce que tout le monde gagne en productivité. Maintenant, si tu veux continuer, libre à toi aussi mais tu auras forcément moins de réponse à ce genre de question.
Ensuite, si tu veux que ta navbar soit plus haute, libre à toi. Apple ne va pas te rejeter ton appli parce que la navbar fait 50pts de hauts. D'ailleurs, on en voit de plus en plus qui sont très hautes car le material design s'invite dans iOS ces derniers temps.
Jérémy, si tu n'était pas allergique aux storyboards, tu aurais pu déterminer les dimensions "recommandées" d'Apple, tout simplement en regardant l'inspecteur, sur le composant de ton choix. Et tout ça sans rancoe“ur ou confrontation.
Je pense pas avoir dit le contraire...
Ma question est de savoir ce que j'ai le droit de faire. Pourquoi ? Car la taille proposé ne me plait pas. D'où le fait d'avoir la doc... Je sais vraiment pas comment l'expliquer...
Encore une fois, je n'ai jamais dit que je ne l'utilisais pas. Je n'ai jamais dit qu'on gagnait en productivité sur un projet où tu es seul. Je dis simplement que dans une équipe, la gestion des conflits, des marges et vraiment pénibles.
??? ??? ??? ???
Je commence à comprendre que tu n'as pas forcément lu les posts d'où le fait que je répète (une fois de plus) ce que j'ai dit plus haut. La preuve :
Il est vrai que de passer de 44pts à 35pts c'est une grosse augmentation...
Bon, il va falloir arrêter de me faire dire des choses que je n'ai jamais dites. Non parce que tu me prêtes des propos mais quand je te demande où j'ai pu écrire ceci où celà , je n'ai jamais de réponses. Où j'ai écrit que :
- j'étais allergique au storyboard (me sort pas la phrase sur dreamweaver, c'était une plaisanterie, je te l'ai dit)
- je n'utilisais jamais le storyboard
- j'ai dit que le storyboard était quelque chose d'anti productif ?
Non parce que depuis samedi tu me sors ça sans savoir d'où ça sort...
Pour terminer (et j'espère que les choses sont claires maintenant), je dis simplement que (au lieu de réécrire je vais me citer) :
Vous serez d'accord avec moi qu'un bon code doit être clair et compréhensible. Vous trouvez franchement que le code généré par le storyboard respect cette règle ? Bah non, puis toute façon on s'en fous puisque quand tu es tout seul tu es rarement en conflit avec toi même. Mais dans une équipe, va faire un merge (voir screen). Tu parles d'une productivité dans ce genre de cas... Tu ne penses pas que tu multiplies considérablement les risques de régressions ? Non ? Même pas un petit peu ? Ah bon...
Le "code" derrière un storyboard est bien structuré mais il n'était pas intentionné d'être lu, sauf en cas extrêmes.
Il n'y a aucun problème en utilisant les storyboards avec plusieurs développeurs mais... il faut prévoir leur gestion à propos Git et ne pas mettre trop dans un seul storyboard. Plusieurs développeurs sur le même "use case" ? c'est fortement déconseillé et de ma longue expérience, toujours évitable.
Si ça se trouve, il faut, tout simplement, sacquer le chef de projet 8--)
Ah ?! Enfin un signe d'ouverture ? 8--)
Absolument vrai. Malheureusement dans une team le "cas extrême" c'est presque le pain quotidien. Il a beau être structuré mais il reste imbouffable.
Sans forcément parler d'un même use case. Tu peux en avoir deux distincts sur un même storyboard (mais là , au vu de ton expérience, je ne t'apprends pas grand chose). Et là ? Bah tu es chocolat lorsque tu dois faire un merge (particulièrement si tu as touché les mêmes composants que ton collègue)...
Plusieurs storyboard diminuent le problème mais le résolvent en rien.
Oui enfin bon... Là j'ai l'impression d'entendre mon prof de fac qui vit dans un monde idyllique. La réalité est tout autre. On ne devrait pas à mettre des plots en béton dans nos villes pour que les piétons ne se fassent pas écraser. Dans un monde parfait ça n'a pas de sens. Et pourtant...
Enfin je remarque trois choses.
1 - Tu ne m'as toujours pas dit où j'ai écris tout les propos que j'aurais tenu sur xib...
2 - Que tu commences à admettre les limites de l'utilisation du storyboard
3 - Nous ne sommes pas d'accord sur tout (quoi que maintenant tu mets de l'eau dans ton vin rouge) mais tu prends la peine de lire la conversation. Entendre pas là que le matou noir, lui, ne se donne pas autant de mal. Entre ce que j'aurais dit (je sais pas où il a lu ça... Ah mais oui je suis bête :P ) et me sortir l'inverse de mes phrases...
Pour en revenir à la question, j'ai déjà vu passer des images qui donnent les tailles, mais je n'ose pas t'envoyer de liens, n'étant pas sûr qu'elles soient à jour.
Comme le dit Joanna, l'un des problèmes est que la hauteur de la Navigation Bar change selon l'orientation. Et ça n'a pas toujours été le cas!
À chaque fois que tu utilises des tailles en dur, tu risques qu'elles changent dans la prochaine version d'iOS. Rien que pour ça je ne m'y risquerais pas.
Par ailleurs, on ne peut pas toujours fixer la taille de toute façon. Tu peux passer une taille à la création de la view, mais c'est simplement ignoré par iOS.
Bref, ce n'est peut-être pas la réponse que tu attendais, mais même par le code, je te conseille d'utiliser l'autolayout.
Merci Céroce pour ton retour. J'ignorais que d'une version à l'autre d'iOS, la hauteur des barres peuvent changer.
C'est ce que je faisais. Je trouvais la hauteur trop importante... Tant pis...
Disons que le choix d'Apple est un compromis. Par exemple, sur l'iPad Mini, un point est physiquement assez petit, alors même les icônes en 44 x 44 sont un peu petites.
Ouai je comprends. Mais passer de 44pts à 35pts... C'est pas non plus comme si je l'avais divisé par deux... ::)
Super cohérent leur truc... Quand tu vois que la hauteur par défaut d'un textfield est de 30/31 points...
Je n'avais pas compris. Ils disent que les éléments cliquables doivent être séparé de 44pts. C'est pas vraiment incompatible avec ce que je veux faire.
Mais là où Céroce à raison c'est que sur un iPad Mini, la barre doit être petite.
Ils ne parlent d'une séparation, c'est plutôt la taille minimum d'un zone de touche. Les textField ont un zone lateral assez large, malgré le manque d'hauteur ; au moins si on laisse assez d'espace entre un et son voisin.
C'est cette phrase que je dois mal interpréter :
Je pensais que ça voulais dire de ne pas trop coller les éléments entre eux.