En testant avec les simu iPhone 6 et iPhone 6Plus, je constate que tout semble à peu près rouler....
Alors qu'avec les resizable iPhone, c'était bien moins le cas....
C'est que tu as du code propre... Moi, vu que je suis toujours une bleue, il reste encore un peu de bricolage par ci par là ... mais ça permet de faire un peu de ménage !
Une autre solution serait de créer des pools de bêta-testeurs. Il y a suffisamment de monde sur le forum pour faire des tests avec toutes les configurations physiques possibles.
C'est que tu as du code propre... Moi, vu que je suis toujours une bleue, il reste encore un peu de bricolage par ci par là ... mais ça permet de faire un peu de ménage !
non non... Je te rassure, j'ai aussi des choses à faire Par exemple, en mode paysage, tout s'adapte très bien en iOS7, pas du tout en iOS8. Ca ne s'élargit pas.
Et je n'ai encore que survolé...
Mais grosso modo, ça se comporte bien, contrairement aux resizable devices.
Les différences de comportement que j'ai pu constater sont plutôt liés à iOS8.
Par exemple, les headers et footers des tableview ont changés (sont moches et gras) et la rotation en mode paysage ne se comporte pas du tout pareil (surement du code un peu crado)...
Vous testez le rendu avec le simulateur ? le simulateur donne un bon rendu ? car ca commence à faire un paquet de résulution 4s/5,5s/6/6plus
Le simulateur est plutôt réaliste dans l'ensemble. Avec le Resizable iPhone c'était plutôt mal foutu (pourquoi la fenêtre du Resizable Simulator ne se redimensionnait pas à la dimension de l'iPhone ? Laissant ainsi des bandes noires entre la fenêtre du simulateur et la zone où l'écran du simulateur était rendu aux dimensions qu'on avait indiqué, et prêtant énormément à confusion...). Mais avec la GM et du coup les simulateurs directement aux bonnes dimensions ça va mieux.
ca va commencer à être du boulot d'optimiser les apps pour toutes les résolutions
quelle stratégie allez vous adopter ?
C'est pour ça qu'Xcode 6 a intruoduit Size Classes. Et c'est pour ça qu'on a les simulateurs. Et qu'on a le mode "Preview" dans l'Assistant de Xcode 6 aussi. Perso j'utilise de + en + le mode "Preview" de l'Assistant quand j'édite mes Storyboard ou mes XIB, pour voir directement ce que mon ViewController va donner à la fois en portrait et en paysage et sur différentes tailles d'écran le tout en un coup d'oeil et sans avoir à lancer de simu.
Pour l'instant je n'utilise pas trop les Size Classes, car je n'ai pas prévu de faire des applications dont la présentation générale va être différente selon si elle est sur écran compact (genre iPhone 4) et sur écran large (genre iPhone 6+). Si j'ai ce besoin un jour j'y réfléchirai, mais pour l'instant je décoche même carrément la case "Use Size Classes" dans mes XIB et Storyboards, pour pas m'embêter, car mes ViewControllers ont le même look " juste étirés en respectant les contraintes AutoLayout pour profiter au maximum de la place disponible " quelle que soit la taille d'écran.
Quand on a bien compris AutoLayout, ça va tout seul de ce côté. Et en général mes apps utilisent déjà AutoLayout, qu'on a adopté depuis quelques temps déjà , donc du coup il n'y a rien à faire pour le passage à l'iPhone6 ou iPhone6+, ça fonctionne déjà comme attendu.
Au final ma stratégie donc :
Utiliser AutoLayout, c'est fait pour.
SizeClasses, ne l'utiliser que vraiment si vous avez un design différent entre écran compact et écran large (avant on distinguait une ergo iPhone vs. iPad maintenant faut plutôt raisonner en distinction écran compact/large, mais le principe reste le même, SizeClasses simplifie juste la vie en concentrant tout dans un seul XIB)
Si vous utilisiez déjà , fort est à parier que vous aurez très peu de changements à faire pour que votre app soit affichée comme vous l'espériez déjà sous iPhone6
Pour avoir un aperçu du rendu lorsque vous mettez au point vos XIB et Storyboard, n'hésitez surtout pas à utiliser l'Assistant en mode "Preview", quitte à utiliser le bouton "+" pour rajouter des modèles d'iPhones ou d'iPad, en iOS6, 7 ou 8, en portrait ou en paysage... pour avoir plusieurs aperçus d'un coup.
Pour le reste, les simulateurs sont plutôt représentatifs du rendu réel sur vrai device.
Et puis, il faudrait aussi se faire une méthode qui capte automatiquement les screenShots pendant les tests, dans toutes les langues, etc. ce serait déjà ça de gagné !
Bah ça existe déjà , et ça s'appelle Automation.
Tu lances Instruments (menu Product > Profile), tu choisis l'instrument "Automation", puis tu cliques sur le bouton d'enregistrement (au rond rouge) tout en bas de la fenêtre de script pour qu'il commence à enregistrer tes actions et générer automatiquement un script pour les reproduire (à ne pas confondre avec le bouton d'enregistrement en haut à gauche de la fenêtre d'Instruments)
Ensuite tu fais joujou avec ton simulateur. Il va t'enregistrer alors tes actions dans le script. Alternativement, tu peux aussi écrire les commandes dans le script à la main (le langage est assez simple c'est du JavaScript).
Une fois le script généré, avant de le rejouer, tu insères des appels à captureScreenWithName() là où tu veux faire des captures. Puis tu rejoues ton script Automator, tu changes de simulateur, tu rejoues le même script Automator, tu changes de simu, tu le rejoues, etc.
Sinon il existe des scripts qui intègrent ça encore mieux, comme UIScreenShooter, qui fait in fine la même chose (utilisation d'Automation pour rejouer un scénario sur un simulateur et déclencher des captures), mais en pilotant le tout d'un niveau un peu au dessus (il se charge de la compilation pour chaque target, lance instruments en ligne de commande, exécute le script, choisis le nom pour les captures selon le simulateur utilisé et son orientation, etc...)
Je me demande si de coder les vues de manière programmatique, ca évite pas des surprises. Autant pour la version Iphone 6 sur le simulateur ca passe bien dans l'écran autant le 6 plus c'est plus penible. Tout façon je crois qu'on va être forcer de faire du simulateur les devices coutant telement cher
Heu là , clairement pas.
Créer les vues par code, déjà c'est un peu une plaie par rapport à avoir un éditeur visuel, bien que pour ça pourquoi pas chacun ses goûts, mais c'est aussi et surtout une quantité impressionnante de lignes de code, rien que pour un seul cas. Si en plus tu dois rajouter par code tes contraintes AutoLayout, tes SizeClasses, et j'en passe, t'es pas sorti. Ca fait 3 à 4 fois plus de code pour pouvoir traiter tous les cas.
Le problème quand tu crées tes vues par code c'est que faut aussi du coup s'abonner aux notifications comme quoi l'orientation a changé ou les bounds de la vue parente ont changé (ou alors implémenter layoutSubviews), tout ça pour être sûr que si ton écran change ta vue s'adapte dynamiquement. En plus, quand tu crées tes vues par code, c'est le meilleur moyen d'introduire des magic numbers dans ton code (et donc, justement, d'être encore moins flexible par rapport aux cas de multi-résolution et multi-orientation)
Alors qu'avec un XIB ou un Storyboard :
En quelques clics tu crées tes contraintes (maintenant avec Xcode 5 et Xcode 6 c'est plutôt bien foutu contrairement aux débuts), sans une ligne de code tu positionnes tous tes éléments de sorte qu'ils s'adaptent automatiquement à toutes les résolutions et dimensions d'écrans, sans avoir du code de partout pour gérer tout ça ou pour ajouter les 36 contraintes (la plaie à faire par code).
Avec l'Assistant et son mode Preview, tu vois tout de suite en un coup d'oeil le rendu de ton ViewController en cours d'édition pour voir la tronche qu'il aura sur un device 3.5' ou 4" ou 4.7" ou 5.5", en portrait ou en paysage, et ce sans lancer le simulateur. Tu déplaces un élément et tu vois tout de suite dans l'assistant Preview où il sera positionné dans toutes les configurations.
Si tu veux un rendu différent sur iPhone et sur iPad, ou plutôt devrais-je dire sur écran compact vs. sur écran large, avec des vues pas du tout positionnées pareil et certaines vues même pas affichées sur un écran compact, pas de soucis, tu as SizeClasses pour ça, pour différencier totalement le placement dans les 2 cas trop différents (alors que par code, c'est encore 2x plus de frames à calculer). Et encore une fois, avec l'assistant tu as le rendu direct de ce que ça va donner dans toutes les configurations, tailles et orientations.
Avec la création de ton interface par code, tu n'as rien de tout ça, et la seule manière de t'en sortir c'est avec un papier/crayon pour faire le dessin de ton interface sur papier à côté et faire tous les calculs alambiqués de positionnement, et compiler et lancer le simulateur à chaque fois que tu veux voir le rendu dans une configuration donnée. L'horreur, je vois pas comment cette solution pourrait t'éviter des surprises comparativement à la solution utilisant un XIB ou Storyboard !!
Au contraire donc, plus ça va et plus on a des {résolutions + orientations + looks différents selon les versions d'OS} à gérer, et plus la solution XIB ou Storyboard, en tout cas l'utilisation d'InterfaceBuilder, avec AutoLayout et SizeClasses, devient incontournable tellement ça serait de plus en plus compliqué à gérer tous les cas par code là où IB te donne tous les outils visuels pour gérer tous les cas d'un coup.
Merci, j'avais un peu regardé automator mais pas trop compris comment le faire fonctionner. Il faudrait que je me repenche dessus. Ca vaut souvent la peine de se donner un peu de mal pour gagner du temps ensuite... le problème, c'est qu'il faut le faire... ::)
A ce jour, j'ai une appli universelle et je traite iPhone et iPad différemment sur certains écrans en utilisant les xib avec le (tilde)iPad.
Tu es en train de dire que si j'utilise les SizeClass, ca ne sert plus à rien ?
C'est exact. Enfin tu peux toujours utiliser la solution de 2 XIB (avec "~iPad") si tu veux, je pense qu'elle va d'ailleurs perdurer un moment. Mais maintenant à la place :
D'une part Apple incite à raisonner en "Large" vs. "Compact" (c'est ce qu'Apple appelle donc les "Size Classes") plutôt qu'en "iPad" vs. "iPhone". En effet, un iPhone 6+ est finalement aussi grand en résolution qu'un iPad Mini, donc ça a + de sens de raisonner en catégorie de taille (Size Classes) qu'en idiome/modèle (iPad/iPhone)
De plus maintenant les XIB et Storyboard intègrent la notion de SizeClasses dans IB, autrement dit maintenant tu peux mettre les 2 variantes (la variante pour la SizeClass "large" et la variante pour la SizeClass "compact" dans le même XIB ou le même StoryBoard.
En fait, il faut plutôt raisonner comme "je fais un Storyboard ou XIB général, applicable à toutes les SizeClasses par défaut (Any/Any), et ensuite je fais des cas particulier pour les SizeClasses qui en ont besoin".
Par exemple tu fais une interface où tu as plein d'infos, tu la design dans IB dans la SizeClass "Any/Any" (la plus générique), et ensuite tu bascules sur la SizeClass "Compact" (qui, tant que tu n'as rien modifié, va reprendre exactement le même look que Any/Any mais compacté pour tenir dans + petit) et tu enlèves des éléments genre des labels (informations superflues dont on peut se passer si on n'a pas assez de place pour les afficher), change le titre d'un bouton "Supprimer le fichier" en "Supprimer" car en vue "compacte" c'est plus court, etc...
Comme ça tout ce qui n'est pas spécifié / customisé dans la SizeClass "compact" il va aller à la place chercher l'objet dans la SizeClass "Any", donc si tu veux par exemple changer la backgroundColor d'une vue finalement plus tard, tu la changes dans la SizeClass "Any" et ça va la changer pour toutes les SizeClasses (à part si tu as une SizeClass où tu avais déjà surchargé la backgroundColor bien sûr). Ca t'évitera donc d'avoir à refaire chaque changement dans toutes les configurations, comme tu es obligé de le faire actuellement avec 2 fichiers différents.
je t'invite vivement à regarder la vidéo WWDC2014 sur les SizeClasses (je sais plus le numéro), elle est plutôt bien foutue et explique bien les choses avec démo/exemples à la clé.
N'ayant absolument pas suivi les rumeurs et autres actus fiévreuses concernant les nouveaux iPhones, je les ai donc découvert lors du Keynote.
Un peu déçu par l'aspect général qui m'a tout de suite rappelé les anciennes générations aux bords arrondis (le design des iphone 5 est bien plus séduisant). Avec mes grandes paluches je serai plus attiré par l'iPhone 6. Le 6 plus me parait trop grand ; j'aurai l'impression de me balader avec un réfrigérateur dans la poche.
Et pour prendre des photos, le 6 simple me parait bien suffisant ; je n'ai habituellement que très rarement recourt à des objectifs stabilisés.
Mais grosso modo, ça se comporte bien, contrairement aux resizable devices.
Les différences de comportement que j'ai pu constater sont plutôt liés à iOS8.
Attention, vous savez peut-etre deja mais moi je l'ai decouvert par hasard hier, qu'il faut ajouter des launch images à la bonne taille pour que l'iPhone 6 communique ses caracteristiques d'ecran a votre app. Sinon il considère qu'elle n'est pas adapatée et la "grossit".
Attention, vous savez peut-etre deja mais moi je l'ai decouvert par hasard hier, qu'il faut ajouter des launch images à la bonne taille pour que l'iPhone 6 communique ses caracteristiques d'ecran a votre app. Sinon il considère qu'elle n'est pas adapatée et la "grossit".
C'est un peu comme lors du passage à l'iPhone 5.
hmmmmm.... Ca doit être ça alors ^^J'ai rien rajouté....
Ceci dit, dans mes LaunchImages Sources assets, j'ai rien de tout ça...
Et finalement, c'est pas plus mal comme ça. Pour les iPhone 5, on avait des barres noires en haut et en bas. Là , par défaut, c'est adapté donc parfait.
Personnellement, j'ai pris l'habitude d'emmener mon téléphone quand je vais courir. Mais j'en ai rien à faire de savoir par où je suis passé, ce qui m'intéresse c'est le temps, la distance, le dénivelé, la vitesse. Et pour le coup la montre c'est quand même beaucoup moins encombrant que l'iPhone
Il est possible de connaitre distance, dénivelé et vitesse sans GPS?
Attention, vous savez peut-etre deja mais moi je l'ai decouvert par hasard hier, qu'il faut ajouter des launch images à la bonne taille pour que l'iPhone 6 communique ses caracteristiques d'ecran a votre app. Sinon il considère qu'elle n'est pas adapatée et la "grossit".
C'est un peu comme lors du passage à l'iPhone 5.
OK, je comprends mieux le comportement observé hier où tout était grossit.
C'est un peu nul comme manière de faire, de se baser sur les launch-images !
Il est possible de connaitre distance, dénivelé et vitesse sans GPS?
Tu crois que les sous-marins nucléaires évoluant à 500 mètres de fond pendant 6 mois ont le GPS ? Ils connaissent leurs positions/vitesse/orientation/profondeur en permanence grace à des accéléromètres. Et se recalent de temps en temps avec des cartes du champ magnétique terrestre.
Il est possible de connaitre distance, dénivelé et vitesse sans GPS?
Pendant la keynote ils ont (me semble-t-il, mais peut être que mon anglais m'a fait mal comprendre) dit avoir grandement amélioré le coprocesseur qui est maintenant autonome pour détecter les déplacements, vitesses ainsi que les changements d'altitude
Dommage qu'ils n'aient pas proposés un iphone 6 de la taille du 5s (du coup un 6, un 6 Plus et un 6 Max) pour profiter des nouvelles puces sans exploser sa poche.
Dommage qu'ils n'aient pas proposés un iphone 6 de la taille du 5s (du coup un 6, un 6 Plus et un 6 Max) pour profiter des nouvelles puces sans exploser sa poche.
Moi je me demande s'il y aura des iPod Touch correspondant ?
Réponses
C'est que tu as du code propre... Moi, vu que je suis toujours une bleue, il reste encore un peu de bricolage par ci par là ... mais ça permet de faire un peu de ménage !
Peut-être une idée à creuser...
non non... Je te rassure, j'ai aussi des choses à faire
Par exemple, en mode paysage, tout s'adapte très bien en iOS7, pas du tout en iOS8. Ca ne s'élargit pas.
Et je n'ai encore que survolé...
Mais grosso modo, ça se comporte bien, contrairement aux resizable devices.
Les différences de comportement que j'ai pu constater sont plutôt liés à iOS8.
Par exemple, les headers et footers des tableview ont changés (sont moches et gras) et la rotation en mode paysage ne se comporte pas du tout pareil (surement du code un peu crado)...
C'est pour ça qu'Xcode 6 a intruoduit Size Classes. Et c'est pour ça qu'on a les simulateurs. Et qu'on a le mode "Preview" dans l'Assistant de Xcode 6 aussi. Perso j'utilise de + en + le mode "Preview" de l'Assistant quand j'édite mes Storyboard ou mes XIB, pour voir directement ce que mon ViewController va donner à la fois en portrait et en paysage et sur différentes tailles d'écran le tout en un coup d'oeil et sans avoir à lancer de simu.
Pour l'instant je n'utilise pas trop les Size Classes, car je n'ai pas prévu de faire des applications dont la présentation générale va être différente selon si elle est sur écran compact (genre iPhone 4) et sur écran large (genre iPhone 6+). Si j'ai ce besoin un jour j'y réfléchirai, mais pour l'instant je décoche même carrément la case "Use Size Classes" dans mes XIB et Storyboards, pour pas m'embêter, car mes ViewControllers ont le même look " juste étirés en respectant les contraintes AutoLayout pour profiter au maximum de la place disponible " quelle que soit la taille d'écran.
Quand on a bien compris AutoLayout, ça va tout seul de ce côté. Et en général mes apps utilisent déjà AutoLayout, qu'on a adopté depuis quelques temps déjà , donc du coup il n'y a rien à faire pour le passage à l'iPhone6 ou iPhone6+, ça fonctionne déjà comme attendu.
Au final ma stratégie donc :
Tu lances Instruments (menu Product > Profile), tu choisis l'instrument "Automation", puis tu cliques sur le bouton d'enregistrement (au rond rouge) tout en bas de la fenêtre de script pour qu'il commence à enregistrer tes actions et générer automatiquement un script pour les reproduire (à ne pas confondre avec le bouton d'enregistrement en haut à gauche de la fenêtre d'Instruments)
Ensuite tu fais joujou avec ton simulateur. Il va t'enregistrer alors tes actions dans le script.
Alternativement, tu peux aussi écrire les commandes dans le script à la main (le langage est assez simple c'est du JavaScript).
Une fois le script généré, avant de le rejouer, tu insères des appels à captureScreenWithName() là où tu veux faire des captures. Puis tu rejoues ton script Automator, tu changes de simulateur, tu rejoues le même script Automator, tu changes de simu, tu le rejoues, etc.
Sinon il existe des scripts qui intègrent ça encore mieux, comme UIScreenShooter, qui fait in fine la même chose (utilisation d'Automation pour rejouer un scénario sur un simulateur et déclencher des captures), mais en pilotant le tout d'un niveau un peu au dessus (il se charge de la compilation pour chaque target, lance instruments en ligne de commande, exécute le script, choisis le nom pour les captures selon le simulateur utilisé et son orientation, etc...)
Créer les vues par code, déjà c'est un peu une plaie par rapport à avoir un éditeur visuel, bien que pour ça pourquoi pas chacun ses goûts, mais c'est aussi et surtout une quantité impressionnante de lignes de code, rien que pour un seul cas. Si en plus tu dois rajouter par code tes contraintes AutoLayout, tes SizeClasses, et j'en passe, t'es pas sorti. Ca fait 3 à 4 fois plus de code pour pouvoir traiter tous les cas.
Le problème quand tu crées tes vues par code c'est que faut aussi du coup s'abonner aux notifications comme quoi l'orientation a changé ou les bounds de la vue parente ont changé (ou alors implémenter layoutSubviews), tout ça pour être sûr que si ton écran change ta vue s'adapte dynamiquement.
En plus, quand tu crées tes vues par code, c'est le meilleur moyen d'introduire des magic numbers dans ton code (et donc, justement, d'être encore moins flexible par rapport aux cas de multi-résolution et multi-orientation)
Alors qu'avec un XIB ou un Storyboard :
- En quelques clics tu crées tes contraintes (maintenant avec Xcode 5 et Xcode 6 c'est plutôt bien foutu contrairement aux débuts), sans une ligne de code tu positionnes tous tes éléments de sorte qu'ils s'adaptent automatiquement à toutes les résolutions et dimensions d'écrans, sans avoir du code de partout pour gérer tout ça ou pour ajouter les 36 contraintes (la plaie à faire par code).
- Avec l'Assistant et son mode Preview, tu vois tout de suite en un coup d'oeil le rendu de ton ViewController en cours d'édition pour voir la tronche qu'il aura sur un device 3.5' ou 4" ou 4.7" ou 5.5", en portrait ou en paysage, et ce sans lancer le simulateur. Tu déplaces un élément et tu vois tout de suite dans l'assistant Preview où il sera positionné dans toutes les configurations.
- Si tu veux un rendu différent sur iPhone et sur iPad, ou plutôt devrais-je dire sur écran compact vs. sur écran large, avec des vues pas du tout positionnées pareil et certaines vues même pas affichées sur un écran compact, pas de soucis, tu as SizeClasses pour ça, pour différencier totalement le placement dans les 2 cas trop différents (alors que par code, c'est encore 2x plus de frames à calculer). Et encore une fois, avec l'assistant tu as le rendu direct de ce que ça va donner dans toutes les configurations, tailles et orientations.
- Avec la création de ton interface par code, tu n'as rien de tout ça, et la seule manière de t'en sortir c'est avec un papier/crayon pour faire le dessin de ton interface sur papier à côté et faire tous les calculs alambiqués de positionnement, et compiler et lancer le simulateur à chaque fois que tu veux voir le rendu dans une configuration donnée. L'horreur, je vois pas comment cette solution pourrait t'éviter des surprises comparativement à la solution utilisant un XIB ou Storyboard !!
Au contraire donc, plus ça va et plus on a des {résolutions + orientations + looks différents selon les versions d'OS} à gérer, et plus la solution XIB ou Storyboard, en tout cas l'utilisation d'InterfaceBuilder, avec AutoLayout et SizeClasses, devient incontournable tellement ça serait de plus en plus compliqué à gérer tous les cas par code là où IB te donne tous les outils visuels pour gérer tous les cas d'un coup.Merci, j'avais un peu regardé automator mais pas trop compris comment le faire fonctionner. Il faudrait que je me repenche dessus. Ca vaut souvent la peine de se donner un peu de mal pour gagner du temps ensuite... le problème, c'est qu'il faut le faire... ::)
Hmmmm, intéressant ce que tu dis Ali....
A ce jour, j'ai une appli universelle et je traite iPhone et iPad différemment sur certains écrans en utilisant les xib avec le (tilde)iPad.
Tu es en train de dire que si j'utilise les SizeClass, ca ne sert plus à rien ?
- D'une part Apple incite à raisonner en "Large" vs. "Compact" (c'est ce qu'Apple appelle donc les "Size Classes") plutôt qu'en "iPad" vs. "iPhone".
- De plus maintenant les XIB et Storyboard intègrent la notion de SizeClasses dans IB, autrement dit maintenant tu peux mettre les 2 variantes (la variante pour la SizeClass "large" et la variante pour la SizeClass "compact" dans le même XIB ou le même StoryBoard.
En fait, il faut plutôt raisonner comme "je fais un Storyboard ou XIB général, applicable à toutes les SizeClasses par défaut (Any/Any), et ensuite je fais des cas particulier pour les SizeClasses qui en ont besoin".En effet, un iPhone 6+ est finalement aussi grand en résolution qu'un iPad Mini, donc ça a + de sens de raisonner en catégorie de taille (Size Classes) qu'en idiome/modèle (iPad/iPhone)
Par exemple tu fais une interface où tu as plein d'infos, tu la design dans IB dans la SizeClass "Any/Any" (la plus générique), et ensuite tu bascules sur la SizeClass "Compact" (qui, tant que tu n'as rien modifié, va reprendre exactement le même look que Any/Any mais compacté pour tenir dans + petit) et tu enlèves des éléments genre des labels (informations superflues dont on peut se passer si on n'a pas assez de place pour les afficher), change le titre d'un bouton "Supprimer le fichier" en "Supprimer" car en vue "compacte" c'est plus court, etc...
Comme ça tout ce qui n'est pas spécifié / customisé dans la SizeClass "compact" il va aller à la place chercher l'objet dans la SizeClass "Any", donc si tu veux par exemple changer la backgroundColor d'une vue finalement plus tard, tu la changes dans la SizeClass "Any" et ça va la changer pour toutes les SizeClasses (à part si tu as une SizeClass où tu avais déjà surchargé la backgroundColor bien sûr). Ca t'évitera donc d'avoir à refaire chaque changement dans toutes les configurations, comme tu es obligé de le faire actuellement avec 2 fichiers différents.
je t'invite vivement à regarder la vidéo WWDC2014 sur les SizeClasses (je sais plus le numéro), elle est plutôt bien foutue et explique bien les choses avec démo/exemples à la clé.
N'ayant absolument pas suivi les rumeurs et autres actus fiévreuses concernant les nouveaux iPhones, je les ai donc découvert lors du Keynote.
Un peu déçu par l'aspect général qui m'a tout de suite rappelé les anciennes générations aux bords arrondis (le design des iphone 5 est bien plus séduisant). Avec mes grandes paluches je serai plus attiré par l'iPhone 6. Le 6 plus me parait trop grand ; j'aurai l'impression de me balader avec un réfrigérateur dans la poche.
Et pour prendre des photos, le 6 simple me parait bien suffisant ; je n'ai habituellement que très rarement recourt à des objectifs stabilisés.
Attention, vous savez peut-etre deja mais moi je l'ai decouvert par hasard hier, qu'il faut ajouter des launch images à la bonne taille pour que l'iPhone 6 communique ses caracteristiques d'ecran a votre app. Sinon il considère qu'elle n'est pas adapatée et la "grossit".
C'est un peu comme lors du passage à l'iPhone 5.
hmmmmm.... Ca doit être ça alors ^^J'ai rien rajouté....
Ceci dit, dans mes LaunchImages Sources assets, j'ai rien de tout ça...
Et finalement, c'est pas plus mal comme ça. Pour les iPhone 5, on avait des barres noires en haut et en bas. Là , par défaut, c'est adapté donc parfait.
Il est possible de connaitre distance, dénivelé et vitesse sans GPS?
Théoriquement oui, des accéléromètres suffisent.
Mais en pratique il faut recaler de temps en temps les calculs faits à partir des accélérations, avec des données GPS par exemple.
OK, je comprends mieux le comportement observé hier où tout était grossit.
C'est un peu nul comme manière de faire, de se baser sur les launch-images !
Il y a une case à cocher.
http://stackoverflow.com/questions/25779571/dealing-with-iphone-6-6-startup-images
Effectivement, ça change tout, bien plus fin
Merci
ça oblige à utiliser Xcode 6 pour envoyer une release...
ah ben faut y aller maintenant Muqa
Maintenant, on peut soumettre sans pb
Pendant la keynote ils ont (me semble-t-il, mais peut être que mon anglais m'a fait mal comprendre) dit avoir grandement amélioré le coprocesseur qui est maintenant autonome pour détecter les déplacements, vitesses ainsi que les changements d'altitude
Dommage qu'ils n'aient pas proposés un iphone 6 de la taille du 5s (du coup un 6, un 6 Plus et un 6 Max) pour profiter des nouvelles puces sans exploser sa poche.
Sinon j'aime assez le nouveau look.
Entièrement d'accord, là , on aurait eu une vraie gamme sympa !
J'y suis depuis 3 mois, mais sur une autre version. ;-)
Puré, tjs de l'USB2 a priori....
Ils abusent quand même...
Moi je me demande s'il y aura des iPod Touch correspondant ?
Ca cannibaliserait beaucoup l'ipad mini non ? Mais c'est vrai que la question peut se poser.
Par contre, les size class, c'est iOS8 only ?