Utilisation du "~iPad.xib" pour un iPhone 6 Plus ?
Hello
Savez-vous s'il est possible de faire en sorte qu'iOS8 utiliser nos fichier "Foo~ipad.xib" au lieu de "Foo.xib" quand l'application est lancée sur un iPhone 6 Plus ?
La question posée autrement :
- J'ai une application Universelle (iPhone + iPad)
- On n'a pas prévu de faire une refonte totale de l'ergo juste pour s'adapter à l'iPhone 6/6+
- Par contre l'affichage qu'on a déjà sur iPad et iPad Mini (Foo~ipad.xib) conviendrait tout à fait pour un affichage sur un iPhone 6+ plutôt que d'utiliser l'affichage qu'on a sur les iPhones (Foo.xib) juste étirés
- On utilise déjà AutoLayout donc les contenus sont prévus pour s'adapter à l'espace disponible. Donc le Foo~ipad.xib redimensionné pour s'adapter à la taille de l'écran iPhone6+ conviendrait
- On ne compte pas tout refaire pour passer notre Foo.xib en "Size Classes", car ça serait du boulot alors qu'on a déjà les 2 variantes de prêtes dans Foo.xib et Foo~ipad.xib. Et que de toute façon l'application doit continuer de fonctionner sur iOS7
Questions annexes :
- Est-ce que Size Classes fonctionne sur iOS7 (et que genre si notre Deployment Target est iOS7, au lieu de générier un unique .nib à la compilation, lisible uniquement sur iOS8 car lui seul comprend Size Classes, il génère deux nib dont un "~ipad" pour que ça reste compatible iOS7 ? (Un peu comme AssetsCatalog qui assurait la rétro-compatibilité d'une manière similaire générant les fichiers à l'ancienne mode si on ciblait un iOS trop ancien)
- Y a-t-il une option cachée dans Xcode pour facilement fusionner un Foo.xib et un Foo~ipad.xib en un seul XIB utilisant les Size Classes ?
Merci de vos lumières !
Mots clés:
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
Je n'ai pas de réponse mais c'est vrai que ce serait bien de pouvoir faire ainsi.
Il est évident que certains écrans conçus pour l'iPhone font tout bizarre sur le 6+ (enfin sur le simulateur...)
Untrucalacon:
Tu peux pas faire une macro qui force ~ipad en fonction de la taille de l'écran du 6 Plus (>= 2xxx) et remplacer les initWithNibName par la macro ?
Bah j'y pensais ouais, ça pourrait peut-être être une solution.
Après je me demandais :
(1) si ça marche de passer le nom avec "~iPad" explicitement à initWithNibName ? Par exemple sur le même principe on n'appelle jamais [UIImage imageNamed:@Toto@2x] non plus
(2) S'il n'y avait pas une fonctionnalité plus propre / automatique / dédiée, ou un composant tout fait, ou une solution officielle
ouais ouais. Quand c'est nous qui faisons des trucs crades comme ça, on nous tape sur les doigts mais quand vous devez vous y coller, ben c'est pas mieux hein
Je rêve, notre puit de science Ali se met à poser des questions ;D
Sinon, en lisant ceci : http://stackoverflow.com/questions/24172860/how-can-xcode-6-adaptive-uis-be-backwards-compatible-with-ios-7-and-ios-6 il semblerait qu'iOS 7 lise les storyboards et XIB utilisant les size class mais applique systématiquement le layout défini pour la classe "Any/Any" et en applique certaines correctement (depuis Xcode 6 b4, j'avais pas lu la page jusqu'au bout) dans le simulateur. Sur un device c'est pas très clair...
Sinon en bas de la page il y a une intervention de Dave Delong, qui je crois bosse chez Apple. Je pense qu'il est utile de suivre ses conseils.
Oh oh !
Est ce que ça veut dire qu'on peut finalement utiliser les Size Class et que le design utilisé pour "Compact-regular" sera appliqué sur les iPhone iOS7 et "Regular-regular" sera utilisé pour les iPad iOS 7 ?
Et que donc au final, on peut utiliser les size class et rester compatible iOS7/8 ?
Moi c'est ce que je comprends de l'intervention de Dave, oui.
A mon avis il ne faut pas 3 heures pour faire une application de test (genre avec un bouton placé différemment dans les divers classes) et l'essayer sur iOS7 et iOS8...
M'enfin ça ne répond pas à la question principale d'Ali de toute façon, mais uniquement à sa question annexe...
Ahah tu as tout à fait raison, j'ai même honte de poser la question
Je vais m'attaquer à faire une appli de test, j'ai 2-3 trucs à confirmer de toute façon.
En espérant que mes conclusions tirées par des tests sur simulateurs seront applicables aussi sur devices (parce que le temps qu'on reçoive nos iPhones 6 et 6+... ^^)
Si jamais on arrive à répondre à ma question annexe numéro 2, cela solutionnerait mon problème (et serait même sans doute idéal) : Si SizeClasses est réellement compatible iOS7, alors si on trouve un moyen de fusionner automatiquement un Foo.xib iPhone existant + Foo~ipad.xib iPad existant en un nouveau Foo.xib Universel utilisant SizeClasses, ça me va bien aussi !
D'ailleurs je viens de lire la réponse de Dave, et c'est ce que j'espérais à vrai dire, car Apple a fait exactement la même chose pour les Assets Catalog : Si vous utilisez les Assets Catalog dans votre projet :
- Si votre projet cible iOS7 (Deployment Target = iOS7) alors ça génère à la fin un fichier unique "assets.car" (un fichier qui semble être au format propriétaire propre à iOS) contenant toutes vos images (et les infos de slicing pour les 9-patches) en un seul fichier dans le bundle final (.ipa). Or le runtime iOS7 sait manipuler ces fichier donc pas de soucis
- Si votre projet cible iOS6 ou inférieur (Deployment Target < 7) alors ça génère autant de fichiers PNG, fois le nombre de résolutions (@1x, @2x), que d'assets, pour que dans le bundle (ipa) final vous vous retrouviez comme avant que les Assets Catalog existent, directement avec les fichiers PNG dans le bundle
Au niveau de Xcode c'est transparent, vous pouvez utiliser les Assets Catalog dans votre projet dans tous les cas, et il va compiler d'une manière ou d'une autre en fonction du Deployment Target pour s'assurer de la rétro-compatibilité.
J'espérais donc justement que ça soit pareil pour les Size Classes qui re-génèrerai les ~iphone et ~ipad... d'après la réponse de Dave il semble que ça soit le cas, ô joie.
Je teste au plus vite par moi-même et vous confirme ça.
Je suis en train de regarder la session #216 de la WWDC'14 (je vous invite à la regarder y'a plein de trucs intéressants)
Et là je découvre qu'on peut overrider les TraitsEnvironments (= size class horizontale + size class verticale + idiome iPhone/iPad + screen scale) de nos vues si on veut.
Dans leur démo par exemple ils utilisent un SplitViewController (qu'on peut maintenant utiliser sur iPhone, et qui se met automatiquement en 2 colonnes master/detail quand on est sur iPad) et ils montrent comment forcer la SizeClass à "Regular" au lieu de "Compact" quand ils passent l'iPhone en mode portrait pour forcer la vue master/detail comme sur l'iPad même quand on est sur l'iPhone.
Pour cela, ils utilisent la méthode "setOverrideTraitCollection: forChildViewController:" (à ≈36'30 dans la vidéo)
Ils présentent aussi le fait que les "Traits Environments" suivent une sorte d'héritage, récupérant les Traits de leur view/viewcontroller/window/screen parent s'ils ne définissent pas eux-même le leur. Mais du coup si tu forces donc le trait ainsi, en disant que même si tu es sur un écran "compact" tu veux utiliser l'interface "regular", ça devrait permettre d'utiliser l'interface iPad sur un iPhone 6 Plus landscape... du moins en théorie (ça aussi faut que je teste)
En tout cas ça me semble une piste à creuser.
Ben essaye ! Et tu nous donneras la réponse.
Ah ces newbies qui veulent qu'on fasse tout pour eux !
Va voir dans les xml des xibs si, par hasard, un xib avec deux size classes ce serait pas tres ressemblant à deux xib collés côte à côte dans un seul fichier...
Bien sur tu ne beneficierais pas de la factorisation des elements communs quoique en mettant les mains dans le camboui...
Le locuteur montre également qu'avec une méthode il est possible de modifier le nombre de colonnes allouée à la vue de gauche, jusqu'à prendre la moitié de l'écran par exemple.
La Size Class est une bonne nouveauté pour gérer plus facilement les vues je trouve et même si je n'ai pas encore pratiqué je pense que c'est un outil qu'il faut utiliser dans l'avenir pour gérer les tailles et orientations des devices.
Sinon, cette vidéo dont tu parle se trouve être la Session 214 chez moi et non 216.
Concernant ta question sur l'utilisation des SizeClass sur un support iOS7 ou inférieur j'ai des doutes. J'ai pas vérifié mais dans la documentation, les UITraitCollection ne sont utilisables que sur une cible iOS8. Je suppose que tout ce qui est lié n'est rendu utilisable qu'à partir de la dernière version mais c'est à confirmer.
Bah de ce que dit Dave Lelong, faire un XIB ou Storyboard qui utilise des SizeClass mais cible iOS7 semble possible (je teste d'ici ce soir, là je suis un peu débordé).
Par contre l'utilisation par le code évidemment, et donc faisant intervenir des classes comme UITraitCollection ou des méthodes comme "setOverrideTraitCollection:forChildViewController:", est à conditionner par la disponibilité desdites classes et méthodes. Mais bon ça c'est du "cross-SDK development" assez classique (https://developer.apple.com/library/mac/documentation/developertools/conceptual/cross_development/Introduction/Introduction.html)
La 214 c'est "View Controller Advancements in iOS 8"
La 216 c'est "Building Adaptive Apps with UIKit"
D'ailleurs si je recherche sur asciiwwdc le terme "UITraitCollection" il n'y a que la session 216 qui ressort. Mais c'est vrai que si je cherche le terme "trait collection" par contre la 214 est listée aussi
Ah ! Parce que la description de la vidéo dont tu parles (avec le SplitView Controller) est désignée chez moi comme la session 214 après l'avoir télécharger et vu. Mais peut être qu'en fait j'ai pas vu la bonne vidéo.
Edit : Oui en effet. Je n'avais pas fais attention.
Bah ils en parlent dans les 2, mais sous 2 angles différents.
Dans la 214 ils se concentrent sur les nouveautés côté UIViewController.
Dans la 216 ils se concentrent sur les Size Classes et les Traits.
Je déterre le sujet car je me met aux size class.
D'après mes premiers tests, les size class ne sont pas utilisées sous iOS7. Par défaut, il prend le design qu'on a défini pour la size class any/any.
Du coup, j'imagine que le coup du UISplitView qui fonctionne partout ne doit pouvoir s'utiliser qu'en iOS8...
C'est un peu plus compliqué que cela : http://stackoverflow.com/a/25795533/267152
Je confirme ce que dit FKDEV (j'avais déjà cité la même réponse de Dave DeLong sur SO), sachant que au cas où tu n'es pas au courant, ce Dave DeLong est un App Framework Evangelist chez Apple, donc le gars sait de quoi il cause ^^