Prévisions WWDC 2012

FKDEVFKDEV Membre
mai 2012 modifié dans Coin canapé & détente #1
L'année dernière j'avais prévu un SDK pour iCloud.

Comme je suis content de moi, je rejoue cette année.



J'aurais bien prévu un SDK pour Siri mais j'ai l'impression que c'est un peu tôt.



Pour iOS 6 et Mountain Lion, j'ai envie de prévoir un gros effort d'unification des SDK iOS et OSX.

Mais si c'était vrai, des petits malin l'auraient déjà  détecté dans les frameworks inclus dans les bétas de ML.



Un SDK pour la future TV ? Pour que des applis soient prêtes à  la sortie du produit à  Noël.

Bof... Il y aurait déjà  eu des fuites...



Allez j'opte pour un nouveau MapKit basé sur OpenstreetMap avec support des offline maps.

Avec une annonce de support du projet OSM (fourniture de donnée, photos aérienne, ou autre).

Réponses

  • yoannyoann Membre
    Unification des SDK, je ne vois pas vraiment ce que vous voulez de plus. Pour la partie graphique, l'AppKit et UIKit ne seront pas mélanger, ce sont des paradigme d'infterface trop différents pour être unifier. Par contre les idées de l'un sont adapté à  l'autre (comme le centre de notification, certaines gestures au trackpad...). Pour le reste, tout est déjà  identique... Foudation, CoreDate, CoreAnimation...



    Je vois pas vraiment en quoi on peut faire plus unifié...



    Quand Snow Leopard est sorti, c'était l'OS avec 0 nouveauté utilisateur, que de la stabilisation. Aujourd'hui on sait que ML dispose de quelques nouvelles fonctionnalités de sécurité, je ne pense pas qu'on ait de gros truc à  faire péter la baraque.



    Le nombre d'application sur le Mac App Store étant encore faible, je pense que la WWDC va surtout porter sur "de iOS à  OS X" et les fonctions avancé de ML (optimisation, API de sécurité...).



    Le changement de Map, c'est possible oui, mais ça ne changera rien pour nous...



    Un SDK siri, c'est une éventualité mais ça semble complexe à  mettre en oe“uvre. Le point réellement intéressant avec Siri c'est le contrôle du téléphone verrouillé. Pour pouvoir dire à  Siri "tag cette musique sur Shazam" il faut un niveau de configuration vraiment lourd pour l'utilisateur... Genre le centre de notification mais pour Siri et avec plus d'option... Certes Jobs n'est plus là  pour dire non aux idées de merde (genre l'OS de l'AppleTV) mais ça me parait vraiment gros... Et derrière il faut des applications faites par des développeurs qui ont des connaissances en analyse du langage...
  • FKDEVFKDEV Membre
    mai 2012 modifié #3
    'yoann' a écrit:
    Unification des SDK, je ne vois pas vraiment ce que vous voulez de plus. (...)




    Je sais pas moi... Par exemple, accès facile aux albums photos dans iPhoto comme sur iOS. Idem pour iTunes. Mapkit sur OSX. Plus de filtre CoreImage.



    C'est vrai que les paradigmes d'interface sont différents. Mais en règle générale, les API qui sont comparables me paraissent plus difficiles d'accès (plus puissantes aussi) sur OSX que sur iOS (par ex: la Web View, la Table View).

    En plus, pourquoi différencier certaines classes comme UIImage/NSImage, UIColor/NSColor.



    Au final, avec iOS qui devient plus puissant et OSX qui se modernise, je pense qu'il y a une API de juste milieu à  proposer qui permettra aux développeurs de porter leurs applis plus rapidement de l'un à  l'autre.

    En gros ce serait cool si porter une app de l'iPad vers le Mac soit aussi facile que de porter une app de l'iPhone à  l'iPad.



    Pour moi le "Back to the Mac" n'a pas vraiment eu lieu comme il le faudrait.

    J'ai fait l'essai par exemple de porter une app qui affiche des listes par l'intermédiaire de la UITableView de iOS sur Mac car sur le SDK 10.7 il y a eu des changements dans la NSTableView qui rappelle iOS (réutilisation des cell view par exemple). C'est super en théorie mais le problème c'est que les deux listes ne fonctionnent pas de la même manière. Il n'y a pas de section sur la NSTableView. Pas non plus de gestion d'index simple en utilisant NSIndexPath par exemple. Le portage revient donc à  tout refaire alors que la différence de paradigme d'interface ne le justifie pas complétement.



    Je me trompe peut-être car j'ai peu d'expérience sur le Mac mais même avec les SDK revus dans Lion, on sent une différence de philosophie dans les API qui perdurent parce que, je suppose, les équipes sont différentes.

    Pour moi la grande force d'Apple c'est la cohérence à  travers les produits. Si cette cohérence n'est pas présente dans les APIs alors elle ne se retrouvera pas pour l'utilisateur. Il ne faut pas que ça devienne comme chez Microsoft où les équipes sont en concurrence et se tirent dans les pattes, ce qui a pour conséquence des logiciels incohérents même au sein de la Suite Office par exemple.
  • yoannyoann Membre
    Les tablesView se gèrent différemment par ce que les paradigme d'interface sont différents... Tu ne peux pas gérer une NSTableView avec un simple indexPath, il te manquera ton identifiant de colonne...



    UIImage/NSImage, je pense que c'est une simple question de logique. Tout ce qui est images et couleurs fait parti de l'API graphique donc prend le préfixe qui va avec même si ça doit faire plus ou moins la même chose.



    Pour ce qui est de la suite iLife, ça peu ce discuter en effet.
  • DrakenDraken Membre
    Des filtres CoreImage pour iOS !
  • FKDEVFKDEV Membre
    'yoann' a écrit:


    Les tablesView se gèrent différemment par ce que les paradigme d'interface sont différents... Tu ne peux pas gérer une NSTableView avec un simple indexPath, il te manquera ton identifiant de colonne...


    Euh section.ligne.colonne, ça marche non ?




    'yoann' a écrit:


    UIImage/NSImage, je pense que c'est une simple question de logique. Tout ce qui est images et couleurs fait parti de l'API graphique donc prend le préfixe qui va avec même si ça doit faire plus ou moins la même chose.


    Mouais... image/huh.gif' class='bbc_emoticon' alt='???' /> Chacun sa logique.
  • yoannyoann Membre
    'FKDEV' a écrit:


    Euh section.ligne.colonne, ça marche non ?




    La colone doit forcément être une chaine de caractère (les colonnes peuvent se réordonner). Par contre c'est clair qu'il manque un système de section.


    'FKDEV' a écrit:


    Mouais... image/huh.gif' class='bbc_emoticon' alt='???' /> Chacun sa logique.


    Logique de conception ici. ça aurait été moins chiant si l'UIKit était préfixé en NS (mais ça aurait été perturbant pour le reste comme les boutons)
  • DrakenDraken Membre
    Il ne peut y avoir de cohérence entre une interface uniquement tactile et une interface tactile/souris/trakball. ça se conçoit et se gère différemment.
  • FKDEVFKDEV Membre
    mai 2012 modifié #9
    'Draken' a écrit:


    Il ne peut y avoir de cohérence entre une interface uniquement tactile et une interface tactile/souris/trakball. ça se conçoit et se gère différemment.




    Regarde la liste de tweets dans Twitter OSX.

    Les cellules ressemblent à  des cellules de Table View sur iOS : icône à  gauche, des textes de taille et de couleur différentes dans la même cellule. La largeur de la liste est fixe et d'une taille comparable à  un écran d'iPad.

    Sur ma magic mouse, les mouvements de doigts pour parcourir la liste sont presque les mêmes que sur iPad.

    On pourrait s'attendre à  ce que ce soit codé à  l'aide des mêmes API que sur iOS.



    Idem pour Sparrow. http://sparrowmailapp.com/

    C'est ce que j'appelle de la cohérence.



    Ce que je pense, c'est que le SDK de OSX est à  la traine. Qu'il ne permet pas de faire des Apps OSX sympas et moderne aussi rapidement que sur iOS.

    Ce que je crains, mais j'en sais absolument rien, c'est que ce soit un problème humain ou d'organisation au sein des équipes R&D d'Apple.

    Voilà  c'est juste mon avis et c'est pourquoi j'aimerais qu'Apple annonce des gros efforts sur l'uniformisation des SDK.
  • yoannyoann Membre
    mai 2012 modifié #10
    'FKDEV' a écrit:


    Regarde la liste de tweets dans Twitter OSX.

    Les cellules ressemblent à  des cellules de Table View sur iOS : icône à  gauche, des textes de taille et de couleur différentes dans la même cellule. La largeur de la liste est fixe et d'une taille comparable à  un écran d'iPad.

    Sur ma magic mouse, les mouvements de doigts pour parcourir la liste sont presque les mêmes que sur iPad.

    On pourrait s'attendre à  ce que ce soit codé à  l'aide des mêmes API que sur iOS.



    Idem pour Sparrow. http://sparrowmailapp.com/

    C'est ce que j'appelle de la cohérence.




    Tu cite un cas hyper particulier d'une application avec une tableview à  une seule colonne. C'est un cas marginal d'une application faite pour limiter les capacités de l'utilisateur !
  • MalaMala Membre, Modérateur
    'yoann' a écrit:


    UIImage/NSImage, je pense que c'est une simple question de logique. Tout ce qui est images et couleurs fait parti de l'API graphique donc prend le préfixe qui va avec même si ça doit faire plus ou moins la même chose.


    UIImage,NSImage,CGImage,CIImage ça commence a être sacrément le bronx pour les newbies...
  • yoannyoann Membre
    'Mala' a écrit:


    UIImage,NSImage,CGImage,CIImage ça commence a être sacrément le bronx pour les newbies...




    Et c'est tant mieux ! Moins il y a de newbies et moins ont a à  justifier les prix journalier d'un dev expérimenté. On en discutait avec un pote bien plus ancien que moi dans le secteur et depuis quelques temps c'est impressionnant, chute libre des prix en freelance, que ce soit pour de la formation ou pour du consulting.
  • LarmeLarme Membre
    Faudrait juste former les nioubies au " vrai " travail et aux réels coûts.

    Que la communauté augmente, c'est sympa, mais il faut toujours de la qualité derrière.
  • yoannyoann Membre
    'Larme' a écrit:


    Faudrait juste former les nioubies au " vrai " travail et aux réels coûts.

    Que la communauté augmente, c'est sympa, mais il faut toujours de la qualité derrière.




    Vu ce que l'histoire (windows et web entre autre) nous montre, je ne suis pas spécialement confiant. Plus une plateforme est en vogue, plus il y aura de gens prêt à  bosser à  pas cher pour faire de la merde vu que c'est ce que les entreprises demandes. Garder un cercle restreint d'initié permettait de garder une qualité globale plus élevé. Et tant que les formations étaient faites par ces gens, ça permettait de passer le flambeaux on va dire (tout du moins c'est ce que j'espère arriver à  faire dans mes cours).



    Depuis quelques temps on constate que pas mal de centre de forma bosse avec des formateurs que personne ne connait. Ce qui n'aide pas du tout à  garder une ligne de formation globale au niveau...



    Enfin c'est mon point de vue de jeune vieux con :-p
Connectez-vous ou Inscrivez-vous pour répondre.