iPad, discussion officielle hors NDA
muqaddar
Administrateur
J'ouvre ce nouveau sujet pour parler de l'iPad et de son écosystème, bref, tout ce qui n'est pas sous NDA (notamment les API).
Merci d'y faire attention.
Pour commencer, je suis plutôt content de l'appareil d'après ce que j'en ai vu en vidéo, mais je me pose tout un tas de questions en tant que développeur.
1) J'espère qu'Apple va présenter les choses clairement dans iTunes. Dans l'AppStore, j'espère 3 sections claires : iPhone, iPad... et Mac un jour prochain.
J'espère qu'Apple précisera juste si l'application est "native iPad" ou juste compatible.
2) Dans la mesure ou la création d'une version iPad peut être juste une adaptation "vite codée" ou une version refaite entièrement (ce que je semble privilégier pour ma part...) pour tirer partie de l'écran notamment, cela impliquera donc 2 versions bien différentes, certainement avec 2 noms différents dans ce cas-là (sinon comment l'AppStore va s'y retrouver ?), et donc pour le consommateur :
- dans le cas de 2 applications natives : payer 2 fois s'il veut les 2 versions OU BIEN acheter la version qu'il préfère
- dans le cas d'une application universelle : payer 1 fois pour avoir la compatibilité et le choix de la plateforme... mais certainement que la version iPad ne sera pas optimisée 100% iPad dans ce cas-là !
Comment le consommateur va-t-il raisonner ? Privilégier la compatibilité ou bien la "forme" ? En étant plus terre-à -terre, va-t-il préférer une appli rétro-compatible à 3 euros ou bien 2 applis natives à 1,50 euros ? Ou bien 1 seule application ? Mais ceci n'est valable que pour ceux qui ont un iPhone déjà ... Donc, le raisonnement est à revoir pour ceux qui n'auront qu'un iPad...
3) Pour le peu de tests que j'ai fait, je trouve dommage de juste actualiser ses applications pour l'iPad sans revoir l'interface. Hors, revoir l'interface et la navigation sans partir sur un projet vierge semble assez "compliqué". Cet écran d'iPad, c'est 6 écrans d'iPhone, et ça serait vraiment dommage de ne pas en profiter ! Amusez-vous à dessiner la tablette sur une feuille A4.
4) Pour ma part, je privilégie la piste des applications "non universal", ne serait-ce que pour une question de poids de binaire également. Par exemple, mon application iDesserts pèse 7,6 Mo... la même avec des photos plus grandes pour l'iPad péserait 30 Mo sûrement. Pour celui qui n'a pas d'iPad, c'est quand-même dommage de perdre du temps de téléchargement et de la place sur son iPhone... Surtout si Apple ne fait pas sauter la limite des 10 Mo hors wifi.
Merci d'y faire attention.
Pour commencer, je suis plutôt content de l'appareil d'après ce que j'en ai vu en vidéo, mais je me pose tout un tas de questions en tant que développeur.
1) J'espère qu'Apple va présenter les choses clairement dans iTunes. Dans l'AppStore, j'espère 3 sections claires : iPhone, iPad... et Mac un jour prochain.
J'espère qu'Apple précisera juste si l'application est "native iPad" ou juste compatible.2) Dans la mesure ou la création d'une version iPad peut être juste une adaptation "vite codée" ou une version refaite entièrement (ce que je semble privilégier pour ma part...) pour tirer partie de l'écran notamment, cela impliquera donc 2 versions bien différentes, certainement avec 2 noms différents dans ce cas-là (sinon comment l'AppStore va s'y retrouver ?), et donc pour le consommateur :
- dans le cas de 2 applications natives : payer 2 fois s'il veut les 2 versions OU BIEN acheter la version qu'il préfère
- dans le cas d'une application universelle : payer 1 fois pour avoir la compatibilité et le choix de la plateforme... mais certainement que la version iPad ne sera pas optimisée 100% iPad dans ce cas-là !
Comment le consommateur va-t-il raisonner ? Privilégier la compatibilité ou bien la "forme" ? En étant plus terre-à -terre, va-t-il préférer une appli rétro-compatible à 3 euros ou bien 2 applis natives à 1,50 euros ? Ou bien 1 seule application ? Mais ceci n'est valable que pour ceux qui ont un iPhone déjà ... Donc, le raisonnement est à revoir pour ceux qui n'auront qu'un iPad...
3) Pour le peu de tests que j'ai fait, je trouve dommage de juste actualiser ses applications pour l'iPad sans revoir l'interface. Hors, revoir l'interface et la navigation sans partir sur un projet vierge semble assez "compliqué". Cet écran d'iPad, c'est 6 écrans d'iPhone, et ça serait vraiment dommage de ne pas en profiter ! Amusez-vous à dessiner la tablette sur une feuille A4.
4) Pour ma part, je privilégie la piste des applications "non universal", ne serait-ce que pour une question de poids de binaire également. Par exemple, mon application iDesserts pèse 7,6 Mo... la même avec des photos plus grandes pour l'iPad péserait 30 Mo sûrement. Pour celui qui n'a pas d'iPad, c'est quand-même dommage de perdre du temps de téléchargement et de la place sur son iPhone... Surtout si Apple ne fait pas sauter la limite des 10 Mo hors wifi.
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
je suis assez d'accord avec toi sur le fait de refaire entierement une version pour l'ipad
Ca dépend de l'interface de base de l'application iPhone.
Ma première application est basée sur une UITableView et bien sûr pour l'iPad, toute l'interface est à revoir.
Par contre pour la seconde, iPocket Draw, j'ai peu de modifications à faire puisque l'interface est basée sur une vue avec des boutons.
Elle s'adapte donc à la taille de l'écran.
Mes vues secondaires affichées avec "presentModalViewController" sur iPhone sont affichées avec "presentPopoverFromRect" sur l'iPad.
J'ai juste un soucis car certaines vues secondaires affichent une autre vue secondaire et ça, ça coince un peu pour l'instant.
Du coup, à part ce problème, la version iPad d'iPocket Draw est fonctionnelle.
On peut s'en sortir avec un seul projet et toute la partie modèle réutilisable voir même certain contrôleur. Il restera a avec deux vues différentes avec leurs contrôleurs à adapter.
Avec le système de ViewController c'est d'ailleurs facilité, je vois bien une archi comme ça modèle -> controlleur -> viewController. En plaçant dans le controller toute la préparation générique etc et dans le VC juste ce qui va être propore à l'affichage.
Pour bien des applications iPhone actuelle ça dois passer (toute celle utilisant les tableBar + tableView par exemple).
Vous voyez ça comment vous ?
Oui mais tu penses faire une universal ou 2 binaires ?
Oui, ça on le sait.
Mais ça ne répond pas à toutes les interrogations du haut.
Non justement, à se faire chier à jouer le MVC à 200% autant faire 3 clic de plus pour avoir les deux targets.
Apple ne recommande l'universal que pour les petites applications qui n'ont pas de vrai différence entre l'iPad et l'iPhone. Pour le reste double target !
La seule chose c'est que j'espère qu'Apple sera plus permissif coté gestion des prix pour laisser le choix aux dev de vendre séparément ou en même temps les deux targets (et proposer les MAJ payante aussi c'est pas mal...)
Bonjour,
Oui bien sûr mais les recommandations d'Apple sont à prendre en compte fortement car même avec les développeurs, ils peuvent être directifs.
D'autant plus que pour l'instant, il n'y a pas trop d'explication sur le pourquoi de cette recommandation.
Il n'y a pas si longtemps, il y avait eu la "recommandation" des appli en Universal Binary.
Par contre, il faut des clarifications sur les possibilités ou non de différences de tarif des app. iPhone et iPad.
Moi, par exemple, je suis parti sur un seul projet avec 2 targets + des groupes de classes dont un groupe de classes partagées (en plus des modèles) et idem pour les images pour alléger les binaires + 2 info.plist (pas obligatoire mais plus clair) et même 2 appDelegate de même nom (puisque chacun est cherché par le bon MainMenu.xib targeté).
A la rigueur, je pourrais changer pour une Universal facilement par la suite en faisant un bon test sur le device.
L'universal je ne l'utiliserais que dans des cas ou je veux ma faciliter la vie (genre une appli quasi identique sur les deux terminaux vendu a un client qui veux juste que ça marche sans y passer 30 ans)
Apple nous dit de l'éviter si possible... Histoire de ne pas avoir de #ifdef IPAD partout ?
Sinon, si j'ai 2 appDelegate dans mon cas, c'est qu'il y a bien plus de différences que 3 lignes.
Il semble que le proc A4 ne soit pas un ARM. Sinon, pourquoi deux binaires ? Lors de la keynote il on laisser échappé à plusieurs reprise que les applications iPhone était émulé. La dernière fois qu'Apple a parlé d'universal binary est pour Mac OS X lors du passage sur Intel.
Ceci dit en plus du processeur l'écran est bien plus grand. Donc il me semble plus simple de faire deux binaires. De plus ça évite de faire grossir les APP.
PS: je suis en trait de commencer une app pour iphone et je galère pas mal (il faut quasiment tout coder même l'HIM). Je trouve pas ça aussi simple que pour Mac Os X en plus du fait que j'ai pas trop le temps de m'y pencher
Bah pourtant c'est pratiquement la même chose. Il manque juste les bindings, mais on s'en sortait très bien sous MacOS X avant qu'ils n'existent.
D'autant que dans le SDK iPhone, les classes profitent des évolutions d'Obj-C 2.0 (les API sont pensées avec), donc déjà toutes les @property sont déclarées comme telles, on a la possibilité d'utiliser la syntaxe pointée, etc... chose qu'on ne peut pas avec le SDK OSX car à l'époque où l'API a été écrite tout cela n'existait pas.
Maintenant, je comprend que ta première incursion dans le SDK iPhone soit troublante et que tu t'y perde. Au début c'est le cas de toute le monde. Même si comme le dit zoc c'est pratiquement la même chose, c'est vrai que dans les faits :
- Le concept de ViewController est inexistant sous OSX, alors qu'il est omniprésent sous iPhone
- Le travail de design n'est pas le même (sous OSX on peut avoir une grande fenêtre avec tout dedans, éventuellement des drawers et fenêtres additionnelles... sous iPhone faut raisonner en écrans quand tu fais ton design)
- La gestion de la mémoire est plus importante (comme tout développement mobile d'ailleurs), et le découpage en XIB différents devient une habitude limite obligatoire, là où sous OSX on n'est pas du tout habitué et l'on met tout dans MainMenu.xib
... bref, 2-3 concepts différents, des bonnes habitudes à prendre (qui sont applicables si l'on veut aussi à OSX, mais qu'on voit beaucoup moins pratiquer dans le monde OSX que dans du monde mobile), ça joue, même si l'ensemble est quand même la même chose (même coeur, même framework, même IDE, même fonctionnement et concepts de base, ...)
Je pense qu'il y a ce qu'Apple conseille pour la globalité des développeurs. N'oublions pas qu'il y a beaucoup de développeur iPhone qui sont des nouveaux venu du Java. Les notions de compilations conditionelle dans un PDF d'introduction serait quand même mal venu pour eux.
Pour autant dès que tu travail sur un code qui a pour objectif d'être utilisé sur plusieurs plateforme la compilation conditionelle est utile.
Regarde les sources de LAME par exemple, tu as forcément du conditionel en fonction de la cible de compilation, sinon c'est le bordel à maintenir !
N'oublions pas qu'Apple donne uniquement des guidelines, à nous de voir réellement ce qu'il est nécessaire d'appliquer dans notre code :-)
En effet, si il y a quelques années (pas si longtemps), j'étais le seul à avoir une vision "Think different", et la plupart des élèves ne savaient même pas ce qu'était un Mac. Depuis l'avènement de l'iPod, cela a changé, mais pas tellement. Ils savent ce c'est. Mais ils considèrent que ce n'est pas un ordi pour eux : trop cher, pas de msn et autres arguments...
Bref, j'en arrive à l'étonnement du moment. J'entends de plus en plus le désir d'en savoir plus, voir même des intentions d'achat de la part d'ados qui sont normalement sur PC. Quels arguments ? Le prix (même s'il n'est pas encore connu) et le côté fun d'un iPod tuch / iPhone.
Tu veux parler de la limite levée il y a 15 jours ? Bon d'accord, elle est juste passée à 20 Mo, mais c'est un progrès quand même !
Sinon, pour rester dans le cadre du topic, je pense qu'il est préférable de faire des applications distinctes sur les deux machines, surtout à cause de l'interface utilisateur. Un écran iPad ne se conçoit pas comme un écran iPhone, la taille des écrans étant bien trop différente.
C'est intéressant cette évolution que tu constates Mage. Merci du retour.