Ah ben oui je pense que c'est ce qu'il fait. S'il n'y a pas de @2x de présent, le simulateur non-Retina prend la version non @2x je pense. Mais bon ça se voit quand même que ton image est crénelée (enfin ça dépend si t'as l'oeil /biggrin.png' class='bbc_emoticon' alt=':D' />)
Ah ben oui je pense que c'est ce qu'il fait. S'il n'y a pas de @2x de présent, le simulateur non-Retina prend la version non @2x je pense. Mais bon ça se voit quand même que ton image est crénelée (enfin ça dépend si t'as l'oeil /biggrin.png' class='bbc_emoticon' alt=':D' />)
Donc ça permet pas vraiment de vérifier qu'on a oublié des @2x ;-)
De mon côté, je confirme. Qques autoresizes dans les xib (ce que j'appelle les ressorts car dans le temps, il me semble bien qu'il y avait des ressorts :-)), une image de chargement et hop, ça roule nickel.
C cool, je pensais que ce serait pire...
Cependant, un truc con : mon convertisseur de cotations.
Ben en 4", je pourrai facilement ajouter 1 ou 2 échelles supplémentaires...
Du coup, on rentre quasi dans la fragmentation des résolutions là ... Genre :
=> Si résolution.height=1000 et qques, ajoute 2 échelles ?
int nombreEchelles = ([UIScreen mainScreen].bounds.size.height - kMargins) / kEchelleHeight;
Pas de condition, juste un calcul du nombre max d'échelles que tu peux mettre selon la hauteur de l'écran, et donc un calcul dynamique et adaptatif et non une valeur statique en dur.
ouaich... Enfin, c ce que je dis quoi... Ca se gère en plus quoi... Alors qu'à la base, je pensais qu'ils allaient juste "stretcher" l'écran (désolé ldroziers :-)) (et désolé *2 car je tape ton pseudo à l'aveugle...) et comme on est en retina, ça allait pas se voir...
Mais bon... En y réfléchissant, ça paraà®t compliquer (forcément, ça déformerait)...
Ah non heureusement qu'ils n'étirent (c'est mieux en français hein ?) pas l'écran direct cash, ça ferait un truc déformé !
Par contre ils font en sorte que les vues prennent tout l'écran, et appliquent les autoresizingmasks déjà en place, pour replacer les subviews, rendre plus grande celles que tu as rendu étirables avec les AutoresizingMasks (les "struts & springs", les "ressorts" rouges de IB quoi), et ça évite d'étirer et déformer, mais ça utilise bien toute la place de l'écran (par exemple un UITableViewController ta tableView aura juste + de cellules d'affichées à la fois). Donc ça c'est nickel.
Quant au fait que ça se fait pas tout seul pour tes 2 échelles en plus, bah en même temps c'est normal j'ai envie de dire tu espérais quoi, qu'il allait deviner que tu voulais rajouter 2 échelles ? Et en plus, si tu avais effectivement fait en sorte dès le début que le nombre d'échelles affichées dans ton appli soit en fonction de la taille de ton écran, au lieu de mettre ce nombre d'échelles en dur, tu n'aurais rien à faire.
Par exemple si une échelle prend 90pt en hauteur, sur un écran de 480pt de haut, moins 20pt de statusbar, tu peux afficher 5 échelles (460/90 = 5,111, donc tu peux en mettre 9 et il te reste une petite marge de 10 pixels à répartir en haut et en bas). Si dans ton code tu mets "ok dessine-moi 5 échelles" car tu as calculé ce chiffre 5 de ton côté et l'a mis en dur, forcément sur un écran Retina 4" tu verras toujours aussi 5 échelles. Si dans ton code tu mets par contre int nbEchelles = self.view.bounds.size.height / 90; alors si la taille de la vue fait 460pt (iPhone 3.5") tu auras 5 échelles, mais si elle fait 548pt (iPhone 4") tu en auras 6.
C'est justement avec cet écran 4" qu'on va voir ceux qui ont codé leur appli avec des valeurs en dur et des Magic Numbers de partout, et ceux qui ont codé leur appli en récupérant la taille de l'écran avec les méthodes dédiées etc. C'est comme quand tu utilises une valeur en dur de 300 dans ton code pour qu'une vue fasse la largeur de l'écran moins 20px par exemple, forcément si un jour l'écran de l'iPhone ne fait plus 320pt de large ça ne va pas s'adapter. Alors que si tu fais bien self.view.bounds.size.width - kMargins (avec kMargins une constante qui vaut 20) là tu as du code évolutif, des constantes claires, et aucun Magic Number.
Oui je l'ai enlevé après réflexion, je n'ai pas de loader, je ne sais pas si elle parle de la même chose que nous...
Non je parle pas de la splashscreen par défaut, mais bien d'une vue custom de load que j'ai après le [font=helvetica, arial, sans-serif]Default-568h@2x.png [/font]
Ton app est universal? Parce que je sais pas si du coup il va chercher le ~iphone si ça n'est pas universal.. simple supposition
Mon app est universal oui. De toute façon j'ai essayé sans le [font=helvetica, arial, sans-serif]~iphone [/font]pour voir si ça venait de là . Mais non.
Dans ce cas ce gist pourra t'aider /smile.png' class='bbc_emoticon' alt=':)' />
ok merci mais je comprend pas pourquoi utiliser ce code là , xcode ne reconnait pas tout seul le 568h[font=helvetica, arial, sans-serif] [/font]? Comme il le fait pour le @2x ?
Réponses
J'avais jamais testé mais je me disais que dans tous les cas, il prenait la version non @2x... comme le fait le tél.
Donc là , c'est pas con en effet.
Donc ça permet pas vraiment de vérifier qu'on a oublié des @2x ;-)
Chouette ! Moi aussi remarque. Mais là faut que j'arrête de bosser jusqu'à 3:00 du mat'
C cool, je pensais que ce serait pire...
Cependant, un truc con : mon convertisseur de cotations.
Ben en 4", je pourrai facilement ajouter 1 ou 2 échelles supplémentaires...
Du coup, on rentre quasi dans la fragmentation des résolutions là ... Genre :
=> Si résolution.height=1000 et qques, ajoute 2 échelles ?
Mais bon... En y réfléchissant, ça paraà®t compliquer (forcément, ça déformerait)...
Par contre ils font en sorte que les vues prennent tout l'écran, et appliquent les autoresizingmasks déjà en place, pour replacer les subviews, rendre plus grande celles que tu as rendu étirables avec les AutoresizingMasks (les "struts & springs", les "ressorts" rouges de IB quoi), et ça évite d'étirer et déformer, mais ça utilise bien toute la place de l'écran (par exemple un UITableViewController ta tableView aura juste + de cellules d'affichées à la fois). Donc ça c'est nickel.
Quant au fait que ça se fait pas tout seul pour tes 2 échelles en plus, bah en même temps c'est normal j'ai envie de dire tu espérais quoi, qu'il allait deviner que tu voulais rajouter 2 échelles ? Et en plus, si tu avais effectivement fait en sorte dès le début que le nombre d'échelles affichées dans ton appli soit en fonction de la taille de ton écran, au lieu de mettre ce nombre d'échelles en dur, tu n'aurais rien à faire.
Par exemple si une échelle prend 90pt en hauteur, sur un écran de 480pt de haut, moins 20pt de statusbar, tu peux afficher 5 échelles (460/90 = 5,111, donc tu peux en mettre 9 et il te reste une petite marge de 10 pixels à répartir en haut et en bas). Si dans ton code tu mets "ok dessine-moi 5 échelles" car tu as calculé ce chiffre 5 de ton côté et l'a mis en dur, forcément sur un écran Retina 4" tu verras toujours aussi 5 échelles. Si dans ton code tu mets par contre int nbEchelles = self.view.bounds.size.height / 90; alors si la taille de la vue fait 460pt (iPhone 3.5") tu auras 5 échelles, mais si elle fait 548pt (iPhone 4") tu en auras 6.
C'est justement avec cet écran 4" qu'on va voir ceux qui ont codé leur appli avec des valeurs en dur et des Magic Numbers de partout, et ceux qui ont codé leur appli en récupérant la taille de l'écran avec les méthodes dédiées etc. C'est comme quand tu utilises une valeur en dur de 300 dans ton code pour qu'une vue fasse la largeur de l'écran moins 20px par exemple, forcément si un jour l'écran de l'iPhone ne fait plus 320pt de large ça ne va pas s'adapter. Alors que si tu fais bien self.view.bounds.size.width - kMargins (avec kMargins une constante qui vaut 20) là tu as du code évolutif, des constantes claires, et aucun Magic Number.
gnia gnia gnia...
grumph...
Mais bon, on les enlève vite.
Tu test le device et tu set l'image en fonction ? Ou il y a un format de nom auto comme le @2x ?
nouvelle venue, je trouve ce feed très intéressant car il y a que très peu de doc sur le net pour la portabilité vers iPhone 5, donc j'en profite.
J'ai bien ajouté le Default-568h@2x et mon app s'adapte en partie à la nouvelle taille d'écran.
Cependant, j'ai des assets à modifier en 640x1136 comme notamment cet écran de load (voir ci-dessous).
J'ai bien rajouté Default_loader-568h@2x~iphone, mais on dirait qu'il n'est pas pris en compte vu ce que ça me sort :
L'image est étirée, et ne va pas chercher le Default_loader-568h@2x~iphone.
Je me demandais donc s'il fallait rajouter autre chose ?
J'ai raté qq chose ?
Merci
Sinon tu peux te présenter (bien que la plupart doivent déjà savoir que tu fais de beaux dessins).
edit : bon Muqaddar a disparu ... Sympa !
Oui je l'ai enlevé après réflexion, je n'ai pas de loader, je ne sais pas si elle parle de la même chose que nous...
Non je parle pas de la splashscreen par défaut, mais bien d'une vue custom de load que j'ai après le [font=helvetica, arial, sans-serif]Default-568h@2x.png [/font]
Dans ce cas ce gist pourra t'aider
Mon app est universal oui. De toute façon j'ai essayé sans le [font=helvetica, arial, sans-serif]~iphone [/font]pour voir si ça venait de là . Mais non.
ok merci mais je comprend pas pourquoi utiliser ce code là , xcode ne reconnait pas tout seul le 568h[font=helvetica, arial, sans-serif] [/font]? Comme il le fait pour le @2x ?